Build vs Buy.

The wedge nobody draws

You're in a board meeting. Someone — usually the most expensive person in the room — asks whether you should build your own AI platform instead of "just paying OpenAI". Someone else says public tools are a data security risk. A third person mentions a vendor pitch they saw last week. The room collapses into a binary and you walk out with a $50K-$70K project on the slate that nobody has stress-tested.

The framing is wrong. Build vs buy isn't a one-time decision, it's a sequence. Buy first to find the workflow that has actual gravity. Watch it for six months. Then build the thin layer of moat around the thing the public stack can't give you. Anyone who tells you to skip step one and start building is selling something — usually their consulting hours.

I've watched four portfolio CEOs spend $200K+ building a custom platform that re-implemented 80% of what ChatGPT Teams already did, then quietly shelved it. Every one of them would have caught the mistake in week three of buy-first, because the operator using the public tool would have told them "this works, I just wish I could do X". X is the thing worth building. Everything else is reinvention with extra steps.

Three signals that say "stop buying, start building"

1. Data you legally can't send out.

Specific shapes, not vague gestures at "privacy". Health (HIPAA PHI, patient charts, anything that touches a covered entity). Legal (privileged communications, sealed records, attorney-client work product). Security (incident response intel, threat models, anything that becomes a weapon if it leaks). Customer PII at scale — not "we have emails", but "we have 4M customer records and a regulator who reads our data processing agreements".

If your data isn't on this list, the data-security argument is decoration. Most companies don't have data they can't send to Claude or GPT — they have data they're worried about, which is different. The fix for "worried" is a DPA, an enterprise contract with a no-training clause, and SOC2 evidence. The fix for "legally cannot" is a private deployment, which is what you actually build.

2. A workflow you've already de-risked.

Six months minimum on the public stack. You know exactly what the agent does, what it costs per run, where it fails, what the human does to catch the failure, what the operator wishes were different. If you can't answer those four questions in two sentences each, you don't have a workflow — you have a wish. Building on top of a wish is how $55K MVPs become $200K post-MVPs that still don't ship.

The shape of a de-risked workflow: someone on your team is annoyed every day that the public tool can't do that one thing, and the annoyance is worth more than $5K/month to fix. That's the brief for the build. Less specific than that, you're not ready.

3. A moat that only exists if you own the stack.

This is the one most boards skip. The point of building isn't to save money — public tools are almost always cheaper at year one. The point is to compound something the vendor will never compound for you. Knowledge retention (your fine-tune learns from every closed deal and your competitor's doesn't). Custom UI (your operators move 3x faster because the interface is shaped to their workflow, not OpenAI's). Embedded product (you ship AI features to customers and the platform is the product, not a tool you use internally).

If none of those apply, you don't have a moat — you have a vendor dependency you're choosing to absorb. Absorbing a vendor doesn't make you faster. It usually makes you slower with more headcount.

The cost ladder you're actually staring at

Here are the numbers from a real custom-platform proposal one of my portfolio companies received last week. They're typical for a US-based shop building a focused operator platform with one to two senior engineers. They're not theoretical.

So the napkin number for "we built our own thing" is roughly $110K to $130K all-in for year one, assuming the MVP ships on schedule and the post-MVP scope doesn't bloat. Both of those assumptions are wrong about half the time.

The numbers nobody puts on the slide:

• Maintenance. Year two isn't $0 — it's roughly 60-70% of year-one post-MVP spend, every year, forever. You're now running a software product.
• The engineer who leaves. The one who built it. Their replacement spends 2-3 months reverse-engineering the codebase before they can ship a single feature. Budget the gap.
• Model deprecation. Whichever model you fine-tuned on gets retired in 18 months. You're now paying for a migration you didn't plan, or running on a model the vendor has stopped patching.
• The API change that breaks staging. Anthropic or OpenAI ships a breaking change in a minor version. Your platform is down for a day. The on-call cost is real.

None of these are deal-killers. They're just the part of the bill that doesn't appear in the proposal and shows up in year two.

The ROI defense (the honest version)

The pitch in every custom-platform proposal sounds the same: "this will let you reduce a 5-person team to 3, plus knowledge retention, plus scalability." I've heard it four times this quarter. It's directionally true and quantitatively overstated.

The 5-to-3 claim has been oversold across the industry. The honest number, based on what I've actually watched happen in portfolio companies that did the build: roughly 5-to-4, with throughput up 30-50%. You don't replace a person — you give four people the capacity of six. The headcount line doesn't drop as much as the pitch says. The output line goes up more than the pitch credits.

The soft benefits the CFO didn't ask about, in descending order of how much they actually matter:

1. Knowledge retention. Every closed deal, support ticket, and meeting transcript becomes training signal for next quarter. The vendor stack throws this away. You don't. Over two years this is the moat that compounds the hardest.
2. IP ownership. The prompts, the fine-tunes, the eval harness — these are assets. On a vendor stack they're a config file. On your stack they're on your balance sheet.
3. Scalability. Not the one in the slide deck. The real one: you can ship a fifth workflow in a month instead of negotiating a new vendor contract for two.

Note what's not on this list: cost savings. Building your own platform is not cheaper than buying. It's different. If your case rests on "we'll save money", the case is weak. If it rests on "we'll own something that compounds", the case is strong.

The buy-side that often wins

The unfashionable truth: for most companies under $50M revenue, the right answer is buy. Not because building is bad — because the moat from using public tools better than your competitors is real, and it's available next week instead of next year.

Everyone in your category has access to the same Claude and the same GPT. The differentiator is the operator who knows where to point them, the prompt library that's been tuned for 90 days, the cron schedule that wakes them up at 4 AM Eastern, the eval harness that catches drift before it ships. None of that is on a vendor's website. All of it is yours to build on top of the public stack, for ~$1-3K/month in API spend instead of $110K+ in custom build.

If your operators can articulate what makes them better at running the public stack than the team next door — that's the moat. The platform underneath is the boring part.

A decision matrix that's not from a McKinsey deck

Score each question 1-5, where 1 means "definitely not us" and 5 means "this is exactly us". Sum the score.

Score > 18: build. You have legal pressure, operational clarity, a moat you can articulate, the team to maintain it, and a place to ship it. Approve discovery this week.

Score < 12: buy. Sharpen the operators on the public stack. Spend the $110K you'd have spent on the build on hiring one more operator and tripling your prompt library. You'll be ahead in nine months either way.

Score 12-18: buy-now-build-the-moat-you-find. Run the public stack hard for two quarters with explicit "what would we build" tracking. At the end of Q2 either the score is > 18 with a concrete brief, or it's settled below 12 because the public stack handled it. Don't decide today.

What the wrong question costs you

The wrong question is build or buy. The right question is which one teaches you the moat fastest. Buy is faster to learn. Build is slower to learn but lets you keep what you learned. The sequence — buy, learn, then build the specific thing the learning surfaced — is almost always cheaper than committing to either in isolation. The companies that get this wrong are the ones who treated it as a one-time vote instead of a two-step play.

Companion piece: The case for the AI spend — 600 words you can forward when the finance side of this conversation gets stuck. For the technical layer on what AI actually costs once you've decided to run it, see Ch 29 — Why Is My Bill So High?