Three stages, and an exit after each one
Diagnose, Build, Run. Most of what goes wrong in software projects goes wrong in the gap between what was agreed and what was understood. This is how we close it.
What the process commits us to
4 things that decide this
- 01A scoping call costs nothing, and you leave it with our read on the problem whether or not you hire us.
- 02Where the answer depends on code we have not read, a paid two-week diagnostic produces the scope and a fixed build price.
- 03The build price is fixed from that diagnostic. If we estimated badly, that is ours to absorb.
- 04The engineers who build the system are the ones who run it afterwards. Nobody is handed to a separate support desk at launch.
Most projects are priced before anyone understands them
A vendor sees a requirements document, quotes a number, and wins the work. The number was a guess. Six weeks in, the integration nobody looked at turns out to have no API, and the argument about who pays for that starts.
We split the guess out and charge for it separately, because it is real work. Reading an existing codebase, tracing what the data actually looks like and testing the integration that everyone assumes is fine takes senior engineers days. Priced into a build, that effort is invisible and gets skipped.
- 01You get the diagnostic document whether you continue with us or not. It is yours, and it is specific enough to send to another firm.
- 02A greenfield build with no existing system to read usually needs no diagnostic. We scope it on the call.
- 03Anything touching a system already in production gets one, because that is where estimates fail.
Diagnose, Build, Run
Each stage ends with something you own and can act on. There is no stage whose only output is a proposal.
- 01
Diagnose
A senior engineer reads the code, the data and the integrations, then writes down what the build actually involves. You get the scope, the risks that could move it, and a fixed price for the build. Free where the problem is greenfield. Paid, over two weeks, where it sits inside a system we have to go into.
- 02
Build
Fixed price, taken from the diagnostic. Code lands in your repository under your review, on your ticketing system and in your sprint ceremonies. You see working software continuously rather than a demo at the end.
- 03
Run
The system goes live with monitoring, evals where a model is involved, and documentation written for whoever inherits it. You choose an ongoing agreement under an agreed service level, or a handover that trains your own team until they can run it without us.
- ScopeAgreed from a document nobody tested
- IntegrationThe system with no API
- DataReal records, not the sample set
- LaunchThe demo works. Monday does not
- OwnershipWho answers the pager at 2am
Every one of these is knowable before the build starts, and every one of them is cheaper to find in week one than in month four. The diagnostic exists to move the discovery of all five to the left.
Fixed price only works if somebody carries the risk
A fixed price is usually a way of moving risk onto the buyer. The vendor pads the number, then bills change requests for anything the document did not spell out. You pay for the padding and the changes.
Ours works the other way round. The diagnostic is what earns the right to quote a fixed number, and once quoted it holds. An estimate we got wrong comes out of our margin. That is the point: you are buying certainty about the number, not a discount on it. We are not the cheapest bid and do not try to be.
- Scope changes you ask for are re-quoted openly. Scope we misjudged is not.
- The diagnostic document names the risks that could move the price, before you commit.
How most engagements run, and how ours does
| Criterion | The usual shape | How we run it |
|---|---|---|
| Where the price comes from | A guess against a requirements document, padded for the unknowns. | A diagnostic where an engineer reads the actual code and data first. |
| Who pays when the estimate was wrong | You do, through change requests. | We do. The build price is fixed from the diagnostic. |
| Who writes the code | Senior people pitch. Juniors deliver. | The engineers you meet are the engineers who build it. |
| What happens at launch | Handover to a support queue that has never seen the system. | The same team keeps running it, under an agreed service level. |
| What you can take elsewhere | A proposal. | The diagnostic document, the code, the models and the infrastructure. |
Systems still running after launch
“They will treat your vision like their own and build it that way.”
Ron Klabunde · Founder, SmartREI ↗
Delivered with every build
In the repository
Where a model is involved
After launch
What buyers ask before the first call
01Do I have to pay for the diagnostic?
Only where we need to go into a codebase we have not seen. Scoping calls are free, and a greenfield build is usually scoped on the call at no charge. The paid two-week diagnostic applies when the answer sits inside an existing system. Reading one properly is engineering work, not a sales activity.
02How long will my build take?
Nobody can answer that before seeing the problem, and a firm that quotes you a range on a first call is guessing. The diagnostic produces a delivery date alongside the scope and the price, and that date is what we commit to. Where there is no existing system to read, we can usually settle it on the scoping call instead.
03What if we stop after the diagnostic?
You keep the document and owe nothing further. It contains the scope, the architecture, the risks and the fixed price, written plainly enough to hand to another firm or to your own team. Some clients run the diagnostic specifically to get a second opinion on a build already underway.
04Who owns the code and the models?
You do, completely. Source code, fine-tuned models, prompts, evals and data pipelines transfer to your organisation with no licence-back clause. Nothing we build depends on us continuing to be involved for it to keep running.
05Can we use our own project management and repository?
Yes, and it is the default. Engineers work in your repository, your ticketing system and your review process rather than asking you to adopt a parallel one. Enterprise teams get the compliance and access review that implies. A startup with no platform team gets that set up as part of the build.
06What does the Run stage actually cover?
Uptime monitoring, alerting, dependency and model updates, and the evals that catch a model drifting after launch. You pick one of two shapes. Either an ongoing agreement under an agreed service level, or a documented handover where we train your team until they can run it themselves. Both are priced and written down before launch, not negotiated during an incident.
Read next
- What to ask any AI vendor →The questions that separate a demo shop from a team that ships.
- Fixed price against time and materials →Which contract shape fits which kind of build.
- Taking a prototype into production →What changes between a demo that works and a system that runs.
- Engineers embedded in your team →When you want to direct the work yourself.
