Delivery
Build vs buy for platforms
Most platform parts should be bought or taken from open source. The homegrown PaaS trap is a custom YAML dialect that only three people understand, and that nobody funds to upgrade.
Every platform part is a choice between building it and using something that already exists. The right answer is almost always to buy or adopt open source for the undifferentiated parts, and to build only where your company has a real need that nothing else meets. The costly mistake is the homegrown PaaS, which is a custom platform that wraps Kubernetes in a private dialect.
The big idea
Think of building your own kitchen appliances. A custom oven might suit a famous restaurant. A home cook who builds their own oven spends the year on the oven and not on food. Build only the parts that set your product apart.
Walking through it
| Component | Lean toward buying or open source | Build when |
|---|---|---|
| Portal and catalog | Backstage, or a commercial portal | You need a deep custom experience, and can staff it |
| CI | GitHub Actions, Buildkite or Cloud Build | You operate at extreme scale, or need unusual hardware runners |
| CD and canaries | Argo Rollouts, Flagger or Cloud Deploy | You outgrow the standard tools, and need org-wide policy |
| Secrets and IAM patterns | Cloud IAM with Vault or SSM | Compliance needs one facade over everything |
| Full internal PaaS | Rarely | You operate at the scale and culture of a large platform company, and are funded for it |
The homegrown PaaS trap looks like this. A team wraps Kubernetes in a custom YAML dialect and a deployment service. Three people understand it. The team is underfunded, so upgrades freeze. Debugging means reading the wrapper's source code. New hires learn the company's dialect instead of the industry's. Five years later, the platform is a liability.
Prefer composing boring upstream tools behind templates and thin APIs. If you do invent a domain-specific language, also invent its exit strategy in advance.
Warning
Measuring platform success by the number of internal tools built rewards the trap. Measure adoption, time to a safe production deploy, and the drop in undifferentiated tickets instead.
Common mistakes
- Building CI or a portal from scratch when a managed option covers the need.
- No exit strategy for a custom layer. The day the author leaves, the layer becomes a legacy system.
- Building because it is interesting. Build only when the need is specific and repeated.
Check yourself
- When is it worth building a platform component? When the need is specific to your company and repeated, and nothing bought or open source meets it.
- What is the warning sign of the homegrown PaaS trap? A custom dialect that only a few people understand, with upgrades frozen because it is underfunded.
Key takeaways
- Buy or adopt open source for undifferentiated parts, such as CI, CD and the portal.
- Build only where your need is specific, and staff what you build.
- Avoid a custom dialect over Kubernetes. If you invent a DSL, plan its exit.
Further learning
The platform picture is in platform engineering. The product view that tells you what to measure is in platform as a product.
Backstage documentation, what is BackstageWhat is Backstage? | Backstage Software Catalog and Developer Platformbackstage.ioRelated
Platform engineering
Internal developer platforms, golden paths and treating infrastructure as a product. Cut cognitive load without building a second Kubernetes.
Platform as a product
Treat internal engineers as customers, measure adoption and time to a safe production deploy, and choose a thin platform over a thick one until a clear need forces a thicker abstraction.
Continuous integration and the software supply chain
Fast, trustworthy pipelines - build, test, artifact, scan and sign - plus DORA metrics and supply-chain controls that keep trunk green.