How it runs
Three segments, and two places to stop.
You do not need to arrive with requirements written up. We start on the assumption that they cannot be written yet.
In one sentence
A way of running the work to one standard — starting where requirements cannot yet be written, defining the process, building a structure that leaves records, and moving repeated judgements to the system.
Applies To
Who this fits
A fit
- Operations that run, but whose procedure lives in people rather than documents
- Local subsidiaries with a head-office system that does not match local work, where workarounds have accumulated
- Requests scattered across email and chat, with no way to count volume or waiting time
- The same judgement made by hand every time, where the criteria could be written down
Not a fit
- Nobody who can spare the time to explain how the work runs
- Rewrites of a large system several teams already depend on
- Adopting AI without having settled what it is for
- Day-to-day desktop support and physical infrastructure
How It Runs
Assessment, definition, build
Contract a project as one block and it becomes hard to stop even once you can see it is wrong. The work is split into three segments, and the end of each of the first two is a formal exit.
Assessment
2 weeks · fixed priceCurrent read · three bottlenecks · now / later / never
Exit 1
Requirement definition
Scope settledProcess definition · inputs and outputs · exception list
Exit 2
Build and adoption
One processA working system · handover · failure procedure
You do not need to arrive with requirements written up. We start on the assumption that they cannot be written yet. The usual approach takes in requirements and returns them when they fall short; there is no return step here — segment 2 does that work instead.
The contract can end at either exit. Everything produced through segment 2 is left in a form another firm could pick up and use as it stands.
Deliverables
What is left behind
Each segment leaves documents in a fixed format. If the work ends midway, everything up to that point still stands — including if you take it elsewhere.
Segment 1 · Assessment
- Current-state read
- Where you sit on the two readiness axes, with the reasoning.
- Bottleneck list
- The top three, each with a count of where and how often hands are involved.
- Now / later / never
- Including what not to do, and why it is excluded.
Segment 2 · Definition
- Process definition
- Input, output, owner and completion condition, per step.
- Exception list
- Every departure from the normal path, and how each is handled.
- Data lineage
- Which source each metric is read from. This is the document that stops one number differing between screens.
Segment 3 · Build and adoption
- Decision configuration
- Thresholds and tolerances as values, not code. Changed by the owner without a developer.
- Failure procedure
- The manual path for when it stops. Written before the feature.
- Handover
- Permissions, how to change it, how to roll it back. After handover it runs without us.
Difference
Where this departs from the usual approach
| The usual approach | Here | |
|---|---|---|
| Requirements | Written and submitted by the client | Assumed absent, derived together in segment 2 |
| If they fall short | Returned for rewriting | There is no return step — segment 2 does that work |
| Contract unit | One block | Per segment; the end of each of the first two is a formal exit |
| Stopping midway | Negotiated break | A formal exit. The deliverables remain |
| Automatic decisions | Switched on in full once built | Logic fixed; only its authority moves up, in three stages |
| Connecting to systems | Read and write together | The first connection is read-only |
| Failure planning | Reviewed after the feature is done | The manual path is written before the feature |
| Documents | Assembled at project close | Left in a fixed format at each segment |
This is not a claim that the right column is better. Starting from requirements that cannot yet be written produces this order — and the cost is more time in segments 1 and 2.
Discipline
The order in which automatic decisions are switched on
“What happens when the AI gets it wrong” is the most common question. It is answered with an order, not a guarantee. The decision logic stays exactly as it is; only its authority to act moves up.
The system decides and records, nothing more. Through that period its decisions sit alongside the human ones for comparison, and where they diverge the rules are corrected. Live work is unaffected.
A decision does not take effect immediately. It confirms automatically once a set interval passes, and a person can step in and stop it during that window.
Switched on once stage 1 shows sufficient agreement with human decisions and stage 2 shows interventions have all but stopped.
Where the criteria live — configuration, not code
Thresholds and tolerances are changed by the person who owns the work, without a developer. Every change carries a delay and an effective date, and before release we count how many records would come out differently. Any version can be rolled back at once.
The first connection is read-only
The first connection to a system holding core data is read-only. Every view can be built with reads alone, and that stage is where the meaning of the data is confirmed. By the time writes are needed, the system is already understood.
Before adding, look for a layer to remove
Meeting an awkward manual tool, improving that tool feels natural — and the manual work stays. Where a system already knows the state, the layer that copies it across is treated as something to remove, not improve.
One source per metric, fixed in advance
Reports and historical aggregates come from the warehouse, the state of this moment from the system of record directly, order and customer state from the CRM. Left unfixed in writing, the same metric starts showing different values on different screens.
The manual fallback comes first
For work that stops the day when it stops, the manual fallback is settled before the feature. No payment: a manual invoice. No kiosk: direct entry on the admin screen. Automation without a fallback is not an improvement — it is a new single point of failure.
Same Decision
The same judgement, four projects apart
Not declared as a principle. Recorded as decisions.
| Where | What was done |
|---|---|
| Membership and billing | Found that a billing rule contradicted the system’s own guarantee, and moved the confirmation out of the screen and up to a decision gate |
| Expenses and approval | An item is not passed to approval while any exception raised in validation remains open |
| Voice records | Introduced a confidence convention so that no code could be written on top of an unverified legal fact |
| Decision automation | Split the authority to decide into three stages, raised only after comparison with human decisions |
All four are the same judgement — do not proceed while uncertain. More precisely: build the thing that notices the uncertainty first.
Review
The review — fixed price, fixed output
What comes after depends on what is found. The review has a defined output, so its price is known before it starts.
- Scope
- One process · includes reading the whole flow
- Duration
- 2 weeks
- Price
- Fixed, $2,400
- If it leads to a build
- Credited in full
The output is a read on the current state, three bottlenecks, and a do-now / do-later / do-not list. Those three remain even if you stop at the review.
Two things are needed from your side. One person who can explain how the company’s work flows end to end, and a working session with whoever owns the area that needs improvement. Without the second, the review turns into generalities.
The figures above are for a single process. Where the subject spans several functions or several sites, the review itself is priced separately — and that price is also settled before it starts.
Because it is credited in full, there is only one case in which this stage costs you anything: a review that concludes “not now.” We hold that such a conclusion is worth more than its price.
Instead of saying “it depends on the company,” we say: in this state it takes this many weeks, and one step up it would have taken this many.
What We Turn Down
Work we do not take
- Projects where nobody can spare the time. With no one to ask, the work gets built on assumptions, and the mistake surfaces only once it is finished.
- Rewrites of large systems several teams already depend on.
- Staff augmentation. We build and hand over.
- Physical infrastructure and day-to-day desktop support.
- Adopting AI without having settled what it is for.
What changed is not how capable the tools are. It is the smallest job worth doing. Automation at a scale that used to be abandoned for want of a viable quote now finishes in weeks.
Get in touch — one question
We answer first whether this is a situation that warrants a review, or whether it is not the moment.