Build Your Internal Developer Platform Last

I joined Brian Teller on his podcast, Ship It, last week to talk shop. This post pulls one thread from that conversation.

Here's how I've come to think about an internal developer platform (IDP — not an identity provider): it's the icing on the cake. A Backstage, a Port, a well-designed homegrown portal — that's the reward you give your team and your developers once the cake underneath is baked. Worth wanting. Worth waiting for.

A quick note on who this post is for. If Kubernetes and the underlying platform are someone else's problem in your organization — your company has a dedicated platform team, or you're consuming a managed service — then have at it. Trust your platform people. Build whatever portal helps your developers move faster. The rest of this post is for the team that owns the whole stack: the team that's responsible for making the cake and icing it.

If that's you, here's what I've learned.

The IDP delivers on its promise when the foundation underneath is conventionalized. When every service has the same shape, every Terraform repo follows the same layout, every auth flow is modeled the same way — then a portal can expose all of that uniformly, and you actually get the experience you were hoping for. Without that consistency, the portal becomes a window onto whatever's already there. And what's already there, for most teams, is a lot of working infrastructure that just doesn't look the same from one corner to the next.

That's worth saying clearly: most teams have built plenty. AWS accounts, VPCs, Terraform modules, CI pipelines, IAM policies — often a lot, often for years. The gap isn't "they haven't built anything." It's that what's been built is ad hoc. Service A's auth flow is different from service B's. Repo A's directory layout is different from repo B's. There's no framework underneath, no shared conventions, no consistent shape an automation layer can rely on.

That's the gap a framework closes. And once that gap is closed, the IDP question changes shape entirely.

Why Order Matters

The reason it's worth getting the order right isn't aesthetic. It's that early decisions get baked in. Reorganizing accounts a year later is a migration. Relocating Terraform state across forty repos is a migration. Walking back an authentication model after every team has wired into it is a migration. The earlier you lock in conventions, the more value you get from them — and the less you spend later untangling what was put in place ad hoc.

So the conversation I want to have isn't "stop reaching for Backstage." It's "here's what makes Backstage — or any IDP — actually deliver." It comes down to the same handful of things every time.

What an IDP Actually Buys You

An IDP does a few things really well. It catalogs services in one place. It exposes self-service workflows for things developers do all the time — provisioning, scaffolding, requesting access. It standardizes the path from "I want a new service" to "the new service exists."

What it can't do is conjure consistency where there isn't any. If the underlying services don't all expose the same metadata, the catalog is partial. If the provisioning workflows have to special-case half the targets, the self-service experience is brittle. If the scaffolding produces something different from what the team would build by hand, developers route around it.

Backstage is genuinely good at the right scale. Spotify built it because Spotify needs it — and Port's analysis pegs the team needed to actually extract value from Backstage at 7 to 15 engineers, citing Gartner's recommendation to dedicate up to ten engineers to it for years. That's a real cost. Most teams don't have those engineers to spare, which makes it doubly important that the foundation underneath is in shape so you're not paying that cost twice.

What "Foundation" Looks Like

The foundation is the part of platform engineering that gets glossed over because it isn't visible. People talk about "platform engineering" as if it's one thing. It's actually a stack of concerns, every one of which exists whether or not you have a portal in front of it.

Most teams have versions of these pieces already. The work isn't building from zero — it's bringing what exists onto a single shape so an automation layer (a portal, an AI agent, a script) can reason about it.

I've spent the last eleven years at Cloud Posse focused almost entirely on this layer — zero to one on AWS. It's a humbling realization that you can spend an entire career on cold starts. There's just that much underneath.

A Framework Is What Conventionalizes the Foundation

There's a familiar line in the Terraform community: "We don't use wrappers. We just write vanilla HCL."

I get the impulse. But most teams that have run Terraform for more than six months have built a wrapper. They just call it scripts and READMEs and tribal knowledge. They've reinvented file layout, state management, environment promotion, role assumption, toolchain installation — every time, in private. That isn't really vanilla. It's an undocumented framework.

Web developers don't start projects from index.html. They start from React, Next.js, Rails, Django. The framework gives them conventions for naming, layout, routing, deployment — so they can spend their time on what their app actually does. A real framework for infrastructure does the same. Atmos is the one we built. It's not the only valid choice. The choice that's hard to recommend is pretending you don't have one when you do.

A framework is what turns a pile of working-but-different infrastructure into something a portal — or a script, or an AI agent — can reason about. It's also what gives a new hire a fighting chance, because the conventions live in code and docs instead of in someone's head.

Reviews Are the Other Half of the Foundation

A beat I owe to Adam Jacob, who said it cleanly at Config Management Camp in Belgium earlier this year: speeding up coding is meaningless if reviews and QA can't keep up.

That hits different in the AI era. Generative AI is shipping pull requests at vibe-years speed. The bottleneck moves to review. Without consistent naming, predictable layout, and legible intent, every change asks reviewers to read every diff line by line — and that doesn't scale.

This is exactly where the framework pays you back. When every service has the same shape, reviewers can trust diffs structurally. When repos are laid out the same way, you stop re-learning the codebase every time. That's a foundation feature, not a portal feature — and it's what makes shipping at AI speed actually safe.

The Portal Has Competition Now

Here's the part I find most interesting.

Self-service used to mean: build a portal, wire it to your IaC, expose forms. Train your developers to use it. Maintain it forever.

That's changing. With agentic editors — what some are starting to call the ADE, the agent developer environment — and with MCPs that expose your AWS, your telemetry, your logs, your internal services, and per-repo agent skills that encode your team's conventions, the editor itself becomes a self-service surface. Code stays the artifact. Developers describe the infrastructure they want in plain English. The framework grounds the output. Reviewers see a clean, idiomatic PR.

That doesn't kill the IDP. It does mean the IDP is one option for self-service rather than the only one. Some teams will still want a polished portal for non-engineering users, for guardrails around sensitive workflows, or because the developer experience is itself a product. Others will find that with a framework and good agent skills, the editor is enough.

This isn't theoretical. It's what we're doing inside Cloud Posse every day — conversing with the editor, manifesting infrastructure, running it through pipelines that just work. The same approach we wrote about in Why Terraform Is More Relevant Than Ever in the AI Era. Frameworks plus skills plus MCPs plus a foundation that knows what it's doing.

So When Does an IDP Make Sense?

At Spotify's scale, with Spotify's headcount and number of services, an IDP is clearly the right answer. Lots of organizations are big enough — and have enough developers and consumers — that centralizing the developer experience behind a portal pays for itself many times over.

For everyone else, the question I'd encourage is: what would the IDP provide that you're not already getting from your ADE — the agentic developer environment described above? Start there. If the answer is "the catalog would still be partial, the workflows brittle, the scaffolding inconsistent" — that's not a failure. That's a signal that the foundation is still shaping up. Worth doing for its own sake. The icing is better when it goes on a cake that's actually finished baking.

So the order I'd suggest: adopt a framework. Lock in conventions. Get the accounts, the network, the DNS, the IAM, the TLS, the toolchain, the auth flows, and the review pipeline shaped consistently across every service. Decompose your monolithic Terraform root module into services that can evolve on their own. Get to where shipping a change is boring. Then ask whether the portal is the right next step — and either way, you'll be deciding from a much stronger position.

If you're somewhere in the middle of that and want a second set of eyes — the kind of conversation that helps you figure out what you've already built versus what's still worth conventionalizing — let's talk.