Ivan CernjaInternal Developer Platform: Build vs Buy (2026)
What it takes to build a platform, and when buying makes more sense
An internal developer platform (IDP) is a self-service layer that sits between developers and infrastructure. Instead of filing tickets to get a database, waiting on DevOps for a new environment, or piecing together CI/CD pipelines for each service, developers interact with the platform. The platform handles provisioning, deployment, and observability according to standards your organization defines.
The idea is straightforward: reduce cognitive load on developers by abstracting away infrastructure complexity, while maintaining the guardrails and consistency that operations teams care about. The execution is where it gets complicated.
Most engineering organizations eventually face the same question: should we build this platform ourselves, or adopt something that already exists? This guide covers both paths, from assembling tools like Backstage and Terraform to adopting integrated platforms like Encore Cloud that bundle IDP capabilities out of the box.
What an IDP Actually Includes
A functional internal developer platform typically covers five areas:
Service catalog. A central registry of all services, their owners, dependencies, APIs, and health status. Developers use it to discover what already exists before building something new. Operations uses it to understand the dependency graph when something breaks.
CI/CD integration. Standardized build and deployment pipelines that work across all services. Developers push code and the platform handles testing, building, and deploying to the right environment. Golden paths define how a new service should be set up so that every team follows the same patterns.
Environment management. The ability to spin up preview environments, staging environments, and production environments with consistent infrastructure. Developers should be able to get a full environment for a pull request without involving anyone else.
Infrastructure provisioning. Databases, queues, caches, object storage, and networking configured according to organizational standards. The platform provisions these resources when a developer needs them, with the right security policies and configurations already applied.
Observability. Distributed tracing, metrics, and logging integrated across all services. When something fails in production, developers can trace the request through the system without setting up monitoring themselves.
Getting any one of these right is a project. Getting all five to work together as a cohesive self-service experience is what makes platform engineering hard.
The Build Path
Building an IDP means assembling and integrating tools across each of those five areas. Here's what that typically looks like:
Service Catalog
Backstage, originally from Spotify, is the most common choice. It provides a plugin-based service catalog where teams register their services and expose metadata, documentation, and API specs. Backstage is open source and extensible, but it requires significant effort to deploy, customize, and maintain. You'll need a team that can write and maintain Backstage plugins, integrate it with your internal systems, and keep it useful enough that developers actually use it.
Alternatives like Port, Cortex, and OpsLevel offer managed service catalog experiences with less assembly. They provide scorecards, ownership tracking, and integrations out of the box, but they cover only the catalog layer. You still need the rest of the platform.
CI/CD and Golden Paths
Most organizations start with GitHub Actions, GitLab CI, or Jenkins, then layer on standardized workflows. Golden paths (predefined templates for how to create and deploy a new service) are typically built as repository templates or scaffolding CLIs that generate the right pipeline configuration, Dockerfile, and infrastructure code for a new service.
Maintaining these templates is ongoing work. Every time your infrastructure patterns change, every golden path needs to be updated. The gap between what the templates generate and what production services actually look like tends to widen over time.
Infrastructure Provisioning
Terraform is the default for infrastructure provisioning. Teams write Terraform modules that encode organizational standards (VPC configuration, IAM policies, database sizing), and the platform exposes these as self-service options. Pulumi offers a similar approach using general-purpose programming languages.
The challenge is keeping Terraform modules current as cloud services evolve, managing state across hundreds of resources, and handling the drift between what's defined in code and what's running in production. A platform team of two to three engineers can spend most of their time on Terraform module maintenance alone.
Deployment
ArgoCD handles GitOps-style deployment to Kubernetes. Flux is another option. Both require Kubernetes expertise and ongoing maintenance of the deployment pipeline, including handling rollbacks, canary deployments, and environment-specific configurations.
Observability
Most build-path organizations integrate Datadog, Grafana, or New Relic, then create dashboards and alerting standards that apply across services. The platform team defines what metrics every service should emit, configures distributed tracing, and ensures logs are aggregated in a searchable way.
The Hidden Cost of DIY
The individual tools above are well-documented and widely used. The hard part is integration. A Backstage catalog that doesn't reflect what's actually deployed is useless. A CI/CD pipeline that doesn't match the infrastructure Terraform provisions creates drift. Environment management that doesn't include the same observability as production means bugs slip through.
Platform teams at companies that build their own IDPs typically have three to eight engineers working full-time on the platform. They're maintaining Backstage plugins, updating Terraform modules, debugging CI/CD pipelines, upgrading Kubernetes clusters, and fielding requests from product teams who need something the golden paths don't cover yet.
The initial build is the easy part. Year two is where the real cost shows up: keeping the platform current as tools release new versions, onboarding new infrastructure patterns, and handling the edge cases that golden paths don't address. Team Seven's Terraform module works differently from Team Three's because they forked it eighteen months ago and never merged back. The Backstage catalog says Service X is owned by a team that was reorganized six months ago. The preview environment system works for single-service PRs but breaks on cross-service changes.
For organizations with hundreds of developers, the return on a dedicated platform team is clear. The leverage of enabling 200 developers to self-serve justifies eight engineers maintaining the platform. For organizations with 20 to 50 developers, the math is harder. Those three to five platform engineers represent a significant fraction of your total engineering capacity, and they're not shipping product.
The Buy Path
The alternative to assembling your own IDP is adopting a platform that includes IDP capabilities as part of a cohesive product. Instead of integrating Backstage plus Terraform plus ArgoCD plus Datadog plus a custom environment manager, you adopt a single system that covers multiple layers.
Several platforms in this space bundle what would otherwise be separate IDP components:
Managed Kubernetes platforms (like Humanitec) add an abstraction layer on top of Kubernetes that handles environment management and deployment standardization. They assume you're running Kubernetes and want to make it more self-service.
PaaS platforms (like Heroku, Railway, Render) handle deployment and some infrastructure provisioning, but typically run on the vendor's infrastructure rather than your cloud account. They trade control for simplicity.
Infrastructure-from-code platforms take a different approach by inferring infrastructure from application code, removing the need for separate provisioning tools entirely.
Encore Cloud as an Example
Encore is an infrastructure-from-code platform that covers several IDP functions in a single product. Rather than assembling a platform from separate tools, Encore provides:
- Service catalog generated automatically from your codebase, including architecture diagrams, API documentation, and dependency graphs. No manual registration or Backstage plugins required.
- Environment management with preview environments for every pull request, staging, and production, all provisioned automatically with real infrastructure.
- CI/CD built in. Push code and Encore builds, tests, and deploys to your AWS or GCP account.
- Infrastructure provisioning handled automatically. Declare a database or Pub/Sub topic in your TypeScript or Go code, and Encore provisions the corresponding cloud resources (RDS, Cloud SQL, SNS/SQS, GCP Pub/Sub) in your own cloud account.
- Observability with distributed tracing and metrics built in, no instrumentation or external tool setup needed.
The trade-off is that Encore works with TypeScript and Go, deploys to AWS and GCP, and requires adopting its declarative patterns for infrastructure. You get a working platform without the integration and maintenance overhead, but within those constraints.
For teams that would otherwise need three to five engineers spending a year assembling Backstage plus Terraform plus ArgoCD plus an observability stack, a platform like Encore provides comparable self-service capabilities from day one.
Deciding Between Build and Buy
The build path makes sense when your organization has specific requirements that no existing platform covers: unusual compliance constraints, infrastructure patterns that don't fit standard tools, or a scale where the leverage of a custom platform justifies the engineering investment.
The buy path makes sense when your goal is enabling developers to self-serve standard infrastructure patterns (databases, queues, caches, environments) without dedicating a platform team to ongoing integration and maintenance work.
Questions worth asking:
- How many developers will the platform serve? Below 50, the cost of a dedicated platform team is hard to justify. Above 200, the leverage is clear.
- Do you have Kubernetes expertise in-house? Many IDP tools assume Kubernetes. If you don't run it today, adopting it as a prerequisite for your IDP adds significant complexity.
- What's your infrastructure scope? If you need databases, queues, and cron jobs on AWS or GCP, that's well-covered by existing platforms. If you need custom networking across three cloud providers with specific compliance requirements, you're likely building.
- How much ongoing maintenance can you commit to? The initial build takes months. Keeping it working takes years. Budget for both or buy.
The companies getting the most value from their internal developer platforms in 2026 are the ones that matched their approach to their actual constraints, rather than defaulting to "build" because it felt more in control, or "buy" because it seemed easier.