Ivan CernjaHow to Build an Internal Developer Platform
The build-versus-buy decision, what you assemble if you build, and the ongoing cost most teams underestimate
In 2020 Spotify open-sourced Backstage, the developer portal it had built to tame a sprawl of internal services, and thousands of companies adopted it expecting a platform in a box. What most of them found was a frontend with a service catalog and a plugin system, sitting on top of infrastructure they still had to provision, pipelines they still had to run, and environments they still had to manage, all wired together by a team they had to staff. Backstage was one component of an internal developer platform, and the rest was theirs to build. That gap between "we installed the portal" and "we have a platform" is where most IDP projects stall, so before writing any code the first decision is whether to build at all.
Build or buy
An internal developer platform is worth building when your workflows are strange enough that no product maps onto them and you have a platform team ready to own the result for years. It is worth buying when an off-the-shelf product covers most of what you need, because the cost of an IDP lands almost entirely after launch, in the maintenance, not in the first version. Teams tend to overestimate how unusual their requirements are and underestimate how much upkeep the seams demand, which is why buying or adopting a platform is the safer default outside the largest orgs.
| Build | Buy or adopt | |
|---|---|---|
| Upfront cost | Months of platform-team time | Onboarding and configuration |
| Ongoing cost | A standing platform team | Vendor cost plus lighter integration |
| Fit | Exact, if you get it right | Close, with some workflows adapted |
| Time to first golden path | Slow | Fast |
| Who absorbs upstream changes | You | The vendor |
| Best fit | Large orgs, unusual workflows | Most teams |
The decision hinges on who will maintain the platform in year three. If that is a dedicated platform team you already have and intend to keep, building can pay off, but if the answer is vague, an IDP you build becomes a system nobody owns, which is worse than the ticket-driven process it replaced.
What you assemble if you build
Building an IDP means integrating six layers, none of which is a platform on its own. The value is in the connections between them, exposed to developers as paved paths rather than a set of consoles to learn.
The stack you assemble to build an internal developer platform: a portal or service catalog on top, then infrastructure-as-code, CI/CD, environment management, observability, and access control underneath, integrated into golden paths a developer follows.
The portal or service catalog is the layer developers see, where they find services, ownership, and docs, and where they kick off new work. Backstage, Port, and Cortex live here. It is a frontend, not the machinery underneath.
Infrastructure-as-code provisions the cloud resources a service needs. Terraform, Pulumi, or Crossplane declare databases, queues, and networking, and the platform team maintains the modules developers instantiate.
CI/CD builds, tests, and deploys. The pipeline has to know how to package each kind of service and roll it out safely, which means the platform team owns pipeline templates as carefully as it owns anything else.
Environment management creates and destroys the environments a change moves through, including preview environments per pull request and a shared staging environment. Making these cheap to spin up and reliable to tear down is more work than it looks.
Observability wires tracing, metrics, and logs so a developer can see what a service is doing without assembling the instrumentation by hand each time.
Access control ties identity to permissions across all of the above, so the paths the platform exposes stay inside the boundaries security requires.
The golden-path approach
Integrating those layers gives you plumbing, not a platform. The product is the golden path, a supported and opinionated route through the plumbing for a common task. "Create a new service" should mean the developer answers a few questions and gets a repository, a pipeline, provisioned infrastructure, an entry in the catalog, and a running preview environment, without touching Terraform or reading six runbooks. The path encodes the org's defaults, so security review, observability, and deployment come free with the route rather than as separate chores.
Golden paths are where the maintenance concentrates, because every upstream change, a new Terraform provider version, a pipeline syntax change, a portal upgrade, can break a path that developers depend on. A platform that ships two or three well-maintained paths beats one that exposes every capability and keeps none of them reliable.
The cost that continues
The initial build is a few engineers for a few months, which is the number that gets budgeted. The number that gets missed is the standing platform team, commonly three to six engineers, whose job is to keep the seams together after launch. They absorb version bumps across every integrated tool, rebuild golden paths when an upstream tool changes shape, and support the internal developers who hit the edges. Over three years that maintenance dwarfs the build, and an IDP without a team funded to own it decays into a set of half-working scripts that the developers route around.
This is the real content of build-versus-buy. A bought platform moves the version bumps, the integration breakage, and the upgrade work to a vendor, and you pay for that in license cost and in adapting some of your workflows to fit the product. The tradeoff is legitimate in both directions, and the common mistake is pricing only the build while treating the maintenance as free.
The adopt-a-platform alternative
Between building from parts and buying a portal sits a third option, which is to adopt a platform that removes layers rather than integrating them. For backend-heavy teams a code-first backend platform is the clearest example of this, and Encore is where it fits.
Where Encore fits
Encore is a code-first backend platform, so the platform experience comes from how the backend is written and run rather than from a portal laid over existing tools. It sits in a different category from portals like Backstage, Port, and Cortex, and from orchestrators like Humanitec: those give you a frontend or a control plane over infrastructure you still assemble, while Encore removes several of the layers a DIY IDP has to integrate.
You declare infrastructure as typed objects in your application code, so a Postgres database, a Pub/Sub topic with delivery guarantees, a cron job, or a secret is an object the code uses, and Encore provisions it into your own AWS or GCP account with defaults you can adjust in the dashboard.
// orders/orders.ts
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
// Declaring infrastructure is declaring a typed object.
// Encore provisions it into your AWS or GCP account.
const db = new SQLDatabase("orders", { migrations: "./migrations" });
interface OrderPlaced {
orderId: string;
}
const placed = new Topic<OrderPlaced>("order-placed", {
deliveryGuarantee: "at-least-once",
});
From that same code Encore gives you CI/CD, preview environments per pull request, staging and production environments, distributed tracing, a service catalog, and an architecture diagram generated from the services and their calls, which covers the provisioning, delivery, environment, observability, and catalog layers a built IDP wires together by hand. It provisions into your own cloud account rather than hosting your services, and encore build docker exports a standard image if you want to run it elsewhere. Where you already have Terraform, Encore's Terraform provider exposes the resources it provisions as data sources so the two coexist.
Encore is not a developer portal in the Backstage sense, so if what you need is a customizable frontend and software catalog over a heterogeneous estate of services in many languages and runtimes, a portal is the right tool and Encore is not a substitute for it. Encore fits when the platform you would otherwise build is mostly backend, and you would rather adopt those layers than staff a team to maintain them.
Related reading
Frequently asked questions
How do you build an internal developer platform?
You assemble it from parts. A portal or service catalog for discovery, infrastructure-as-code for provisioning, CI/CD for delivery, environment management for spinning up and tearing down, observability for tracing and logs, and access control across all of it. Then you wire those pieces into paved paths so a developer can go from a repository to a running service without filing tickets. The build itself is a few months of work; keeping the seams together is the part that continues.
Should you build or buy an internal developer platform?
Build when your workflows are unusual enough that no product fits, and you have a platform team that can own the result long-term. Buy when a product covers most of what you need, because the cost of an IDP is mostly the years of maintenance after launch, not the initial assembly. Most teams overestimate how special their requirements are and underestimate the upkeep, so buying or adopting a platform is the safer default for all but the largest orgs.
What components make up an internal developer platform?
A developer portal or service catalog, infrastructure-as-code for provisioning cloud resources, a CI/CD pipeline, environment management including preview and staging environments, observability with tracing and logs, and access control tying identity to permissions. The platform's real value is the integration between these, exposed as golden paths a developer follows without needing to understand every layer underneath.
What is a golden path in platform engineering?
A golden path is a supported, opinionated route through the platform for a common task, like creating a new service or shipping a change to production. It removes decisions the developer does not need to make and encodes the org's defaults for security, observability, and deployment. Golden paths are what turn a pile of tools into a platform; without them you have integrations but no product.
How much does it cost to build an internal developer platform?
The build is usually a few engineers for a few months. The larger cost is ongoing: a platform team, typically three to six engineers, maintaining the glue between tools, absorbing upstream changes, updating golden paths, and supporting internal users. Over a few years the maintenance dwarfs the initial build, which is why the build-versus-buy math turns on who will own it, not on how long the first version takes.
Is Backstage enough to build an internal developer platform?
Backstage gives you the portal layer, the catalog, templates, and plugins, but it does not provision infrastructure, run deployments, or manage environments. You still assemble and integrate those separately and maintain that integration. Backstage suits large orgs with a platform team that wants a customizable frontend over existing tooling; smaller teams often find the plugin and upgrade upkeep outweighs the benefit.
Automated infrastructure for humans and agents
Let agents build and validate features with real infrastructure in the dev loop. Encore automatically provisions infrastructure, from local dev to production in your cloud on AWS/GCP.