You rarely build an internal developer platform from scratch, and you can’t buy one whole. You assemble it: open source or SaaS parts for the commodity layers (delivery, infrastructure as code, the portal) and your own glue for the parts that encode how your company ships. The real decision is which layers you own. Buy what doesn’t differentiate you, and build only what you can name an owner for.
After 18+ years in platform engineering, DevOps and SRE, I’m sure of one thing: “build or buy” is the wrong first question. The right one is which three things your engineers wait on most. We build platforms for clients on Backstage, Argo CD, Kargo, Crossplane and OpenTofu, and we sell a fixed-price package to start one.
What is an internal developer platform, exactly?
The CNCF’s platforms white paper defines a platform for cloud-native computing as “an integrated collection of capabilities defined and presented according to the needs of the platform’s users”. In practice the capabilities look like this: creating a new service from a template that already has CI, observability and security checks wired in. Promoting a release to the next environment through gates that can stop it. Requesting a database or a queue without filing a ticket. Seeing who owns what, what’s deployed where and what it costs.
The portal (Backstage, Port and the like) is the front door to those capabilities. The platform is everything behind it: pipelines, clusters, infrastructure code, policies. The question gets confusing because vendors sell at different layers. Some sell only a portal, some sell an orchestration layer, and the cloud providers sell the building blocks underneath.
What does “buy” actually get you?
Usually one of two things. The first is a SaaS portal: a catalog, scorecards and self-service forms that call your existing automation. Port is an example (I compare it with Backstage in Backstage vs Port). It’s fast to start, and the automation behind each button is still yours to write. The second is a platform product or orchestrator, which generates configuration and environments from a higher-level description. It takes more work off your plate and imposes more of its own model on how you deploy.
Neither replaces the decisions only you can make: what blocks a release, who approves a destructive infrastructure change, what a new service must include on day one. A purchased platform with nobody making those decisions is an expensive dashboard.
What does “build” actually mean?
It means assembling mature open source projects. A typical stack we run: Argo CD for GitOps sync and Kargo for promotion between environments, OpenTofu or Terraform for infrastructure (with Crossplane where teams want to request infrastructure through Kubernetes), Backstage as the portal, and OpenTelemetry into a Grafana-based stack for observability.
The code you write is the glue: templates, promotion rules, verification checks, a handful of plugins. That glue is the part worth owning. It’s your company’s way of shipping, written down as code.
How do the costs compare?
Put both paths in the same unit, dollars a year.
Buying only the portal at Port’s list price means 80 engineers on Standard, which is USD 40 per seat per month: 80 × 40 × 12 = USD 38,400 a year. That buys the portal. You still need people to write the automation each self-service action calls.
Building on open source has no license, so the cost is engineering time. A first production version through our IDP Foundations package is a fixed USD 5,000. After that, ownership is the line that matters. One Senior engineer for a quarter of their time is about 40 hours a month, or USD 1,800 to 2,000 a month at our rates (40 × 45 to 50), plus hosting in your own cloud.
Both paths share the same underlying work: templates, pipelines, promotion gates, infrastructure modules. Whether you buy a portal or build one, somebody writes these, and no price list shows them. So the comparison is narrower than it looks. It’s a seat fee against the engineering time to run a portal, and the platform work underneath costs about the same either way.
When should you buy, and when should you build?
Buy when your stack is mainstream and the vendor’s connectors cover it. Buy when nobody on the team wants to own a web application (Backstage is a TypeScript app you deploy and upgrade yourself), when you need something visible in weeks to prove the platform team’s value, and when your headcount keeps seat fees small next to an engineer’s time.
Build when the capabilities that matter are specific to you: a promotion flow with your own verification gates, cost views from your own billing data, compliance evidence your auditors ask for. Build when data and credentials must stay in your accounts, when you have or will fund a named owner, and when seats would dominate the cost at your headcount.
Land on both lists and you’re in the hybrid case. That’s normal, and it’s where MPI sits.
What does the hybrid look like on a real platform?
MPI is a portfolio-analytics SaaS platform on AWS EKS with separate dev and prod accounts. Its platform is almost entirely assembled from open source: Argo CD and Kargo for delivery, Terraform and OpenTofu with Atlantis for infrastructure, a migration to Crossplane done as zero-downtime cutovers with rollback, and a Backstage portal. What we wrote is the glue: the promotion template, the verification gates, and the portal plugins (22 modules across 10 plugins).
Here is what moved. Production releases went from about one a week (April to July 2026) to nearly four a week over the last 30 days. Seven manual steps plus a certification checklist per release became one Promote action that runs a 79-step automated template. No vendor sells that template, because it encodes how that team ships.
What’s the cheapest way to find out?
Don’t start with a vendor shortlist. Write down the three things your engineers wait on most. “A new service takes a week to get CI and monitoring” is a capability gap. “We need a portal” is a solution looking for a problem.
For each one, ask whether a product does it with your stack today or whether it needs your rules encoded. Buy the first kind, build the second, and give each a named owner. If you can’t fill in that first list, a portal won’t fix it. That’s a Discovery question.
Our platform engineering service covers the assembled path: Backstage, GitOps delivery, infrastructure as code and the glue between them. IDP Foundations is the cheap way to settle the argument: USD 5,000, two weeks, a first production version with your services connected, so you decide with a working platform in front of you instead of a slide. Every package and hourly rate is on the pricing page.
Sources, accessed 2026-10-07: CNCF TAG App Delivery, Platforms white paper, Port pricing.
Port is a trademark of its owner. Clouditive is not affiliated with it.