Decide by mapping the capability, not the tool: build what's differentiating and still evolving, buy what's commodity and stable, and wrap — buy the capability but build a thin internal interface — when you want vendor flexibility without ownership risk. Score every option against total cost of ownership across a decade, not a single sprint estimate.
Quick answer: Build what's differentiating and still changing shape. Buy what's commodity and stable. Wrap when you need vendor flexibility without owning the plumbing underneath it — and score every path against ten years of total cost, not one quarter's estimate.
What "Build vs. Buy" Really Means for a Platform Team
For platform teams, build vs. buy is really a question about where scarce engineering attention should go: toward capabilities that make your product genuinely different, or toward plumbing every other company also needs. Frame it as an attention-allocation problem, not a procurement problem, and the right call gets much clearer.
Most build-vs-buy conversations start in the wrong place — a spreadsheet comparing sticker price against an engineering-hours estimate. That framing almost always favors building, because engineers price the first release, not the years of upkeep after it ships.
Platform teams are especially exposed to this trap. Unlike a feature team shipping to end users, a platform team's "customers" are other engineers, and as the complete guide to the platform PM role lays out, that internal-facing position makes it easy to justify building almost anything as "strategic infrastructure."
The healthier question isn't "can we build this?" Of course you can — most software is buildable. The real question is whether building it earns a durable advantage, or just occupies your best engineers with something a vendor already solved for less.
Three questions cut through most of the noise:
- Would a customer pay more, or churn less, because your version of this is better than a competitor's off-the-shelf equivalent?
- Is the underlying problem still changing shape, or has the market already converged on a standard solution?
- Would owning this for the next 5–10 years be a strategic asset, or a standing tax on your roadmap?
Why Engineers Default to Build — and Why Leaders Let Them
Engineers default to building because it's more interesting, more resume-building, and easier to estimate optimistically than a decade-long maintenance commitment. Leaders let it happen because the build estimate is visible and immediate, while the maintenance cost is invisible and years away.
A few forces compound this bias:
- Not-invented-here. Engineers trust their own design instincts more than a vendor's, even when the vendor has solved the problem for hundreds of other companies.
- Optimism on estimates. The initial build quote almost never includes the second and third rewrites the capability will need once real usage hits it.
- Interesting work wins. Building a novel system is more career-satisfying than integrating and babysitting someone else's API — a preference that has nothing to do with what's best for the business.
- Vendor risk feels louder than maintenance risk. "What if they raise prices or get acquired?" gets asked in the room. "What if the person who built this leaves in two years?" rarely does.
Joel Spolsky's classic essay on rewrites captured a related version of this psychology two decades ago: engineers systematically underrate how much hard-won knowledge is baked into a system that already works, and overrate their own ability to redo it better. The same instinct shows up whenever a team reaches for "let's just build our own" instead of adapting to a vendor's model.
The fix is to treat the decision as a product call, not an engineering preference. That's the same reframe covered in platform-as-product thinking for internal customers: make the case for a build the way a PM would justify a roadmap bet, with a competing-alternatives analysis and an explicit opportunity-cost line, not just an engineering estimate.
The Framework: Differentiating Core vs. Undifferentiated Heavy Lifting
Separate every candidate capability along two axes: how differentiating it is to your product, and how evolved — how commoditized — the underlying technology already is. Pairing those two answers gives you a defensible default instead of a gut call made by whoever argues loudest in the room.
The second axis borrows from Simon Wardley's Wardley Mapping technique, which plots any component along an evolution path from genesis (novel, no market precedent) through custom-built, product, and finally commodity (standardized, interchangeable, priced like electricity). Where a capability sits on that path is a strong predictor of whether building it still makes sense.
| Evolution stage | What it looks like | Default move | Platform example |
|---|---|---|---|
| Genesis | Novel, no market precedent — you're inventing the approach | Build | A proprietary ranking or matching algorithm core to your product |
| Custom-built | Problem is understood, but every serious company's version still looks different | Build or wrap | An internal feature-flagging layer tuned to your exact release process |
| Product | Mature market, several credible vendors, real feature parity | Buy or wrap | Auth/SSO, payments processing, observability, CI/CD runners |
| Commodity/utility | Standardized, interchangeable, priced like a utility | Buy | Compute, object storage, transactional email, DNS |
Amazon has used the phrase undifferentiated heavy lifting since the founding of AWS to describe exactly the product-and-commodity end of that axis — the servers, databases, and queues every company needs but none compete on. If a capability fits that description, building it is rarely a strategic bet; it's an opportunity cost against the work that actually moves your product.
A useful gut-check: what job is this capability actually doing for the end customer? Mapped the way the complete guide to Jobs to Be Done recommends, most "infrastructure" capabilities turn out to be enabling a job rather than doing the job itself — which is a strong signal to buy rather than build.
Run the two-question test on anything ambiguous:
- Differentiation: would a customer notice or pay more because this specific piece is better than a competitor's?
- Convergence: has the market already settled on two or three credible vendors solving it the same way?
Yes/no (differentiating, not converged) points to build. No/yes (undifferentiated, converged) points to buy. Yes/yes — differentiating enough to want control, but a market exists — is exactly where the third option earns its keep.
The Third Option: Buy, Then Wrap
Wrapping means buying the commodity capability but building a thin internal abstraction layer in front of it, so your product code talks to your interface, not the vendor's. It costs more than a pure buy but far less than a build, and it buys you the one thing pure buying can't: an exit path that doesn't require rewriting your product.
Wrap when one or more of these is true:
- You may need to swap vendors without a product-wide rewrite — payment processors and model providers are the canonical examples.
- Two or more vendors solve most of the job differently, and you want to route between them by cost, latency, or capability.
- The vendor's native interface leaks vendor-specific concepts into your codebase in ways that will hurt later, regardless of who you're using.
- Contract terms, compliance requirements, or acquisition risk make a forced migration a realistic scenario within a few years.
A well-designed wrapper is itself a piece of internal developer experience, and it deserves the same rigor as customer-facing design. That's the case made in why developer experience is your product's front door: a clunky internal abstraction just relocates the pain instead of removing it, and a team that hates using the wrapper will route around it the first chance it gets.
Wrapping is not free, though — it's still a build, just a smaller one. The abstraction layer needs its own owner, its own tests, and its own upkeep as the underlying vendor APIs evolve. Underestimate that and you've recreated the exact maintenance trap you were trying to avoid, one layer removed.
The Total Cost of Ownership Nobody Puts on the Slide
The build estimate that wins the internal debate almost always prices the first release only. Gartner's total-cost-of-ownership (TCO) research — a concept the firm's analyst Bill Kirwin formalized back in 1987 — has repeatedly found that acquisition price is a small slice of lifetime cost once implementation, integration, support, and eventual replacement are counted.
| Cost driver | Build | Buy | Wrap |
|---|---|---|---|
| Year-1 cost | Highest — full design and implementation | Lowest — license or subscription plus integration | Medium — license plus a thin abstraction layer |
| Years 2–5 | Ongoing feature work, bug fixes, rework as scale changes | Vendor absorbs most of it; you pay for support and upgrade cycles | Vendor absorbs the core; you maintain a small, stable interface |
| Years 6–10 | Original engineers move on; a full rewrite becomes likely | Renewal leverage shrinks if switching would be painful | Swap the vendor behind the same interface with a contained blast radius |
| Hiring dependency | High — needs engineers who understand the original design | Low — vendor's support model carries the load | Low to medium — needs someone who understands the wrapper, not the vendor's internals |
| Exit cost | Highest — no one wants to sunset something they built | Highest without a wrapper — deep coupling to vendor-specific APIs | Lowest — swap the implementation behind a stable interface |
The sticker price is the smallest number on the page. Everything expensive about a build happens after launch, not before it.
This is exactly the funding problem covered in why platform maintenance work is chronically underfunded: a build's maintenance years never show up in the original business case, so nobody budgets headcount for them, and the capability quietly becomes an orphan two reorgs later.
The research behind Accelerate (Forsgren, Humble, and Kim) found elite engineering teams deploy directionally far more often than low performers — think on-demand versus roughly monthly. A meaningful share of that gap traces back to how much team capacity is tied up maintaining homegrown plumbing instead of shipping product.
Camille Fournier makes a related point in The Manager's Path: owning infrastructure means owning the org-design problem of who still understands it once the original builders have moved on. That cost never appears in a sprint estimate.
The Build-vs-Buy-vs-Wrap Checklist
Before committing to build, buy, or wrap, run the decision through a short checklist covering differentiation, total cost, hiring dependency, and exit cost. If you can't answer all four with confidence, that's itself a signal the decision is being made on vibes rather than evidence.
| Check | Ask this | Lean toward |
|---|---|---|
| Differentiation | Would customers notice, or pay more, if this were best-in-class? | Yes → build or wrap. No → buy |
| Market maturity | Are there two or more credible vendors with real feature parity? | Yes → buy or wrap. No → build |
| Hiring dependency | Could a new hire maintain this within three months, with documentation alone? | No → red flag for build |
| Exit cost | Could you swap this out in under a quarter if you had to? | No → red flag for buying without a wrapper |
| Ten-year TCO | Have you priced years two through ten, not just launch? | No → redo the estimate before deciding |
A vendor swap rarely stays contained to engineering. Before signing, map how the change would ripple through the customer journey, especially for capabilities customers interact with directly — checkout, support tooling, or anything with a visible SLA.
Two more items worth adding to your own version of this checklist:
- Contract exit clauses. Read the termination and data-portability terms before you sign, not after you want to leave.
- Concentration risk. If three vendors already sit behind this decision (cloud, identity, payments), a fourth deep dependency raises your blast radius in a renewal negotiation, not just a technical one.
Pressure-Testing the Call Before You Commit
High-stakes build-vs-buy calls rarely get the scrutiny they deserve, because the decision is usually made in a single meeting by whoever argues loudest. Prodinja's Leadership Suite includes a Decision Dojo of named scenarios you can walk through to pressure-test a call like this before committing engineers to it — working through the differentiation test, the ten-year TCO horizon, and the exit-cost questions above in a structured way rather than a hallway debate.
It's designed as a rehearsal space, not an oracle: you still make the judgment call, but you make it after stress-testing the weak points in your own reasoning instead of after the most confident voice in the room wins.
Key Takeaways
- Build vs. buy is an attention-allocation decision, not a procurement line item. Price the decade, not the sprint, before you commit.
- Map differentiation against market evolution. Differentiating and still evolving points to build; commodity and stable points to buy.
- Wrap when you need vendor flexibility without owning the plumbing. Buy the capability, build the interface, keep the exit door open.
- The real cost of building is hiring dependency. Ask whether anyone besides the original author could maintain it in year three.
- Exit cost is the most underpriced line item. It's far cheaper to plan a vendor swap before you sign than to negotiate one under duress.
- Fund maintenance in the same conversation you fund the build, or the capability becomes an orphan the moment its author changes teams.
Frequently Asked Questions
When should you build internal tooling instead of buying it?
Build internal tooling only when the capability is genuinely differentiating and the underlying problem hasn't converged on a standard market solution yet. If competitors could buy the same vendor tool and get the same result, building it in-house rarely earns its decade-long maintenance cost.
What is the real total cost of ownership for build vs. buy decisions?
Real TCO includes far more than license price or initial build hours: implementation, integration, ongoing maintenance, specialized hiring, security patching, and eventual replacement or migration. Gartner's TCO research has long argued that the visible acquisition cost is only a fraction of what a capability actually costs across its full life.
How do you decide platform build vs. buy for infrastructure specifically?
For infrastructure — compute, storage, messaging, identity — default to buy, because these sit at the commodity end of the evolution axis where multiple mature vendors already compete on price and reliability. Reserve build for the layer just above infrastructure where your product's actual differentiation lives.
What does it mean to "wrap" a vendor instead of building or buying?
Wrapping means buying a vendor's underlying capability but building a thin internal interface in front of it, so your codebase depends on your own abstraction rather than the vendor's specific API. It costs more than a pure buy but preserves the option to swap vendors later without a product-wide rewrite.
How do you estimate the cost of switching vendors later?
Estimate switching cost by counting how many places in your codebase call the vendor's API directly, how much customer-facing behavior depends on vendor-specific quirks, and how long a parallel migration would need to run safely. If that number is unknowable today, that itself is a sign to add a wrapper now.