How the work runs
The same four phases whatever the project is. The point of running it this way is to force the decisions into the open early, because the ones nobody makes are the ones an AI tool will quietly make for you, in code, where they are expensive to find.
Four phases
Clarify
Week 1We find the decisions nobody has made yet, the ones an AI tool would otherwise make for you, silently, in code. You get a written scope and a fixed price before anything is built.
Plan
Weeks 2-3Architecture, data flow, agent boundaries, and what counts as working. All of it agreed while it is still cheap to argue about, and written down so nobody relitigates it in week six.
Build and verify
Weeks 3-7Small changes, each one run against the evaluation set. You get a live environment in the first week and watch it fill in, so nothing arrives as a surprise at handover.
Learn and adjust
Week 8 onwardReal use produces cases the plan missed. Those become new tests, the system improves against them, and the loop keeps running after handover, with your team or with ours.
What every change travels through
Phases describe the engagement. This describes a single change inside it, from the moment someone edits a prompt to the moment it is serving everybody.
01 change
Something moves
A prompt, a retrieval config, a model version, a line of code. In an AI system all four ship the same way, which is the first thing most teams have to fix.
What stops here: Nothing reaches this pipeline without a review and a reason.
02 suite
The evaluation set runs
Real queries from your staff, with expected behaviour recorded. Not a public benchmark, which tells you how a model does on somebody else's problem.
What stops here: A score below the agreed floor stops here and never reaches staging.
03 shadow
It runs beside the live system
The new version answers the same traffic as the old one without anybody seeing it. Disagreements between the two are the interesting output.
What stops here: Divergence past the threshold holds the release for a human to read.
04 flag
A few per cent of real traffic
Behind a feature flag, on a cohort you choose. Latency, cost per call and the failure rate are watched against the version still serving everyone else.
What stops here: Any of the three moving the wrong way flips the flag back automatically.
05 rollout
Widened in steps
Ten per cent, fifty, all of it, with a soak at each step long enough for a slow problem to surface. Fast rollouts hide exactly the faults worth catching.
What stops here: The previous version stays warm and addressable for the whole rollout.
06 watch
The set grows
Anything that went wrong in production becomes a case in the evaluation set, so the same fault cannot ship twice. This is why the loop is a loop.
What stops here: A rollback is a rehearsed command, not an incident-time decision.
What you can hold us to
- Evaluation before opinion
- Every AI system we ship has a test set drawn from your real queries and a score you can track over time. When we claim something got better, the number comes with it.
- You own all of it
- Source code, prompts, evaluation sets, infrastructure and accounts transfer to you on final payment. Nothing stays licensed from us.
- No model lock-in
- The model sits behind an interface. Swapping it is a config change and an eval run, so you are never stuck with a provider because leaving would cost too much.
- We will talk you out of it
- If your problem is better solved by a form, a query or a rule, we will say so before you have paid for a model to do it worse.
- Fixed scope, fixed price
- You approve a written scope and a number before work starts. Changes get quoted, not absorbed silently and billed later.
- Built to be handed over
- Every project ships with documentation and a training session. If you replace us next year, the next team can read what we left.
Start with the problem
The useful first message is a paragraph about what is not working, not a specification. We come back within two working days.
Start a project