Every platform team eventually hits this decision for some capability — the developer portal, the CI/CD system, the secrets manager, the observability stack. Should we build it in-house, or buy an existing platform from the market? There's no universal right answer, and treating it like there is — "we build everything" or "we buy everything" — is how teams end up either burning years building commodity infrastructure or locked into a vendor for the one thing that was actually supposed to differentiate them.
Note
The single question that resolves most build-vs-buy debates faster than any framework: is this core to your differentiation? If yes, building is usually worth the investment. If no, buying almost always is — because the hours spent building a commodity capability are hours not spent on the thing that's actually specific to your product.
What each path actually costs and gives you
| Build | Buy | |
|---|---|---|
| Control & flexibility | Full control, customized to your needs | Less flexibility, may not fit unique workflows |
| Time to market | Longer — high initial investment | Faster — enterprise-ready and maintained |
| Differentiation & IP | You own it | Vendor owns the underlying platform |
| Ongoing cost | Maintenance and upgrades, indefinitely | Recurring subscription, lower operational overhead |
| Risk | Need skilled platform engineers to sustain it | Vendor lock-in, roadmap risk, compliance dependency |
Neither column is strictly better — the table is a list of trade-offs, not a scorecard with a winner. A five-person startup and a regulated bank should read the exact same table and reach opposite conclusions for the exact same capability, because their actual constraints (speed to market versus data residency, differentiation needs versus available platform engineering talent) are different.
A decision flow that actually resolves the argument
Is it core to your differentiation?
YES → BUILD
NO → Is speed to market more important?
YES → BUY
NO → Do you have the team and resources to build?
YES → BUILD
NO → BUYRunning through real examples against that flow: CI/CD pipelines are rarely core differentiation — most teams buy (GitHub Actions, GitLab CI) rather than build custom pipelines. A developer portal sits closer to the line — plenty of teams buy (Backstage, Port) as a foundation and customize on top rather than building from scratch. A container platform is almost always buy (managed Kubernetes) unless you're at a scale where the control is worth the operational burden. Secrets management typically buys (Vault, cloud-native secrets managers) rather than building an in-house equivalent, because getting secrets management wrong is a security incident, not a minor bug.
The context that should shift the default answer
- Startup or scale-up — buy to move fast and validate; building infrastructure before you've validated the product is effort spent on the wrong bet.
- Enterprise — build where there's genuine differentiation, compliance requirements, or deep integration needs specific to the business.
- Regulated industries — build where control, security, and data residency actually matter, because a vendor's general-purpose compliance posture may not match a specific regulatory requirement.
- Platform maturity — a common and reasonable pattern is starting by buying the foundation, then building the specific pieces that turn out to matter as the platform's needs become clearer.
The hybrid answer is usually the honest one
"Hybrid is the golden path: buy the foundation, build the differentiation." In practice this looks like buying commodities — CI/CD engines, base observability tooling, container orchestration — and building the layer that's genuinely specific to your organization on top of them: the golden paths, the internal conventions, the integrations unique to your stack. Very few real platforms are pure-build or pure-buy; most are exactly this combination, whether or not the decision was made deliberately.
Why this decision deserves this much deliberation
"Focus on business outcomes, not tools. Build what differentiates. Buy what accelerates." Getting this decision wrong in either direction has a real, compounding cost: building commodity infrastructure is years of platform engineering effort spent on something a vendor already solved well; buying the thing that was supposed to be your differentiation locks your competitive advantage behind someone else's roadmap. The decision flow above won't make the trade-offs disappear, but it forces the conversation to happen explicitly instead of by default — which is usually where build-vs-buy regret actually comes from.
Tomorrow's article covers a discipline that applies regardless of which side of build-vs-buy a platform team lands on: FinOps, and why "great platforms don't just ship features, they deliver value efficiently" is a claim that needs actual cost visibility behind it, not just an assumption.
