The Buy-or-Build Playbook: AI made building cheap. It didn’t make owning cheap.

Somebody on your team has already done this. They looked at a $400-a-month SaaS invoice, opened an AI coding tool, and had a rough working replacement by Sunday night. It did the three things you actually used. The demo was genuinely impressive. And in that moment the entire buy-versus-build conversation at your company changed — not because the answer changed, but because everyone started answering the wrong question.

The old rule of thumb was simple: building is expensive, so buy unless the thing is your core differentiator. AI collapsed the first clause. Building is no longer expensive. But that rule was always a proxy for a different question, and the proxy is now broken while the real question is untouched.

The real question is not “can we build this?” It’s “are we willing to own this for five years?” Building is a weekend. Owning is a decade. This playbook is how to tell the two apart before you commit.

Step 1: Write down what you're actually replacing

Before any estimate, list what the incumbent tool does that you use. Not what it can do — the feature list is a sales document. What you use. Do this by looking, not remembering: open the tool, check the last 90 days of activity, and write down every distinct workflow someone touched.

You will typically find three tiers:

• The visible core. Three to five workflows that everyone knows about. This is what the weekend prototype rebuilt.
• The quiet middle. Eight to fifteen things a handful of people rely on: an export format, a permission level, a scheduled report, a webhook into something else. Nobody mentions these in the meeting. Every one of them is a support ticket if it disappears.
• The invisible floor. Audit logs, SSO, data retention, backup, uptime, someone to call at 2am, and whatever compliance paperwork your largest customer asks for annually. Nobody uses these. You cannot ship without them.

The weekend prototype covered tier one. Your estimate needs to cover all three. Write the list before you go further — the length of tier two is usually the whole decision.

Step 2: Run the five-year cost, not the build cost

Here is the arithmetic almost nobody does. Take a tool costing $500/month — $30,000 over five years. That’s the number the build case gets compared against, and against a weekend of work it looks absurd.

Now cost the build honestly. A worked example for a mid-sized internal tool:

• Initial build: 3 weeks of one engineer’s time (the weekend prototype covered maybe 25% of the real scope). At a $150k salary fully loaded, call it $12,000.
• Hardening to production: auth, permissions, error handling, the tier-two list. Historically about the same again. $12,000.
• Ongoing maintenance: the number that gets omitted. Assume 4 hours a month forever — dependency updates, breakages, small requests. Over five years that’s 240 hours, roughly $18,000.
• Hosting and infrastructure: modest, but real. $50–200/month. Call it $6,000.
• The bus-factor premium: at some point the person who built it leaves. Rebuilding context costs 2–4 weeks of someone else’s life. $10,000, and it is not optional — it is a certainty on a five-year horizon.

Five-year build total: roughly $58,000 against $30,000 to buy. The tool that looked 60x too expensive is actually about half the cost.

Now invert it. Run the same math on a $5,000/month tool — $300,000 over five years. Suddenly $58,000 is a rounding error and building is obviously correct. That is the real threshold, and it moves with your spend, not with how clever the prototype was.

Step 3: Apply the four gates

Cost is necessary but not sufficient. Run the candidate through four gates. A single failure means buy — these are not scored, they are vetoes.

1. The differentiation gate. If a customer would never notice which vendor you used, this is plumbing. Nobody has ever won a market on a better internal expense-approval flow. Build things customers can feel; buy everything else.
2. The compliance gate. If the tool touches payments, health data, personal data at scale, or anything your auditors ask about, the vendor is selling you their SOC 2, their insurance, and their liability — not their software. Building means absorbing all three yourself. Almost always fails.
3. The integration gate. Count the external systems it must talk to. Zero or one: fine. Two or three: proceed carefully. Four or more: buy. Integrations are where maintenance cost actually lives, because you don’t control when any of them change.
4. The owner gate. Name the specific person responsible for this in eighteen months. Not a team — a name. If you can’t produce one, or the honest answer is “whoever built it, probably,” you are not building a tool. You are building an orphan. Buy.

The one-page decision template

Copy this. Fill it in before the meeting, not during it. If any line is blank, the decision isn’t ready.

• Tool: ______   Current annual cost: $______
• Workflows in active use (from the 90-day log): tier 1: ___   tier 2: ___   tier 3: ___
• Five-year buy cost: $______
• Five-year build cost (build + harden + 4hr/mo + hosting + bus factor): $______
• Gate 1 — would a customer notice? yes / no
• Gate 2 — compliance surface? none / some / regulated
• Gate 3 — external integrations: ___
• Gate 4 — named owner in 18 months: ______
• Decision: buy / build   Review date: ______

The scripts

When someone shows you the weekend prototype. Do not deflate them — that prototype is genuinely valuable as a scoping artifact. Say:

“This is great, and it just told us something expensive: the core is easy. So the decision is entirely about the boring 80% — permissions, the export nobody talks about, who fixes it in 2027. Can you spend an hour listing everything the current tool does that this doesn’t? If that list is short, we build. If it’s long, we’ve saved ourselves six months.”

When a leader says “why are we paying for this, AI can build it.”

“Probably true for the build. The licence isn’t buying the build, it’s buying five years of maintenance, an SLA, and someone else’s on-call rota. Here’s the five-year comparison on both sides. If it still looks wrong after that, I’ll scope the build properly.”

When you decide to buy and want leverage. The build estimate is a negotiating asset. Tell the vendor, in plain terms and without bluffing: “We’ve costed building this internally at roughly $58k over five years against your $30k. We’d rather buy. But that gap is narrowing every year, and at renewal we’ll run the numbers again.” Vendors know this is now true across their whole customer base. It prices better than any threat.

Four failure modes

1. The 80% trap. AI gets you to 80% fast and the last 20% takes as long as it always did — because the last 20% is edge cases, and edge cases are by definition not in the training distribution of common patterns. Teams budget from the 80% and blow the estimate by 4x. Fix: whatever the prototype took, multiply by five for production.
2. The orphan. Built by one enthusiastic person, used by forty, owned by nobody. Runs beautifully for fourteen months, then they leave and it becomes a haunted house nobody will touch. Fix: Gate 4, enforced. A name, in writing, in the ticket.
3. The scope ratchet. You replace one tool. Then someone asks for the thing the old tool did that you skipped. Then someone wants a dashboard. Eighteen months later you maintain an unfunded internal product with a feature backlog. Fix: freeze scope at the tier-one and tier-two list from Step 1, in writing, and treat additions as new decisions with new cost math.
4. Sunk-cost lock-in. Six months in, it’s clearly worse than the tool you cancelled, but reversing means admitting the six months. Fix: set the review date on day one and keep the vendor’s contact. Reverting inside twelve months should be a pre-agreed, blame-free option, not a humiliation.

The one case where building always wins

There is a category the cost math undersells: tools that encode a process nobody else has. If your business does something genuinely unusual — a pricing model, a fulfilment sequence, a quality check that’s yours — every off-the-shelf tool forces you to bend your process to fit their assumptions. That bending has a cost that never shows up on an invoice, and it compounds.

Here, building isn’t about the $30,000. It’s about not slowly converting your distinctive process into whatever the median customer of that vendor does. AI genuinely did change this case, because the tools that used to be too small to justify custom software now aren’t. If a workflow is both unusual and customer-visible, build it — and skip the five-year math, because you’re not buying software, you’re protecting the thing that makes you different.

Run it this week

• Monday: pull your software spend, sorted by annual cost, descending.
• Tuesday: take the top three. For each, do Step 1 — the 90-day usage log, all three tiers.
• Wednesday: run the five-year math on all three.
• Thursday: run the four gates. Most will veto out immediately, which is a fast, correct answer.
• Friday: for anything that survives, book a real scoping session. For everything that didn’t, put the build estimate in your renewal file. It’s worth money at the negotiation whether or not you ever build.

The version of this that goes wrong isn’t the team that builds too much or the team that buys too much. It’s the team that decides based on how impressive the demo was on Sunday night. Building got cheap. Owning didn’t. Price the second one.