The Audit–Build–Operate model

Key takeaways

• Three engagements with hard edges: a two-week fixed-price audit, a four-to-ten-week fixed-scope build, and an ongoing operate retainer either side can end in 30 days.
• Weekly demos against real data, not slide decks, are what keep a build honest.
• The audit document belongs to the client whether they hire us for the build or not.
• Source code, prompts, credentials, and documentation transfer in full on day one of operate.

What's wrong with most consulting

The default consulting model is built around a quiet assumption: more work is good, and the firm earns more when there is more of it. Everything follows from that. Discovery is open-ended. Scope expands. The statement of work refers to "phases to be defined." Change orders become the business model.

That model is fine if you're buying strategy decks. It breaks down when you're buying a working system, because the thing you actually want, software that runs inside your operation without the consultants in the room, has a specific shape, and a contract that doesn't optimize for that shape will optimize against it.

So we use a different structure: three engagements with hard edges.

I. Audit: two weeks, fixed price

The audit is two weeks and the price is fixed. The deliverable is an operations map, a prioritized list of opportunities, and a 12-month roadmap with an estimate 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 a deliberate constraint. It's long enough to genuinely map a small or mid-sized operation, and short enough that our presence doesn't become a distraction. We sit with the people doing the work, watch the workflows that matter run end to end, read the SOPs that exist and note the ones that don't.

The test we hold the audit to: would the document still be worth the fee if the client walked away right after reading it? It has to be, because the client is free to do exactly that. The framework we run it against is [the five questions every audit answers](/blog/five-questions-every-audit-answers).

The fixed price matters as much as the timeline. Open-ended discovery rewards a firm for taking longer. A fixed price rewards it for being right.

II. Build: four to ten weeks, weekly demos, fixed scope

The build has an agreed scope, an end date, and a weekly demo the client can attend without preparing anything.

The weekly demo is the most important piece. It is not a status meeting, and there are no slides. It's a half-hour working session where we show the actual system running against actual data, in whatever state it's in. If we're behind, the demo shows it. If we built the wrong thing, the demo surfaces it on a Friday in week three instead of at the end of the engagement. (The cost of skipping this cadence is most of [why AI pilots die after the demo](/blog/why-most-ai-pilots-die-after-the-demo): the operator never sees the system on their own data until it's too late to change course.)

Fixed scope sounds restrictive. In practice it's the opposite, because it gives everyone permission to say "good idea, v2 backlog" to the seventh good idea that surfaces mid-build, and to finish the system that was actually scoped. Builds without that discipline quietly grow into a year of work and a system that never ships.

Four to ten weeks is a real range, not a marketing range. One workflow with one integration sits at the short end. Three workflows across two systems with a custom dashboard sits at the long end. We say which end you're on during the audit, along with the assumptions behind the estimate, and if an assumption breaks we say so in the demo, not at the end.

III. Operate: ongoing, with a kill switch

Operate is where consulting models usually go wrong. Either the firm doesn't offer it, and the client is left holding a system they didn't build, or it's an open-ended retainer that quietly turns into rent.

Ours has two properties that keep it honest.

First, either side can end it in 30 days. No penalty, no claw-back. The retainer has to survive because the work is worth it, not because the contract makes leaving expensive.

Second, everything transfers before the retainer starts. Source code, prompts, credentials, documentation, all of it, on day one of operate. The client can fire us and keep the system. That's the point. A retainer you can't leave isn't a service, it's a hostage arrangement.

What the retainer buys is the period when the system is being refined, extended, and stress-tested, plus a direct line to the engineers who built it when something changes upstream.

The checklist

If you're evaluating any firm for this kind of work, ours included, ask for:

• A fixed-scope audit document you own regardless of next steps
• Weekly demos against real data, attended without preparation
• A v2 backlog that's explicitly separate from the v1 build
• Source code, prompts, credentials, and documentation transferred at handoff
• A 30-day exit clause on the retainer, both ways
• Direct contact with the engineers who built the system

If a firm won't agree to those, the engagement is structured for billable hours, not for the system you want.

The point

Three phases, hard edges, weekly demos, real ownership. None of it is novel. What's unusual is treating it as non-negotiable instead of as a marketing line.

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