Four weeks. One job. In production, in your codebase.
An engineer joins your team, changes how one job gets done, and leaves. What stays is the job running in production and a record that proves every decision the AI made was allowed.
Why it is four weeks and one job.
- A pilot that runs for six months proves the tool works, not that the work is under control.
- A discovery phase produces a document, and the product is unchanged at the end of it.
- A team of consultants leaves, and nobody inside owns the way the work now gets done.
- The longer the engagement, the harder it is to say what changed because of it.
- One job, measured against the old way, is small enough to judge honestly.
Small enough to decide on. Real enough to keep.
What happens, and when.
The durations are the commitment, not an estimate.
Week 1
The baseline
We agree the job, what the AI is allowed to do in it, and who signs. All of it written down before anything runs, including how we will tell whether it worked.
Weeks 2 and 3
The build
Our engineer works in your repositories, next to your developers, in your standups. The old way and the new way run side by side, so you can see the difference before you rely on it.
Week 4
The handover
The job goes into production and your team takes it. We walk your engineers through the rules, the approval points and the record, and leave the playbook with them.
Week 4 on
The proof
Every decision the AI makes is still checked against your rules before it happens, and still recorded. That does not stop when we leave. You can run it without us; we maintain it if you want.
Four people, named.
Your engineer
One of ours, full time, for the four weeks. They write code in your repositories, follow your conventions and answer in your chat.
Your developers
They review every change as they would any other. Nothing lands because an agent proposed it.
The person who signs
Named in week one. They release the decisions that carry consequence, and the record says so.
Simon and Jason
On the first call and every one after, on scope, delivery and the record you keep.
What is yours at the end of week four.
- The job, live, in your product.
- The code, assigned to you in writing.
- The rules for what the AI may do, owned and changeable by your team.
- The record of every decision, replayable any day.
- The check, still running on every decision.
- The playbook, so a new engineer can run it without us.
When someone asks how this job is done now, what do you show them?
What the AI is allowed to do is written down first.
Every decision is checked against those rules before it happens.
A named person signs it off. The check produces the evidence; a person judges.
You can replay the whole history any day and get the same answer.
If anyone changes it later, it shows. Patent pending, UK application GB2620101.2.
That is what a deployment leaves running for your job. In the accessibility product today, a person on your team accepts every finding before it reaches your record.
Who this is for.
- Teams with one job they have been asked to hand to AI, and a date by which it has to be real.
- Regulated businesses that have to show how the work is done, not only that it works.
- Engineering leaders who want the setup owned inside the team afterwards.
Not for
A long transformation programme. This is one job, four weeks, and a handover.
Two people, on every call and in your standup.
Simon Milner, Founding Architect
He designed the record: what the AI is allowed to do, checked before it acts, and replayable afterwards. Twenty-five years in Silicon Valley before that.
Jason Crispin, Founder
He owns the customer side of every deployment: what the job is, what it is worth, and that it lands. He is on the first call and every one after.
Patent pending, UK application GB2620101.2. Meet the team
Four weeks, then it keeps proving itself.
Week 1
The baseline
What the job is, what allowed means for it, and who signs. Written down before anything runs.
Weeks 2 to 4
The build
Our engineer works in your codebase next to your developers. The old way and the new way run side by side.
Week 4 on
The proof
Every decision checked and recorded. Replay it any day. We maintain it, or you run it without us.
What you keep
- The job, live, in your product.
- The code, assigned to you in writing.
- The record of every decision, replayable any day.
- The check, still running.
What people ask.
Why four weeks?
Why four weeks?
It is long enough to change how one job is done in a real codebase, and short enough that you can decide on it without a procurement cycle. If your job does not fit in four weeks, we say so on the call rather than stretching it.
Are you consultants or engineers?
Are you consultants or engineers?
Engineers. The market calls them forward deployed. Ours ships to production in your repositories. You are not left with a slide deck.
What do you need from our team?
What do you need from our team?
A named owner for the job, a developer who can review, and the person who will sign. Access to the repositories and environments the job touches, which you can revoke any day.
What happens if it does not work?
What happens if it does not work?
The old way is still running beside the new one, so you can stop. You keep the code, the rules and the record of what was tried.
What happens after the four weeks?
What happens after the four weeks?
Your team runs it, the check keeps running on every decision, and you can replay the history any day. We maintain it if you ask.
What does it cost?
What does it cost?
Scoped on the call, because it depends on the job. You leave the call knowing what it would cost and what you would keep.
Bring one job.
Thirty minutes with Simon and Jason. You leave knowing what it would take, what you would keep, and what it costs. If the honest answer is not to use AI for it, we will say so.