Build, Buy, or Wait: An Honest AI Decision Framework
The pressure to "do something with AI" pushes teams to build things they should have bought and buy things they should have ignored. Here's a framework that cuts through it — not as a vibe check, but as a decision you can make in one sitting.
Before you use this tree, make sure the idea survives basic diligence: a specific problem, a success metric, a named owner, and a smallest proof. That's the seven questions worksheet. This post is the fork that comes after those answers are honest.
The decision tree
Work top to bottom. Stop at the first leaf that fits.
Is the problem specific and painful today?
├─ No → WAIT (revisit when pain has a name and an owner)
└─ Yes
└─ Do we have a metric + baseline, and a named owner after launch?
├─ No → WAIT (or fix diligence first — don't fund fog)
└─ Yes
└─ Does a reputable tool already solve ≥80% of this well?
├─ Yes → BUY (integrate, train, measure; don't rebuild commodity)
└─ No
└─ Is this capability core to how we compete
(or so specific that vendors can't fit)?
├─ No → WAIT or BUY-adjacent
│ (tolerate 80%, change process, or park it)
└─ Yes
└─ Can a narrow production slice prove value
in ~2–3 weeks with today's models?
├─ No → WAIT (dated revisit; don't build on hope)
└─ Yes → BUILD (smallest slice; definition of done first)
Optics check (side door): If the honest reason for the project is a press mention, a board slide, or "everyone else is doing AI," kill it regardless of the tree. Shipped software that moves a metric is the only innovation that survives a budget review.
Three mini scenarios
Scenario A → Buy
Situation: A 40-person B2B team wants "AI for meeting notes." Reps already live in a stack that has a solid transcription + summary add-on. Nobody has standardized how notes land in the CRM.
What diligence shows: Problem is real (notes are inconsistent). Metric can be "CRM fields complete within 24 hours of a call." Owner can be RevOps. A vendor already does transcription and summarization well enough.
Decision: Buy the add-on (or turn on the one you already pay for). Spend energy on the habit and the CRM mapping — not on building a custom note bot. Building here is a commodity science fair.
Tell: If a competent stranger could buy the same capability next week, you don't have a build.
Scenario B → Build
Situation: Your product's edge is a domain-specific workflow — say, routing and drafting inside a regulated niche where generic copilots mangle terminology, miss required fields, and can't sit inside your existing system of record without duct tape. You've tested off-the-shelf tools on real cases; they fail the same way every time.
What diligence shows: Problem and metric are clear (e.g., time-to-first compliant draft). Owner exists. Smallest slice is one document type for one team in production. Today's models are good enough when wrapped in your constraints, evaluation, and UI.
Decision: Build the narrow slice. Don't boil the ocean into "an AI platform." Prove the metric, hand off ownership, then expand.
Tell: Build when the advantage is the fit — data path, evaluation, workflow, compliance envelope — not when you merely prefer owning the code.
Scenario C → Wait
Situation: Leadership wants "an AI agent that handles customer success end-to-end." Pain is real-ish (CS is overloaded), but nobody agrees which tickets, which decisions stay human, or what "handled" means. Prototypes look cool; the metric is "reduce workload" with no baseline. A major model upgrade is "any month now," and the plan leans on it.
What diligence shows: Fuzzy problem, no owner, no smallest proof, dependency on future capability.
Decision: Wait. Set a revisit date (30–60 days). In the meantime: pick one painful CS motion, measure it, and try a buy/train path on that slice only. Reopen build when boxes 1, 2, 5, and 7 on the worksheet are fillable without hedging.
Tell: Wait is not cowardice. It's how you fund the projects that deserve a build.
Buy / build / wait — the short version
Buy when the problem is common and a tool already solves it well. Integrate, train, measure. Don't spend your best engineers on commodity.
Build when the capability is how you compete — or is so specific that no tool fits — and a narrow production slice can prove value with what exists today.
Wait when the problem is real but the payoff is fuzzy, ownership is missing, or the plan depends on a model that isn't here yet. Park it with a date. Discipline here is what funds the work that matters.
The trap: building to look innovative
A lot of AI builds exist to be talked about, not used. If removing the press release would kill the project's internal sponsorship, you already have your answer. Use the tree; ignore the theater.
Mapping back to the seven questions
Think of the worksheet as the fuel gauge and this tree as the route:
| Diligence gap | Usual tree leaf |
|---|---|
| No specific problem (#1) | Wait |
| No metric / baseline (#2) | Wait (or diligence first) |
| Depends on a future model (#3) | Wait |
| Tool/habit not exhausted (#4) | Buy (or train) before build |
| No named owner (#5) | Wait — builds without owners become demos |
| Data path unclear (#6) | Pause until written; then re-enter the tree |
| No smallest production slice (#7) | Wait or shrink until a 2–3 week proof exists |
You don't need a workshop to use that table. You need honesty in one sitting.
How to decide in one sitting
- Run the seven questions with the decision-maker present.
- Walk the tree above — out loud, no slides.
- Write the decision in one sentence: Buy X and measure Y / Build slice Z by date / Wait until date, with these three unknowns closed.
- If it's Build, lock definition of done before kickoff (see shipping in weeks).
The goal isn't to build more — it's to build the right things and skip the rest with a clear conscience. If you want a second pair of eyes on that one-sentence decision, that's what a free consultation is for — or start with the readiness scorecard if the real risk is adoption, not architecture.
Frequently asked
When the capability is core to how you compete, no off-the-shelf tool fits, and you have a clear problem and success metric. If a tool already does it well, buy it and spend your energy elsewhere.
Yes. If the problem is real but the value is unclear or the tooling is immature, the disciplined move is to wait and revisit — not to burn a quarter proving an obvious maybe.
Build / buy / wait is the fork after diligence. The seven questions establish whether the problem, metric, owner, and smallest proof are real. This framework decides the vehicle — custom software, a vendor, or a dated pause.