How it runs
What happens in an engagement, in the order it happens. The method first, in its own terms; what each step replaces on an agency’s bill is a separate table at the end.
An engagement as four fixed points on one line: the call, which is yours; a prototype and an architecture out of the transcript; a live board you can open whenever you want; and a handover with three tests to pass. Status meetings are marked as absent.
Steps
You say what you’re thinking. I don’t ask how the software should work, because you don’t know yet and asking forces the decision early.
Rather than interview you into a document, the fleet builds something that embodies the idea and you react to working software. The building is the requirements process.
Each version moves something. Features that felt critical turn out to be later work, and things nobody could articulate turn out to be first.
Under a hundred job boards, or a set of property CRMs, or every assistant’s private habits, there is one shape. Finding it is the architecture, and it is the part an agent can’t do: agents fill a shape in; they don’t find it. This is the step that decides whether the other four work.
Bare-metal Docker on commodity servers — plain machines, in your own accounts — conventional enough that the next person can read it.
Then the version repeats: another week of scoped work, built on the last, with something new running at the end of it, until you decide there isn’t another one. What happens to the code and the accounts when you stop is in the terms.
Fleet
Nobody reviews the agents while they write. Given room, an agent invents work that doesn’t need doing, so I let the fleet run and bin whatever comes back wrong. What survives is architecture I’ll put my name on.
That is a real risk and it is worth naming: the review is at the output, not the keystroke. It is why the handover is rehearsed in the first version rather than promised for the end, and why the decision records are written as the calls are made.
The supervision loop, as one line: direction goes to the fleet, which builds with no review while it writes; what the fleet produces reaches a single human review at the output; what survives that review is architecture with my name on it, and what does not is binned.
Proof
These are what a review at the output costs.
The first two, custody and the documentation tests, are also written into the terms as the custody and acceptance clauses, because they change what you sign, not just what you’re told. The other two are how the work is done.
The repository lives in a GitHub or GitLab organisation in your company’s name, and the cloud accounts are opened in your name. The owner field on day one is the proof, and someone you didn’t hire can verify it from a printout in under a minute. The escrow conversation is moot before it starts, because the code never had a custody problem.
Written before work begins: it is read by someone who didn’t write it, it runs on a fresh machine from a freshly provisioned account, and it is signed off against the agreed scope. If any test fails the work isn’t done, at no extra charge and inside the same version. For a codebase a fleet wrote, the fresh-machine test is the one that matters most, so it is the one that is run first.
In the first version, someone who didn’t write the system runs it through those three tests. A tested handover is evidence. An untested one is a claim. If the drill fails, work continues at the same price until it passes — or the documentation ships as it stands and the next version is yours to start or not.
Every architecture call, dated, with the reasoning and the alternative that lost, delivered with the work. This is how you check that a human made the decisions and not the fleet, and it means whoever you ask to look at the work can do the looking without me in the room.
Bill
The method above stands on its own. This is the comparison, in one place: the line item an agency charges for at each step, and what is there instead.
| Step | What an agency bills for | Here |
|---|---|---|
| 01Direction | The written brief, and the misreading that follows one. | No brief. You give direction, and the first version stands in for it. |
| 02Build to think | The discovery phase, and its invoice. | The scoping call, then the first version. You pay for a version, not for a phase. |
| 03Iterate | The feature built before the real one was known. | Every week of a version moves one thing, so the wrong feature never gets more than a week. |
| 04The shape | The bespoke one-off, and its maintenance bill. | One shape under the product, so one thing to maintain. |
| 05The fleet | The five-person delivery team, and the DevOps seat. | One architect deciding, a fleet building, on your own servers. |
Step four is why the comparison on the price page is against a team rather than one engineer: one architect finds the shape, and the fleet does the filling-in that a team of ten would otherwise be doing.
You get four answers: what is buildable, what I would build first, what is hardest, and what I would talk you out of.
