Internal developer platform: build, buy, or assemble.
What you are actually deciding
An internal developer platform is not a product. It is a set of capabilities: service provisioning, environment management, deployment automation, observability integration, secrets handling, cost visibility. The build/buy/assemble decision applies to each capability independently. In practice, almost every platform team mixes approaches: buying the CI system, building the service provisioning layer on Terraform modules, and assembling the developer portal from Backstage with custom plugins.
The question is therefore not 'should we build or buy the platform?' It is 'for which capabilities does each approach produce the best outcome at our current scale?' The answer changes as the team grows, as OSS tooling matures, and as commercial vendors expand their capabilities.
Build: when it is right and when it is not
Building custom platform capabilities makes sense when the requirement is genuinely differentiated: when off-the-shelf tooling cannot meet the need at any reasonable integration cost, and when the capability is a source of competitive advantage for the engineering organisation.
In practice, this is rarely true at the platform layer. Service provisioning, deployment pipelines, and developer portals are not competitive differentiators. Building a custom Kubernetes operator when Crossplane exists, or a custom developer portal when Backstage exists, produces a capability the engineering team must maintain indefinitely with no external community support.
Build is the right choice for capabilities that are genuinely specific to your domain: custom workflow automation reflecting your engineering process, internal product registry logic, specialised compliance controls. Not for the generic platform primitives that OSS already covers well.
Buy: the commercial platforms and their tradeoffs
Commercial IDP vendors offer faster time-to-value than building from scratch, a maintained UI, and pre-built integrations. The tradeoffs are vendor lock-in, per-seat pricing that scales linearly with headcount, and capability ceilings when your requirements diverge from the vendor's roadmap.
Buying makes sense for teams that need a working developer portal in weeks rather than months, that do not have platform engineering headcount to maintain OSS tooling, and that can live within the vendor's capability model for the foreseeable roadmap. The warning sign is when the team starts requesting custom integrations from the vendor more often than the vendor ships them. That is the ceiling.
For EU companies, verify data residency before selecting a vendor. Most enterprise-tier agreements include EU region deployment options for the control plane. Verify this before contracting, not after.
"Most teams that say they are building their platform are actually assembling it. The distinction matters because the maintenance cost is very different."
Maikel Vlasman / Cloud Architect
Assemble: the path most teams take
Most teams that describe themselves as building their platform are actually assembling: Backstage as the developer portal, Crossplane or Terraform modules as the provisioning layer, Argo CD or Flux for deployment automation, the existing observability stack for cost and health visibility. The result is a capable platform that required no greenfield development for any individual capability.
Assemble has a higher integration tax than buy and a lower maintenance ceiling than fully custom build. Each OSS component has its own upgrade cycle, breaking changes, and community support quality. The platform team integrates rather than builds, but integration is still engineering work.
The decision criterion: if your team has 2 to 4 platform engineers and developers are asking for a golden path rather than a feature-rich portal, assemble is the right starting point. The OSS components are production-quality and widely adopted. The integration work is real but bounded. The capability ceiling is high enough for most mid-market organisations for several years of growth.