Our Values
What We Hold To
Two sets of them. What you can expect from us on any piece of work, and the six we hold ourselves to while it is being done.
What You Can Expect
Six Things That Do Not Change
Your Business Comes First, Then the Software
Before anything is designed, we spend time with the people doing the work and follow it the way it actually moves: who does what, in which system, and where it slows down. You tell us what should be different once it is built, and we agree how we will both know whether it happened.
You Hear the Inconvenient Thing Early
If something off the shelf does the job, or the timing is not right, you hear it while it still saves you money. A project that should not have started costs you money and costs us your trust, and neither of us finds that out until much later.
Everything We Build Is Yours
The systems, integrations, code, and documentation are yours, in your accounts, from the first day. If the engagement ends, all of it stays with you and keeps running. No business should be held to a supplier by the supplier holding its systems.
What Already Works Stays
Most of our work connects to systems that are already in place and have to keep running while we do it. Where something still meets the need, it becomes part of the answer rather than something to replace, and anything new has to earn its place before it goes near your business.
Done Means Running in Your Business
Not demonstrated, not handed over, not working on one machine. Running where your people use it, documented, and supported, with someone who knows it well enough to answer for it.
Your People Get Their Time Back
The person keeping a spreadsheet alive is holding the business together. When the work they have been carrying by hand moves into the system, they get their hours back and their evenings with them. Going live is the middle of this, not the end: we keep developing and supporting it afterwards, with the service levels agreed in writing.
Our Core Values
The Six We Measure Ourselves By
Quality
Quality is set by what we are prepared to put our name to. It is decided early, in the questions asked at the beginning, in the review that happens before anything moves on, and in a willingness to say that something is not finished yet.
Results
We hold ourselves to what changed, not to what was produced. Hours recorded and items completed describe activity. The measure is whether the thing we set out to improve actually improved.
Trust
We keep our word. What is agreed is delivered, and when circumstances genuinely change, that is raised at once and in plain terms, while there is still time to respond to it.
Relationship
We know the people we work with. Time is taken to learn how someone works, what they are good at, and what they are carrying, and that knowledge stays with us. A working relationship outlasts the piece of work that started it.
Respect
We treat people as equals, whatever their title or however long they have been here. When we look at a decision, we look at what shaped it rather than who made it, and that holds just as much when the person is not in the room.
Innovation
We are still here because the work never stood still. It began with custom ERP in 1994 and has moved since through web and mobile, then data, AI, and cloud. Curiosity is part of the role, and anything new has to earn its place on merit.
The People Doing It
How Our Engineers Learn the Work
A system is only as good as the judgement behind the hundreds of small decisions inside it. Some of that is taught, and the rest comes from the way the work is set up.
Before Any Project
The genius office Engineering Program
Every engineer completes it before they are put on a project, whatever they did before they arrived. It is an internal curriculum, taught by people who are currently shipping, and it is revised as the work changes.
- Architecture That Scales
- How to shape a system so growth is a setting to change rather than a rebuild.
- Systems That Keep Running
- How a system keeps going when something it depends on stops, and how work resumes without anything being lost.
- Performance Under Real Load
- How something behaves with production-sized data and real concurrency, not with a developer's test set.
- Production Coding Standards
- What we hold code to before it can run a business: readable, reviewed, tested, and possible for someone else to change.
Every Specialization Has Its Own Standard
The curriculum is shared, but the detail is not. Each discipline keeps a written standard of its own, setting out what has to be true before work in that area is called finished. They are the reason two engineers who have never worked together produce something consistent.
- Web & Mobile
- What a review looks for before an interface is done, including how it behaves on a small screen, a slow connection, and with a keyboard alone.
- Back End & Integrations
- How a service reports failure, what it retries, and how it proves a transfer between two systems actually completed.
- Data & Reporting
- How a pipeline demonstrates its numbers are right, and what has to hold before a figure is allowed onto a dashboard someone will decide from.
- AI Features
- What is checked before a model's output goes near a decision, where a person stays in the loop, and what is recorded so an answer can be traced later.
- Cloud & Operations
- How infrastructure is described in code, how access is granted and removed, and how a system is restored when something fails.
Each one is written down, reviewed, and revised by the people working to it whenever the work teaches us something the document does not say yet.
After That, the Learning Is in the Work
- They Meet the Business First
- Engineers sit in the sessions where we follow the work as it actually moves. They hear the problem from the person living it, in that person's words, before anyone writes a line of code. It is much harder to build the wrong thing when you have met the people who will use it.
- They Stay With What They Build
- Because we stay after launch, an engineer sees their own decisions play out over years, not weeks. Nothing teaches judgement faster than maintaining a system you designed, and living with the shortcut you were tempted to take.
- Every Change Gets a Second Reader
- Review and testing are part of the work rather than a stage added at the end. A second engineer reads what was written, and the person who built it explains why. That is also how the newer engineers learn fastest, and how the experienced ones keep their reasoning sharp.
- Range Comes From the Work Itself
- We started in custom ERP in 1994 and now build data platforms, AI, and cloud systems across seventeen industries. Engineers move across that range instead of staying in one lane, which is how someone learns what a pattern is worth outside the place they first saw it.
Since 1994
for genius people.
Our mantra has not changed since the first year. It describes the people we build for, never us: the people who built real businesses, and who deserve technology that keeps up with what they built.
Does This Sound Like How You Want to Work?
Tell us what is happening in the business and what needs to change. We read every message and reply ourselves.