Build vs buy an internal developer platform: a 2026 decision framework
The decision most engineering leaders get wrong in both directions. Here is the neutral framework with honest trade-offs, cost numbers, and a worksheet. No named vendors.
Big organisations think they can buy their way to a platform and then discover every commercial IDP needs deep integration work to fit their stack. Small organisations think they will build something just for us and then discover they have accidentally hired a product team to maintain it forever. Both extremes fail. Most successful platforms at scale are hybrids, but that hybrid structure needs to be deliberate rather than accidental.
The three real options
1. Build (from open source and primitives)
Full control over every abstraction. Full ownership of the maintenance burden for as long as the platform exists. The team you hire to build is the same team that runs it forever. Cost is dominated by headcount: five to ten platform engineers for a meaningful in-house platform, which is $900k to $2M in loaded salary in the first year before any infrastructure or tooling spend. Year one total typically $1.0M to $2.3M.
Build wins on three things: domain-specific workflows where no commercial tool exists, sovereignty (data residency, compliance) requirements that commercial vendors cannot serve, and teams with an engineering bench that can genuinely sustain a product for years. Build loses on feature parity with mature commercial tools in mature categories: the gap never closes because the commercial vendor has fifty engineers on the category and you have two.
2. Buy (a commercial internal developer platform)
Faster time to first golden path. Commercial platforms have solved the common patterns, so a two-week integration can give product engineers capabilities that would take a year to build. Platform team still exists but smaller: three to five engineers integrating, customising, and operating the purchased tooling. Licence cost is real (category-level bands vary widely by vendor tier and volume, from $50k at the low end to $500k-plus for enterprise deployments; specific pricing is vendor-dependent and not published here).
Year one total typically $600k to $1.6M. Buy wins on time-to-value and feature richness. Buy loses on three things: vendor lock-in (real but often overstated), integration work that rarely shrinks over time, and licence cost escalation on renewal that surprises finance.
3. Hybrid (the common outcome)
Commercial core plus open-source glue plus in-house golden paths. You buy the commercial capabilities where vendors do them well: CI/CD, observability, service catalogue, container management. You build custom golden paths on top that reflect how your engineering organisation actually wants to ship software. You maintain a full platform team because the hybrid has the most moving parts.
Year one total typically $1.1M to $2.5M, the most expensive of the three models in the first year. Year three is usually cheaper per unit of value delivered than either pure build or pure buy at 200-plus engineer organisations. Hybrid wins when you have an engineering bench that can integrate commercial tools thoughtfully without over-customising them.
The decision matrix
A scannable map from your current situation to the recommendation.
| Your situation | Recommendation |
|---|---|
| Under 30 engineers | Neither. Do not build a platform, do not buy an IDP. Use your cloud provider's managed services. Designate one senior engineer to own shared tooling as 20 percent of their time. |
| 30-80 engineers | Lean buy. Minimum viable commercial tooling in the highest-leverage categories (managed CI, managed observability). Do not build anything custom yet. |
| 80-200 engineers | Hybrid leaning buy. Commercial core for CI/CD, observability, secrets, service catalogue. First custom golden paths for domain-specific flows. Six to ten person platform team. |
| 200-500 engineers | Hybrid leaning build. You have the engineering bench to run custom tooling where commercial does not fit. Still buy the commodity capabilities. |
| 500+ engineers | Hybrid with significant build. Commercial vendors struggle to serve your scale without deep customisation that is almost as much work as building from scratch. |
| Regulated industry (finance, health, defence) | Hybrid with careful vendor selection. Buy for convenience where the compliance story is clear. Build where sovereignty is non-negotiable. |
| Greenfield startup | Buy. You do not have time to build. Pick the commercial options that fit your cloud and move on. |
The real cost of each path
Rough first-year costs at a 150-engineer organisation. Specific vendor pricing is not published here by editorial policy; category-level ranges are used in the Buy and Hybrid rows.
- 5-10 platform engineers: $900k-$2M loaded salary
- Cloud infra for the platform: $100k-$300k
- Commercial licence: $0
- No shortcut available
Plus the full team forever. Knowledge risk when engineers leave. Feature parity gap with commercial tools is permanent.
- Commercial licences (category bands): $50k-$500k+
- 3-5 integration engineers: $500k-$1M
- Cloud infra: $50k-$150k
- Integration work: 2-4 months per tool
Licence renewals escalate. Integration debt accumulates. Lock-in is contractual, not technical.
- Commercial licences: $50k-$500k+
- Full platform team: $900k-$2M
- Cloud + training: $150k-$400k
- Most expensive year one
Scales best past 200 engineers. Requires mature engineering leadership to avoid build-buy ambiguity.
The three failure modes
Build failure
Platform team builds an internal equivalent of an existing commercial tool. Twelve to eighteen months pass. The feature gap with the commercial alternative never closes because the vendor has fifty engineers on the category and you have two. Product teams route around the internal tool. Adoption stalls at under 30 percent. Leadership eventually kills the project or starts buying commercial. The $1M to $3M of sunk engineering time rarely recovers.
Mitigation: be honest about the feature parity goal on day one. Build only where commercial does not serve your domain, not where it would be cheaper to buy.
Buy failure
A commercial platform is purchased without enough integration effort. The vendor runs alongside the stack rather than inside it. Developers still shell-script around it because the happy path does not match how they actually work. Licence cost compounds with usage, the contract escalates on renewal, and the value delivered does not grow proportionally.
Mitigation: budget integration engineering equivalent to one-third the licence cost in year one and commit to replacing internal shell scripts with the commercial happy path aggressively.
Hybrid failure
No clear line between what the commercial platform owns and what the internal platform team builds. Maintenance ambiguity in every incident: is this a vendor ticket or an internal fix? Upgrade paths conflict with customisations the team has layered on top. Neither the commercial vendor nor the internal team has complete accountability.
Mitigation: draw the architectural line explicitly. Commercial owns capabilities A-E; internal owns F-J; there is no overlap zone. Revisit quarterly.
The seven-question worksheet
Answer yes or no to each. More yes-skew-build than yes-skew-buy means you should lean build; the opposite means buy. If the split is close, go hybrid.
- Do you have a clear engineering bench (50+ engineers) who would credibly sustain a platform for 5 years? Skew build.
- Is there a specific workflow that no commercial tool serves, and that workflow is core (not peripheral) to your engineering organisation? Skew build.
- Is time to first value more important than customisation in your next six months? Skew buy.
- Do you have compliance or sovereignty requirements that commercial vendors cannot meet? Skew build.
- Is your team under 200 engineers? Skew buy.
- Is your cloud setup straightforward (single major cloud provider, one region most of the time)? Skew buy.
- Have you tried off-the-shelf tools in the past and genuinely found them insufficient for your use case, not just philosophically unappealing? Skew build.
The honest summary
Most organisations at 100 to 500 engineers land on hybrid regardless of what they say at the start. The distinction that matters is whether the hybrid is deliberate or accidental. Deliberate hybrid chooses commercial for specific categories, draws explicit boundaries, and budgets for the integration work. Accidental hybrid buys things piecemeal, builds things to fill gaps, and ends up with no clear platform strategy and a budget that grows 30 percent a year with no adoption metric to justify it. Aim deliberate.