Build or Buy?

"Build or buy?" looks like a binary. It isn't.

Picture this: a vendor demo, slide 4. On the left, a $48k/year contract. On the right, a back-of-envelope: "two engineers, six weeks, call it $80k." Building wins on the slide. Six months later, the team is still maintaining it, one of those engineers has rotated off, and nobody can find the original spec.

The slide almost always understates the cost of building and overstates the cost of buying — because both options have a long tail of expense that doesn't show up at the moment of decision.

The actual question isn't "what costs less to start?" It's where does this capability live in three years, and who's still paying to keep it alive? That framing changes most build-vs-buy debates from a debate about price tags into a debate about ownership.

The true cost of each option

What "build" actually costs

Build looks cheap because the only line item you see is the initial development. The hidden costs that follow:

• Maintenance, forever. Bugs, security patches, dependency upgrades, changing requirements, the engineer who originally wrote it leaving — all paid out of your roadmap budget every quarter from now on.
• Specialist talent to run it. A payments system needs people who understand payments. A search system needs people who understand search. You either hire that expertise or you accept a worse version of it.
• Opportunity cost. Every quarter you spend on infrastructure your users will never see is a quarter you didn't spend on something they would.

What "buy" actually costs

Buy looks predictable because the price is in the contract. What's not in the contract:

• Pricing power tilts to the vendor over time. The longer you depend on them, the harder they are to leave, and the more leverage they have at renewal. The renewal that doubles is one of the most common surprises in this space.
• Lock-in compounds. Your data is in their schema. Your workflows are built around their UI. Your engineers know their API, not the next vendor's. "We'll switch if it gets bad" gets less true every year.
• Customization ceiling. What the vendor doesn't support, you don't get. If your differentiator depends on something they don't offer, you're stuck waiting for their roadmap.
• Integration friction. Their data model is not your data model. Stitching them together is real engineering work that the vendor's website doesn't price in.

The differentiation test

The single most useful rule in this space: build the things that make you you, buy the things that are table stakes.

Stripe, Auth0, Datadog, SendGrid, Twilio — these companies exist because hundreds of others decided that payments, auth, monitoring, email, and SMS are table stakes (meaning capabilities everyone needs but nobody competes on). None of those buying companies became great because their auth flow was uniquely good. They became great by being free to spend their engineers on the thing customers were paying them for.

The mirror-image mistake is just as common: buying the thing that's actually your differentiator. If your product's value depends on a custom recommendation engine, and you outsource the recommendation engine to a vendor, you've handed your moat to a third party. Renewal time will not feel good.

Two questions that clarify almost any debate

• "If we did this exceptionally well, would users notice or care?" If no — buy. If yes — keep asking.
• "If we did this badly, would it kill us?" If yes — own it. (You can still buy infrastructure underneath, but the layer that touches the user has to be yours.)

The vendor questions PMs forget to ask

Vendor demos are optimized to show the price-on-day-one and the feature-on-day-one. The interesting questions are about year three and incident two. Bring these into the procurement conversation:

1. "What does this cost at 10× our current usage?"

Per-seat and volume-based pricing curves often surprise. Get the actual price at projected scale before you sign — not the price on the marketing page.

2. "What does data export look like?"

Can you get your data out in a format you can use? In what timeframe? What does the vendor charge to do it? "We can export" is a different answer from "you'll get a 14-day window and a CSV per table."

3. "What's their incident history?"

A vendor with no public status page is itself an answer. Look for honest postmortems, not just uptime numbers. A vendor that publishes blameless incident write-ups is one that takes reliability seriously.

4. "What's the contract minimum and the auto-renew clause?"

Multi-year lock-in with auto-renewal is the most common quiet trap in vendor contracts. Read it before you sign, not when you're trying to leave.

5. "Who else is on this — and what do they say when something goes wrong?"

A reference call with a current customer is the single best signal you can get. Ask specifically about their last incident with the vendor — what happened, how the vendor responded, how long resolution took.

The middle option: libraries and open source

"Build vs buy" hides a third option that often wins: using an open-source library or framework. You don't write the thing from scratch, but you also don't depend on a vendor — you take someone else's code and run it yourself.

The trade is that you swap vendor risk (they raise the price, they discontinue the product) for maintenance risk (the library goes unmaintained, a CVE drops, a breaking upgrade lands at the worst time). For mature, widely-used libraries, this is usually a great deal. For a single-maintainer project that's slowing down, it can quietly become a long-term liability.

The "what if it goes unmaintained?" diagnostic

Before adopting an open-source library, ask: if this project went unmaintained tomorrow, what would we do? If the answer is "fork it and pay someone to keep it alive," budget for that as a real possibility. If the answer is "we'd be in serious trouble" — treat the choice with the same skepticism you'd bring to a small, fragile vendor.

What changes when AI is in the loop

The question: When does "build with AI" beat both?

What's changed. There is a real third option on the table now, sitting between "build it from scratch" and "buy a vendor": build it ourselves, but with AI doing the rote parts. That shifts the math in a few specific directions:

• Internal tools that used to fail the cost-benefit test (custom dashboards, one-off admin panels, glue scripts between SaaS tools) now fit comfortably inside a single sprint. The "we don't have time, just buy a tool" answer is less automatic than it was.
• Custom integrations between two vendors you already pay for — historically a common reason to buy a third vendor (an iPaaS, a workflow tool) — are increasingly cheap to build directly.
• Domain-specific small features that no vendor would ever build for your exact workflow are now reasonable to own. The long tail of useful internal capabilities gets longer.
• Some categories of vendor are themselves AI-native and pull ahead — analytics tools that summarize naturally, support tools with strong agent-assist, dev tools that catch real bugs. The "buy" side of the equation also got a power-up.

What hasn't changed. The differentiation test from Section 3 is almost completely unaffected:

• Specialist domains still benefit enormously from buying. Payments, identity, fraud, observability, deliverability — these aren't expensive because they're hard to write; they're expensive because they're hard to operate correctly. AI helps with the first part. It doesn't help with the second.
• Maintenance burden of self-built code is unchanged. AI helps you write a system; it doesn't help you keep it running for five years through six engineer turnovers and a major framework upgrade.
• Network effects, ecosystem integrations, and proprietary data moats that vendors enjoy don't go away because you can now generate code faster.
• Buying remains the right answer for anything where the failure mode is "regulator calls" or "money disappears." Don't AI-roll your own KYC.

What to watch for. The cheap-build era has a specific set of failure modes that PMs are well-positioned to catch.

1. The "we could just AI it" trap

Every team in 2026 thinks they can build their own version of the SaaS tool they currently pay for. Most shouldn't — not because they can't write the initial version, but because the cost moves from "build the thing" to "run and own the thing forever," and that ownership cost looks roughly the same as it always did.

2. Vibe-coded sprawl

When custom tools are cheap to build, they multiply. Without discipline on what graduates from "demo" to "production and supported," you accumulate a long tail of half-owned internal apps that somebody, eventually, has to keep alive.

3. Vendor evaluation has a new question

Add to your vendor diligence: is this vendor using AI to do something we couldn't reproduce? If yes — proprietary models, fine-tuned on data they have and you don't — they're pulling further ahead, and "we'll just build it" is more wishful than it sounds.

4. Open-source AI tooling churns fast

A library you adopt today may be obsolete in six months as the ecosystem moves. A vendor whose roadmap absorbs that churn may be worth more than they used to be, not less.

5. The new buy-build matrix has a third axis: data

Whoever has the data gets the best AI-assisted product. If the vendor has more relevant data than you do, buying gets you their model's intelligence. If you have the data, building gets you an asset they can't match. Notice which side you're actually on before deciding.

The honest read: AI lowers the cost of writing custom code, which makes the build side more attractive on the margin — especially for internal and long-tail use cases. It does not change the cost of operating, maintaining, or specializing in a domain, which is most of why anybody bought from vendors in the first place. Use the new capability where it changes the answer; don't let it tempt you into rebuilding things you were rightly buying before.

PM Playbook — Questions to ask

The next time the team debates build vs buy, try these:

• If we did this exceptionally well, would users notice or care? — differentiation test, buy side
• If we did this badly, would it kill us? — differentiation test, build side
• What does this cost at 10× our current usage? — pricing curve discovery, not the marketing page
• What does data export look like — format, timeframe, vendor charge? — your escape hatch from lock-in
• What's the contract minimum and the auto-renew clause? — read it before you sign, not when you're trying to leave
• What's the vendor's incident history — and can we talk to a current customer about their last bad week? — reality-check vs sales pitch
• If we build, who maintains this in year three after the original engineer rotates off? — the hidden cost of building
• Does the vendor have data we'll never have? Do we have data they can't access? — the new AI-era axis

These eight questions alone will keep your team out of the two most expensive mistakes — buying your moat and building your table stakes.