The Audit–Build–Operate model

Key takeaways

• Three engagements with hard edges: a 2-week fixed-price audit, a 4–10 week fixed-scope build, and an ongoing operate retainer with a 30-day exit clause on either side.
• Weekly demos against real data — not slide decks, not status meetings — are the cadence that keeps the build honest.
• The audit document belongs to the client whether they hire us for the build or not. If it doesn't have value when we walk away, it wasn't honest.
• Source code, prompts, credentials, and documentation transfer fully on day one of operate. The retainer is a service relationship, not a hostage situation.

What's wrong with most consulting

The default consulting model in this industry is built around an unspoken assumption: more work is good, and the firm gets paid more when there is more work. The economics flow from that. Discovery is open-ended. Scope expands. The statement of work refers to "phases to be defined." Change orders are the business model.

That model is fine if you're buying strategy decks. It is structurally broken if you're buying a working system. Because the thing you actually want — a piece of software that runs in your operation on a Tuesday morning, without anyone from the consulting firm in the room — has a very specific shape, and any contract that doesn't optimize for that shape is going to optimize against it.

So we don't use that model. We use three engagements with hard edges. Here is the structure, and more importantly, here is why each piece is the way it is.

I. Audit — 2 weeks, fixed price

The audit is two weeks. It is fixed price. The deliverable is an operations map, a prioritized opportunity matrix, and a 12-month roadmap with hard numbers attached to each item — what it would cost to build, what it would save, what it depends on, and how long it would take.

Two weeks is not a guess. It's the length of time it takes to genuinely map a small or mid-sized operation without our presence becoming a distraction. We sit with the people doing the work. We watch full passes of the workflows that matter. We read the SOPs that exist and find the ones that don't. We come out the other side with a document that the client can use, regardless of whether they hire us for the next phase. That's the test we use to know if the audit was honest: does the document still have value if we walk away after it? The framework we run it against is [the five questions every audit answers](/blog/five-questions-every-audit-answers).

The fixed price matters too. Open-ended discovery rewards us for spending more time. Fixed-price discovery rewards us for being right. We would rather be the firm that gets it right in two weeks than the one that bills for four months of mapping.

II. Build — 4 to 10 weeks, weekly demos against fixed scope

The build phase has a hard scope, a hard end date, and a weekly demo cadence the client can attend without preparing.

The weekly demo is the most important piece of this. It is not a status meeting. It is not a slide deck. It is a thirty-minute working session where we show the actual system, running against actual data, in whatever state it currently is. If we're behind, the demo shows that we're behind. If we built the wrong thing, the demo surfaces it on a Friday instead of in week eight. The cadence is what keeps the project honest. (The flip side of skipping this cadence is described in [why most AI pilots die after the demo](/blog/why-most-ai-pilots-die-after-the-demo) — most of them die because the operator never saw the system running against their own data until it was too late.)

Fixed scope sounds restrictive. It is the opposite. Fixed scope means we can say no to the seventh good idea that surfaces in week three, defer it to a v2 backlog, and finish the system that was actually scoped. The alternative — the scope-creep build that keeps growing — is how most engagements quietly turn into a year of work and a system that never ships. The discipline of saying "great idea, into the v2 backlog" is what makes the build finite.

Four to ten weeks is also a real range, not a marketing range. Some builds take four weeks because they're one workflow with one integration. Some take ten because they're three workflows across two systems with a custom dashboard. We scope honestly during the audit and we tell the client which end of the range they're on, with the assumptions we used to get there. If those assumptions break, we tell them in the demo, not at the end.

III. Operate — ongoing retainer, with a kill switch

Operate is the part of the model most consulting firms get wrong. Either they don't offer it, and the client is left holding a system they didn't build, or they offer it as an unconditional retainer that quietly turns into rent.

We do it differently in two ways.

First, the operate retainer has a kill switch. Either side can end it in 30 days, no penalty, no claw-back. The retainer survives because the work survives, not because the contract makes it expensive to leave. We have lost retainers this way — clients have ended them when the system was stable and didn't need us — and we think that's correct. The retainer is for the months when the system is being refined, expanded, or stress-tested. It is not a tax on owning the system we built.

Second, the retainer is for a person, not a ticket queue. Clients on retainer have a direct line to the engineer who built the system. Not a support address. Not a project manager. The person whose hands are on the codebase. That sounds expensive. It is, in fact, less expensive in total — because the layer of translation between operator and engineer is where most retainer money is wasted, in every other firm's model.

Why this works

The three engagements together encode a small number of beliefs about how this work actually has to be done.

We believe scope creep is the enemy of shipping, so we put a hard edge around every engagement. We believe transparency is what makes the work survive, so weekly demos and inspectable systems are non-negotiable. We believe ownership of a system is binary — the client either owns it or they don't — so source code, documentation, credentials, and operational knowledge transfer fully on day one. The retainer is a service relationship, not a hostage situation.

These are not innovations. They are descriptions of what it actually takes to make AI hold inside a small or mid-sized operation. We have arrived at them by watching the alternatives fail. We're not the only people who think this way, but it's still unusual enough in this industry that it shows up as a difference in the room.

The deliverable list

If you're evaluating an AI consulting engagement — ours or anyone else's — these are the things the model should produce. Tell us if you find a firm whose default contract includes all of them:

• A fixed-scope audit document the client owns regardless of next steps
• Weekly demos against real data, attended without preparation
• A v2 backlog distinct from the v1 build, with explicit deferrals
• Source code, prompts, credentials, and documentation transferred on day one of operate
• A 30-day exit clause on the retainer, both ways
• Direct contact with the engineers who built the system, not a queue

If a firm can't agree to those, the engagement is structured for billable hours, not for the system you actually want. There is no version of this model that ships a system that holds without those pieces. We've tried. They don't.

The point

Three phases, hard edges, weekly demos, real ownership. Nothing about that is novel. What's unusual is treating those as non-negotiable rather than as a marketing pitch.

The consulting model most firms use is built for change orders. This one is built for shipping.