Should You Buy, Build, or Assemble an Internal Developer Platform?

When most platform teams get started, what they start off with is not a tooling question, but a mandate.

Leadership will have read that Gartner projects that 80% of software engineering organisations are running platform teams by this year. A budget line then appears on the balance sheet, and the brief comes down as some version of, “give the developers a self-service platform.” What none of that settles is what the internal developer platform should actually look like. That part gets left to whoever has to build it.

This is where the fork lies, and rather than the two prongs which people expect, it actually has three: A team can buy a commercial internal developer platform and configure it, build their own on top of open-source components, or assemble one from a set of building blocks somebody has already wired together as a starting point. Most write-ups will collapse this decision down to “buy versus build”, with assembly filed as either a slow buy or a quick build.

Our team assembles and adapts these as part of our platform engineering work, and we contribute to an open-source project that underpins the third option. From our experience of building these, we’ve collated this into a comparison.

In short, for the reader who needs the decision and not the detail:

• Buy when the goal is a working portal delivered this quarter, and both the core and stakeholder teams can live with someone else’s opinions about how software is shipped.
• Build only when the requirements are specific enough that nothing off the shelf fits the use-case, and you are happy to staff a product team to own the result.
• Assemble when the team wants to own the platform without paying the cost of a greenfield build. Reference implementations such as those from CNOE can be used as a base.
• The choice is rarely pure; Most teams will assemble a foundation, and then adopt or build selected pieces on top of it. The portal / machinery split further down decides which parts should go which way.

What is an internal developer platform?

“Internal developer platform” can be a baggy phrase. It covers two things, the portal that developers can see, and the machinery underneath it, and the two get sourced in different ways. Our What is an IDP? whitepaper walks through the pieces in full; what matters here is that they are separable, because a vendor will happily sell one part and avoid touching the more tricky part.

The first is the developer portal, the surface developers interact with. It catalogues services, exposes documentation, and offers a place to trigger the actions a developer needs, such as scaffolding a new service or requesting an environment. Backstage (the CNCF project originally built at Spotify) is the best known example.

The second is the platform underneath, the machinery which provisions infrastructure, wires up CI / CD, manages secrets, and reconciles the desired state of a cluster. This is where the golden paths live, the paved routes that allow a developer to go from an idea to a running service without filing a ticket for every step.

An internal developer platform is when both of these are put together. When a vendor or a project claims to offer “an IDP”, the first question worth asking is which of these two layers they mean. Some will sell a polished portal and quietly assume the organisation will bring its own platform underneath. Others provide the platform machinery and leave the developer experience as an exercise for the reader. Either half, on its own, will still get marketed as a platform; the other one still has to come from somewhere.

Each of the three routes answers those two layers differently.

Option A: Buy a commercial platform

The buy path takes a commercial internal developer platform, something like Humanitec, Port, or a managed Backstage offering like Spotify Portal or Roadie, and configures it to fit the organisation. The vendor has already made the hard decisions about how the portal, the orchestration, and the integrations fit together. The team just supplies the specifics of their own estate.

What you are buying here, mostly, is time. A commercial platform can be up in weeks, and the vendor owns the upkeep of the platform’s codebase: upgrades, security patches, and plugin compatibility, all of which an in-house build would have dropped on the team instead.

This means the qualifications tend to surface later:

• Opinions come baked in: A bought platform encodes a view of how software should be delivered. If that view matches the organisation, this makes the platform a shortcut. If it does not, then the team spends its time bending either the product or its own workflows until they meet, and that friction does not always show up before a proof of concept is finished.
• Pricing must scale with something: Commercial platforms are typically priced per developer, per workload, or per deployment. A cost that looks reasonable for a pilot of twenty engineers could read very differently across an organisation of several hundred, and the cost that matters is the one at full adoption.
• Integration is where the fit is decided: The platform has to reach into the organisation’s existing CI / CD, cloud accounts, identity provider, and secret store. Demo integrations are always clean; the ones that decide the outcome are the bespoke internal systems that every established organisation inevitably has, starting with the service registry the catalogue has to reconcile with. A bought portal arrives with its own opinion about what a service is.

Buying makes sense when:

• An organisation ships software in a reasonably mainstream way which is in lock-step with the vendor’s opinions, and
• Getting a portal working soon counts for more than controlling what sits under the hood.

Option B: Build your own

Building starts from open-source components, usually Backstage for the portal, and stands the platform up by writing the code that ties it to the organisation’s own infrastructure. The team owns the result outright and can shape it to fit requirements no product ever anticipated.

It gives the most control of the three, but it is also the easiest to underestimate.

Backstage is a framework rather than a product. Standing it up means running a Node.js application, and extending it means writing plugins in TypeScript and React. The catalogue is empty until someone writes the catalog-info.yaml discovery that fills it.

The golden paths do not exist until someone implements them as software templates, and the integrations with CI / CD and cloud infrastructure are code the team writes and then maintains.

Backstage releases also move quickly, so an upgrade undertaken to apply a security fix will, often enough, break a community plugin. This means that staying current ends up becoming a recurring cost rather than a one-off. At the end of the build, what the organisation has acquired is not a platform so much as a software product, with everything that owning a product entails:

• The build is never finished: A platform that ships is a platform that then needs upgrading, patching, and extending as the organisation’s needs move. The initial delivery is the smaller half of the cost; the ongoing ownership is the larger.
• It needs a product team, not a project team: Building an internal platform and then reassigning the engineers who built it is how organisations end up with an unmaintained portal that developers work around. The platform needs a standing team the way any internal product does.
• The failure mode is silent: A purchased platform that nobody uses will show up as a renewal the finance team can question. A built platform that nobody uses will show up as nothing at all, until someone asks why there is still a ticket queue behind the self-service platform.

Building pays off in a fairly narrow case: the requirements are bespoke enough that there is no clean off the shelf fit, and the organisation is willing to treat platform engineering as a standing capability (rather than a project it finishes and walks away from). Even then, it is rarely the whole platform that warrants it. What survives the argument is usually a single layer, or that one integration nothing off the shelf could have anticipated, such as the change approval gate every deployment has to clear.

Option C: Assemble from reference implementations

The third path sits between the other two. Rather than buying a finished platform or building one from an empty repository, the team can start from a reference implementation, a pre-integrated set of open-source components which already work together, and adapt it to their estate.

The clearest expression of this pattern is CNOE, the Cloud Native Operational Excellence project which publishes reference implementations for internal developer platforms alongside idpbuilder, a tool which stands a working platform up inside a local cluster so a team can inspect the shape of it before committing. A CNOE reference implementation wires together the components a platform needs: ArgoCD for GitOps delivery, Crossplane for infrastructure provisioning, Backstage for the portal, external-secrets for secret management, and allows the team to own the assembly rather than a vendored black box.

Note those are defaults rather than requirements. The adaptation we most often apply is to the provisioning layer, where an organisation already runs a Terraform or OpenTofu estate and has no appetite to move it into Crossplane.

We know this path from the inside, having contributed to CNOE as an official project contributor, including the reference implementations for Google Cloud and Microsoft Azure, which bring that same pre-integrated pattern to a GCP or Azure estate.

Assembly allows for ownership of the build path while removing much of its up-front cost:

• The integration work is largely done: The components that a build spends its first months wiring together arrive already talking to each other. A team’s effort goes into fitting the reference implementation into their own cloud, identity, and delivery conventions, rather than into reimplementing ArgoCD, Crossplane, and Backstage.
• There is no per-seat meter: These are open source components, so the cost at play is the engineering time to adapt and operate them. For an organisation that expects broad internal uptake, this changes the shape of the long-term bill.
• It still needs cloud-native fluency: Assembly removes the blank-page problem, but not the operational one. The team still needs to run ArgoCD, Crossplane, and the rest in production, and still needs to understand them well enough to debug them during an incident or on-call. A reference implementation is a strong starting point, but not a managed service.

If we had to choose a default path for an organisation that wants to own its platform, and either has the cloud-native capability in-house or is prepared to build it, we would point to assembly from a reference implementation first. It sidesteps the lock-in that comes with buying and the from-scratch cost that comes with building. The bill it does hand over is running the thing.

We help organisations stand up and adapt these platforms as part of our Cloud Platform Engineering work, proving the architecture out by building it rather than diagramming a reference architecture.

The hidden costs

The licence fee, the build effort, the time to adapt a reference implementation: these are the costs that go into the business case, and they are not the ones that decide how the platform is judged a year later. Three others do that, and none of them reaches an invoice.

Leaving costs far more than licensing. The lock-in a bought platform creates is not really the subscription. Golden paths, catalogue metadata and scaffolding templates all get authored in the vendor’s format, and that content is where an organisation’s delivery knowledge quietly accumulates. Replacing the tool is a procurement exercise. Re-authoring what forty teams encoded in it over two years is a project nobody scoped, and it is the reason platforms outlive the case for keeping them.

Nobody budgets for adoption. All three routes are costed up to the point the platform works, and developers are assumed to arrive on their own. What actually follows is documentation, office hours, and migrating services that already exist into a catalogue that has never heard of them. Where that work goes unfunded, teams route around the platform and build their own tooling, and the organisation ends up operating two platforms while collecting the benefits of neither.

The catalogue decays faster than anyone plans for. A service catalogue is worth having only while it is accurate, and keeping catalog-info.yaml correct across several hundred repositories is organisational effort rather than a technical feature. It also never finishes. A catalogue six months stale is worse than no catalogue at all, because developers check it once, find it wrong, and stop checking.

No route avoids all these three, and the choice mostly decides which of them lands hardest.

Adopt the portal, own the machinery underneath

The two layers we mentioned earlier have opposite economics, so the answer that suits the portal may not entirely suit the machinery sitting underneath it.

If any layer is worth buying, it is the portal: It is the most commoditised part of a platform, where somebody else’s opinions will cost the least, and produces the most visible “bang for buck”. Where there is appetite to run it, this can be Backstage, but if there’s no appetite, then there is Port or a managed Backstage such as Roadie. Writing a portal from scratch is the least defensible call in this area, because what makes a portal useful is the catalogue and the templates behind it, not the front end itself.

The machinery underneath is the layer worth owning: It has to reach into the cloud accounts, the identity provider, the CI / CD and the secret store an organisation already runs, which is precisely where a vendor’s integrations may stop being clean and start becoming consultancy. This is where a reference implementation can earn its keep: Running ArgoCD or Flux for delivery, Crossplane or an existing Terraform estate for provisioning, and external-secrets against Vault or a cloud key store.

Owning the machinery, however, should rely on two tests: There should be a standing platform product team, and whether the operational capability is there (if somebody can debug ArgoCD at 02:00 without a support contract behind them). If either answer is anything short of an enthusiastic yes, then buy the whole thing and revisit in a year.

That then leaves building for that one platform plugin peculiar to the estate, which is usually where it belongs. A mixed answer is the normal outcome. Our Platform Principles whitepaper sets out what we judge each of those choices against.

Where to start

Before committing to any of it, be honest about which of the three routes the organisation can actually maintain. A build which nobody is staffed to maintain will end up as an abandoned portal, which is the pattern Callum described as slapping on a developer portal and declaring the job done. Buying a platform whose opinions fight with the delivery model may mean it turning into shelfware. Assembly does not escape this issue either: a stack of open components that works the day it is handed over will start rotting the moment nobody owns the operations for it.

Standing a reference implementation up locally is the cheapest way to make the decision concrete. idpbuilder will bring a CNOE platform up inside a local cluster, and an hour spent with a working example will teach a team about what they are taking on. For an estate on Google Cloud or Azure, the implementations we contributed, reference-implementation-google and reference-implementation-azure, are the closest starting point to a live platform on either cloud.

If that decision is still open, or the platform is up but developers are not using it, that is where an outside pair of hands will earn its place. Our Cloud Platform Engineering work settles the architecture by building it, so the team will come away running a platform, rather than come away with a set of recommendations.

Frequently asked questions