Four steps, and an exit after each one
Audit, Blueprint, 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
- 01The first call costs nothing, and you leave it with our read on the problem whether or not you hire us.
- 02Every build starts with a Blueprint: a fixed-fee plan an engineer writes from your real systems, covering scope, architecture, risks and a fixed price for each milestone.
- 03The Blueprint fee is credited in full against the build. If the plan isn't one you'd act on, you don't pay for it.
- 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 your systems, tracing what the data actually looks like and testing the integration everyone assumes is fine takes senior engineers days. Priced into a build, that effort is invisible and gets skipped. The Blueprint is that work, done first and written down.
- 01You get the Blueprint whether you continue with us or not. It is yours, and it is specific enough to hand to another firm.
- 02The Blueprint is standard on every engagement. An engineer reads what you actually run before we quote anything.
- 03If the Blueprint doesn't give you a plan you'd act on, you don't pay for it.
Audit, Blueprint, Build, Run
Each step ends with something you own and can act on. There is no step whose only output is a proposal.
- 01
Audit
A free call where a senior engineer looks at the problem with you. You leave with our honest read on it: what we would build, what we would not, and whether we are the right firm for the job.
- 02
Blueprint
A fixed-fee plan written from your real systems, not from a requirements document. It sets the scope, the architecture, the risks that could move the price, and a fixed price for each milestone. The fee is credited in full against the build. If the plan isn't one you'd act on, you don't pay for it.
- 03
Build
Fixed price per milestone, accepted against written criteria rather than billed by the hour. 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.
- 04
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 Blueprint 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 Blueprint is what earns the right to quote fixed numbers, and once quoted they hold. A milestone we estimated badly 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 Blueprint names the risks that could move the price, before you commit.
How most engagements run, and how ours does
Where the price comes from
The usual shape
A guess against a requirements document, padded for the unknowns.
How we run it
A Blueprint where an engineer reads the actual code and data first.
Who pays when the estimate was wrong
The usual shape
You do, through change requests.
How we run it
We do. Each milestone's price is fixed in the Blueprint.
Who writes the code
The usual shape
Senior people pitch. Juniors deliver.
How we run it
The engineers you meet are the engineers who build it.
What happens at launch
The usual shape
Handover to a support queue that has never seen the system.
How we run it
The same team keeps running it, under an agreed service level.
What you can take elsewhere
The usual shape
A proposal.
How we run it
The Blueprint, 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
- Source code
- Migrations
- CI pipeline
- Test suite
- Runbook
Where a model is involved
- Eval suite
- Versioned prompts
- Logged inputs and outputs
- Escalation rules
After launch
- Monitoring
- Alerting
- Documentation
- Named engineer
What buyers ask before the first call
01Do I have to pay for the Blueprint?+
The Blueprint has a fixed fee, credited in full against the build, so if you go ahead the plan costs you nothing extra. If it doesn't give you a plan you'd act on, you don't pay for it at all. The audit call before it is free. Writing a real plan from your actual systems 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 Blueprint produces a delivery date alongside the scope and the milestone prices, and that date is what we commit to.
03What if we stop after the Blueprint?+
You keep the plan and owe nothing further. It contains the scope, the architecture, the risks and a fixed price for each milestone, written plainly enough to hand to another firm or to your own team. Some clients buy the Blueprint specifically to get a second opinion on a build already underway.
04How do milestones work?+
Each milestone has a fixed price and written acceptance criteria, both set in the Blueprint. You accept a milestone when the criteria pass, and you pay for accepted work, not for hours. Stopping between milestones leaves you with working software and everything shipped so far.
05Who 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.
06Can 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.
07What 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.
