Every flying school and charter operator eventually faces the same fleet question: build an aircraft from a kit, buy one certified off the shelf, or rent until the mission outgrows both. Software teams that practise PlatformOps — operating their internal developer platform with the care a product line receives — face a nearly identical decision, and the trade-offs rhyme so closely that aviation instinct transfers almost directly. Kit planes reward patience and punish shortcuts. Certified aircraft cost more and dictate their own limitations. Renting is cheap until it isn’t. This comparison walks the three routes with the available evidence, then offers a verdict for each organisation size.
The three PlatformOps routes, stated precisely
By “platform” we mean the shared machinery engineers use to ship software: templates, pipelines, a service catalog, guardrails. Three sourcing strategies dominate. Build: assemble your own from open-source parts, owning the integration forever. Buy: adopt a commercial developer-platform product and pay for someone else to maintain the whole. Borrow: adopt open standards and frameworks that carry community momentum — you own less than a kit build but shape more than a purchase allows. Like the hangar versions, none is universally right; each fits a mission profile, a budget, and a maintenance appetite.
Route one: build it from open parts
The build route has a flagship. Backstage, the portal framework Spotify opened-sourced and donated to the CNCF, has been incubating there since March 2022 and ships monthly releases. It gives you catalog entities — structured records for every service you operate — and Software Templates, the scaffolds that turn a blank repository into a running service with pipelines attached. Around it, a standard workshop fits together: Argo or Flux for Git-driven deployments, Prometheus and OpenTelemetry for signals, OPA or Kyverno for policy checks. Each part is proven; the integration is yours.
Evidence for and against is easy to state. For: no vendor can retire your roadmap, the parts evolve in the open, and hiring is feasible because the components are résumé-standard. Against: integration labour is real and recurring, and the platform team that assembles five tools has signed up to upgrade five tools annually, forever — the maintenance burden aviation readers will recognise as engine-and-airframe ownership, not as a one-time purchase.
Maturity signals in the ecosystem matter for this route, because parts differ in staying power. Crossplane, which expresses cloud infrastructure as Kubernetes-style API objects, reached graduated status in the CNCF in October 2025 — the foundation’s highest maturity mark, earned through adoption and governance history rather than marketing. Graduated projects rarely vanish; incubating ones sometimes do. A builder’s first analytical act is therefore sorting candidate parts by lifecycle stage the same way a buyer sorts airframes by hours, inspections, and parts availability before signing anything.
Who should build
Organisations with several platform-minded engineers, a genuine platform customer base, and a multi-year horizon. The open-source route only pays back above a certain scale of repetition, which is why the standard advice in the field warns against founding a platform effort with fewer than about three teams whose needs overlap repeatedly — and only with funding committed for a couple of years, not one budget cycle.
Route two: buy a vendor product
Buying compresses time to first value. A commercial portal arrives with onboarding, support contracts, and demos that impress executives. For companies with no platform staff and an urgent need, a purchase can beat a year of part assembly — the same logic that sends a flight school to a certified aircraft while its chief instructor is still learning rivet patterns.
The evidence against is written in retirement dates. AWS Proton, Amazon’s own platform product, lost vendor support on 2026-10-07. Microsoft’s Azure Deployment Environments is scheduled to retire on 2027-02-22. Two major cloud vendors shipped platform products, marketed them, and then withdrew them — not because the ideas were wrong, but because products without sufficient adoption die commercially. A retired vendor product strands its customers with a migration nobody budgeted for, which is the software equivalent of your type certificate being revoked mid-fleet.
Due diligence follows for any buyer, and it fits neatly in four questions:
- What happens to our data, templates, and workflows if this product line is discontinued — is there a tested export path?
- How many products has the vendor retired in the last five years, and how were those customers treated?
- Does the contract price include migration assistance, or does retirement leave us holding the cost?
- Can the underlying standards (catalog formats, pipeline definitions) move to a competitor without a rewrite?
A vendor that retires products casually is telling you something; the habit of reading those signals closely will feel familiar to anyone who has compared aircraft maintenance programmes across providers.
Route three: borrow the standard, skip the monument
The third route starts from a different premise: the smallest platform that genuinely serves today’s needs. The Team Topologies authors gave this the name thinnest viable platform, and the phrase does honest work. Instead of a portal programme, the organisation adopts the minimum shared capability that removes its worst repeated friction — one pipeline standard, one template, one catalog page — and grows only where pull from real users justifies growth. Borrowing in this sense means leaning on community standards (OpenTelemetry for signals, GitOps patterns for deployment) so that any future build or buy inherits compatible parts instead of a bespoke museum.
For small organisations the thinnest version can be almost embarrassingly modest: a maintained wiki page describing the one supported way to ship, plus a couple of scripts. Field guidance is comfortable saying so outright — below roughly three teams with repeated overlapping needs, a well-kept wiki can suffice. The discipline is not the headcount; it is treating whatever shared capability exists as a product with an owner.
Concretely, a borrowed-first quarter looks like this: document the single deployment route everyone already tolerates; name the person who answers questions about it; measure how long a newcomer takes to ship through it; and only then consider whether a template engine or a catalog earns its keep. Most teams discover the honest bottleneck was documentation and ownership, not missing software — a diagnosis that costs an afternoon instead of a procurement cycle.
Scoring the routes against each other
- Time to first value. Buy wins on the calendar; build loses months to integration; borrow lands in between and often within weeks.
- Ten-year cost. Build shifts spend onto permanent salaries; buy converts it to licence fees plus migration risk; borrow keeps spend proportional to actual usage.
- Lock-in exposure. Buy carries the Proton-style retirement risk; build carries key-person risk; borrow spreads risk across communities.
- Fit to mission. A two-team startup has no platform problem worth a programme; a forty-team organisation with repeated needs probably does.
Analytical readers will notice the pattern: every route’s worst outcome is a mismatch between organisation size and platform ambition. Oversized platforms rot from underuse; undersized ones rot from overuse.
The PlatformOps verdict, route by route
If you have three or more platform engineers and dozens of internal customers, build on Backstage and the open ecosystem — you are buying insurance against vendor retirement with labour you already employ. If you have no platform staff and an acute gap, buy, but negotiate the exit before the entrance. If you are somewhere between — most companies, most of the time — borrow the standards, keep the platform thin, and let adoption pressure justify every addition. For the underlying discipline that makes any of the three workable — lifecycle management, service levels, adoption earned like a product — see the Ops Atlas PlatformOps guide, the reference we would hand to a chief pilot suddenly holding an engineering budget.
And whatever the route, keep the aviator’s humility: the machine you chose matters less than the inspections you never skip. Software platforms, like airframes, stay airworthy through scheduled maintenance, honest logbooks, and crews who file the squawk instead of ignoring it. If the fleet analogy holds you this far, the engineering side will feel less foreign than its vocabulary suggests — a point our cockpit guide for aviation learners makes from the other direction, and one that pairs naturally with an engine basics walkthrough for anyone who likes their analogies bolted to metal.
