Picture the firm that came home from the conference sold on build. The Champion spent a month of evenings on it and shipped five agents: document intake, workpaper prep, the client-email drafts. (Agents, if you’re joining here: AI that carries out multi-step work on its own.) Six months later three of the five are quietly broken, nobody noticed until a client did, and the firm concludes building was the mistake.
It wasn’t. The mistake was answering buy-vs-build by looking at the apps. In part 1 we unbundled what an app actually sells you: intelligence, interface, harness, janitor, pricing wrapper. In part 2 we read the pricing as a risk contract. The last question is who should supply those layers for your firm, and the answer isn’t on any vendor’s website. It’s in your operations.
Problem first, or you lose either way
At Engage this June, one warning came from session after session: buying a tool is not a strategy. Building one isn’t either. Start from the tool, bought or built, and you get the bolt-on trap in procurement form: something impressive attached to a workflow nobody redesigned, solving a problem nobody defined.
The sequence that works runs the other way. Define the problem, unbundle what solving it requires, and then decide who supplies each layer. Sometimes the answer is a vendor. Sometimes it’s your own agent. The point is that it’s a per-layer decision, not a tribal one.
Build-readiness is about your firm, not the app
AI moved the cost of building to a weekend. It did nothing to the cost of keeping. The janitor work from part 1 (model migrations, regression testing, quality monitoring, documentation) lands on someone in your firm the day you build, and it never stops landing.
So build-readiness is not a property of the app you want to replace. It’s a property of your operations: does the maintenance loop exist, and does it have an owner? A firm that captures corrections, tests output when models change, and gives one named person, usually the Champion, ownership of the mop can self-supply the harness and the janitor, and keep the vendor’s margin for itself. A firm without that loop doesn’t have five agents. It has five future incidents.
The packaging premium
If that loop doesn’t exist in your firm yet, buying is not a failure. It’s the rational move, and it deserves an honest name. Call it the packaging premium: you’re paying the vendor’s margin for their harness and their janitor, packaged so your team doesn’t have to supply either. Fairly priced, that’s some of the best money in your budget.
The failure mode isn’t paying the premium. It’s paying it while believing you bought the intelligence: subscription prices for a commodity, with the real value unexamined. Know which layers you’re renting, and the premium becomes a choice instead of a habit.
One question per layer
So here’s the renewal checklist the series has been building toward. For each problem you’re solving, not each tool you own, ask five questions, one per layer.
The intelligence: could our own AI do this work today? The interface: which screen are we paying for: the transaction screen that agents are steadily emptying, or the exception queue where a human reviews the work and stands behind it? That queue is the durable part; the interface of the future is a review queue.
The harness: how hard is client-data scoping for this problem, and can we honestly match the vendor’s? The janitor: who owns the upkeep loop: do we have that person, or are we buying the vendor’s? The pricing wrapper: who carries the token risk (the metered cost of AI consumption); who chooses the model doing the work; and what does the pricing unit force us to adjudicate? A cheaper, nearly-as-good model arrives every few months now; the saving only reaches firms whose tools let them switch.
One check sits outside the layers: vendor mortality. Before you build a workflow on anyone, ask what happens when the platform absorbs their layer. Xero just did it to document capture. Rails help, but nothing makes a vendor immortal.
The answer changes as you do
Build-readiness isn’t fixed. It grows the way every AI capability in your practice grows: one problem, one loop, one owner, and each layer you learn to supply moves the next renewal’s answer. That’s the real reason buy-vs-build has no tribal answer: the firm asking is a moving target.
So before you cancel a subscription or build a single agent, answer the only question the conference stages skipped: which layers can your firm actually supply, and who owns the mop?
If you want a structured read on that before your next renewal, take the free AI Readiness Scorecard at theaiaccountant.ai/scorecard. Twenty-five questions, five minutes, and it scores the operating maturity this article has been describing: workflow automation, deliverable quality, team capability, data and context readiness, and advisory scalability.