Twenty minutes, then a map, then a build.

Stage 1: the Leak Check — free, 20 minutes

Not a demo. Not a capability presentation. Twenty minutes of questions about how work actually moves through your business, and where it stalls.

Most of it is listening. The useful information is usually in an aside — "oh, and then Sharon re-types it into the other system" — not in the answer to the question we asked.

Bring the person who does the admin, not only whoever owns the budget. Those are frequently different people, and the second one has a tidier and considerably less accurate picture of how the work actually moves. If only one of them can make the call, make it the first.

The questions we ask, and why they’re not a fixed list

There is no standard set of fourteen questions, and publishing one would be a marketing exercise rather than a method. The questions differ by trade, because the leaks differ by trade. What you ask a signage business about artwork approval has no equivalent in a plumbing business, and asking it anyway wastes the twenty minutes.

What is constant is the shape: we follow one real job from enquiry to paid invoice, and at every handoff we ask who touches it, what they re-type, and what happens when it goes wrong. You can prepare for that without a list — pick a recent job that was annoying and have it in mind.

If you would rather work through something structured first, the buyer’s checklist and the build-vs-buy framework both run in your browser and take about an hour between them.

Stage 2: the Blueprint — what’s in it, what it costs

Fixed fee, quoted before you commit. Delivered in about 3 days.

• Where the leaks areQuantified in hours and dollars, using your numbers rather than industry averages.
• Which are worth fixingAnd which are not. Some leaks cost less to live with than to close.
• Costed optionsIncluding the do-nothing option, costed honestly.
• What we’d do first, and whySequenced by payback, not by what is interesting to build.
• What we’d advise againstNamed explicitly, with the reasoning.

The Blueprint is yours whether or not you build. Take it to another firm if you prefer — it is specific enough to quote from, and specific enough to check their quote against.

Stage 3: build, in two-week increments

Each increment: agreed scope, agreed cost, working software at the end. Not a demo — something you can use.

You can stop after any increment. That is the point of the structure. A twelve-week project quoted as one number is a bet; the same project in six increments is six decisions, and the most you can be wrong by is one increment.

Stage 4: handover — code, docs, keys

Less of an event than it sounds, because repository access has been yours since the first commit rather than arriving at the end. What changes at handover is that the running system, its credentials and its documentation are formally yours, and ownership transfers on payment of the final invoice.

The full set of commitments behind that — hosting, backups, the restore-test date — is on ownership and security.

Stage 5: the check-in nobody else does

The first one happens two days after the proposal goes out. After that we come back to the numbers from the Blueprint and ask the uncomfortable question: did it do what we said it would?

Sometimes it didn’t. That conversation is the most useful one in the engagement, and it is the reason the Blueprint quantifies things in the first place — a promise you cannot check later is just a nice sentence.

It is also the stage most firms skip, and the reason is obvious: a check-in against published numbers is a standing opportunity to be wrong in front of a client. We would rather be wrong early and fix it than have you quietly conclude a year later that it did not do much.