Platform Engineering & Internal Developer Platforms

What separates high-performing engineering organizations from the rest isn't necessarily better engineers. It's better systems for engineers to work within.

That's the promise of platform engineering — and specifically, of Internal Developer Platforms (IDPs): a curated set of tools, workflows, and self-service capabilities that let developers do their jobs without becoming accidental DevOps engineers.

What is an Internal Developer Platform?

An IDP is not a specific tool. It's a capability — a collection of APIs, UIs, and integrations that abstract away the complexity of infrastructure, deployment, and operational concerns.

Think of it as the "paved road" your engineers drive on instead of cutting through the woods every time they need to spin up a service, deploy an update, or provision a database.

A mature IDP typically provides:

• Self-service provisioning — developers can create environments, services, and resources without filing tickets
• Golden paths — opinionated templates for common patterns (new service, new pipeline, new data store)
• Service catalog — a single place to discover all services, their owners, their SLOs, and their dependencies
• Deployment workflows — standardized CI/CD that's tested and maintained centrally
• Observability integration — logs, metrics, and traces wired up by default

Why organizations build IDPs

The usual trigger is friction. Specifically:

• Onboarding new engineers takes weeks because there's no standard way to set up a local dev environment
• Every team has its own bespoke Dockerfile and CI pipeline
• Infrastructure changes require Slack threads with the platform team
• Nobody knows which services are still in production vs abandoned

At scale, this friction compounds. A 10-engineer company can absorb it. A 100-engineer company starts missing releases. A 500-engineer company starts losing engineers.

The key components

Self-service provisioning

The most valuable thing an IDP can do is let engineers provision what they need without waiting. This doesn't mean giving everyone root access — it means building approval workflows and guardrails into a self-service interface.

Tools like Backstage (Spotify's open-source developer portal) provide the UI layer. Behind it, you might have Terraform modules, Helm charts, or Crossplane operators doing the actual provisioning.

Golden paths, not golden cages

The term "golden path" comes from the Netflix engineering blog. A golden path is the recommended, supported way to do something. It's optimized, documented, and maintained.

The key distinction: golden paths are opt-in, not mandated. Teams can deviate when they have good reason. But deviation means you're on your own.

Compliance by default

A well-designed IDP bakes compliance into the path of least resistance. Logging? Enabled by default. Secret management? The golden path uses Vault or Secret Manager, not environment variables. RBAC? Configured automatically based on team membership.

When compliance is easy, teams follow it. When it's friction, they work around it.

When to build one

You probably don't need a dedicated platform team until you have 40+ engineers. Before that, a few well-maintained Terraform modules and a documented Makefile get you surprisingly far.

The inflection point is when:

• Your CI/CD pipeline is a maze that only one person understands
• New service setup takes more than half a day
• You're having "standards" conversations repeatedly across teams

Build vs buy

Backstage is the de facto open-source choice. It's powerful and extensible, but it's not a small investment — plan for a team to own it.

Alternatives that take less setup: Port, Cortex, and OpsLevel all offer managed IDP features with less infrastructure overhead. If you're on a smaller team and want the benefits without the maintenance, these are worth evaluating before committing to self-hosted Backstage.

Starting without a platform team

You don't need to hire a "platform team" to start. The most impactful early wins:

1. Standardize your CI/CD templates — one reusable GitHub Actions workflow that all services inherit
2. Create service templates — a create-service script that scaffolds a new service with logging, health checks, and basic observability wired in
3. Build a simple service catalog — even a well-maintained Notion page or GitHub repo listing services and owners is better than nothing
4. Automate onboarding — a script that sets up a dev's local environment in one command

These don't require a platform team. They require someone who cares about developer experience enough to invest a sprint.

---

Platform engineering isn't about building cool tools. It's about removing friction from the people building your product. Start small, measure impact in developer time saved, and grow from there.

We help engineering teams design and implement internal developer platforms — from initial architecture through Backstage deployment and adoption. Get in touch if you're thinking through this problem.