You already run a business
We become your technical side.
You run the business and you can already describe what is wrong with it. What you don't have is someone whose job is the software — so decisions get made by whoever is available, and the cost of that shows up eighteen months later.
The arrangement
You pay us. You own all of it.
No equity, no licence, no dependency engineered in. The handover at the end is the real thing — source, infrastructure, credentials, documentation — on accounts with your name on them.
You bring
- A working business, with customers and revenue
- The problem, as you would describe it to a colleague
- Whoever actually does the work today, for an hour or two
- Whatever exists already — code, spreadsheets, the system you hate
We bring
- A written specification you sign before anything is built
- Architecture and engineering judgement, not a template
- Security, reliability and monitoring as part of the build
- A handover that leaves you able to hire someone else
What this usually is
Six shapes this takes.
Most first emails are one of these, and the one you recognise is usually not the one you would have named.
The build that stopped
A contractor left or an agency went quiet. We read what exists before quoting anything, and tell you whether it is worth continuing.
The system nobody will touch
It runs the business and every change is a risk. We replace the part costing you most and keep the rest running while we do it.
The numbers that arrive too late
Usually not a reporting problem. It is that nothing captures the cost as it happens — so we fix where the data enters.
The thing that never got built
The process everyone works around because the software has never supported it. Often the cheapest thing on this list to fix.
The subscription that never stops
Per-seat fees that grow every time you hire, for a product that still does not fit. Sometimes worth it, sometimes not — there is a calculator for that.
Systems that don't talk
Work re-entered by hand between tools you already pay for. Connecting them is rarely the hard part; agreeing what is true is.
AI, where it changes the outcome
Applied to a decision or a bottleneck that costs you money, not added so the system can be described as having it.
How it works
What gets built is what you signed.
The specification is the product of the first phase, and it is what the price is attached to. If it is wrong, it is cheap to be wrong at that point.
- 01
We work out how it actually runs
Not how it is supposed to run. What people really do, where the exceptions are, and which system holds the truth when two disagree.
- 02
We write the specification, and you sign it
What gets recorded, who sees it, every process end to end, what each person uses, what it connects to, and how we both agree a thing is finished — in your words. Then you read it, argue with it, and send it back. Nothing is built until it says what you want.
- 03
We build it in pieces you can see
Progress against the document you signed, section by section, rather than a status update written to sound reassuring.
- 04
You steer while it is being built
You are in the development environment from early on. What is wrong gets said while it is cheap to fix, and changing your mind is normal rather than a problem.
- 05
It goes live, and it is yours
Deployed, monitored and documented, on accounts in your name — with a handover session for the people who will live with it.
Tell us what is going wrong.
A real engineer reads it, and you get an honest answer about whether we are the right people — including when we are not.