Platform Engineering: Building an Internal Developer Platform

The problem an IDP is actually solving

Somewhere between "the ops team deploys everything" and "every developer is expected to be a Kubernetes, Terraform, and networking expert," organizations hit a wall. Shipping a new service requires a dozen tickets, three Slack threads, and tribal knowledge about which YAML incantation the pipeline expects. Cognitive load is the real bottleneck — not raw engineering talent, but the sheer amount of infrastructure detail a developer must hold in their head to get a change to production safely.

An internal developer platform (IDP) is the response: a curated, self-service layer that lets developers provision environments, ship services, and operate what they build without filing a ticket or learning the whole stack. Platform engineering is the discipline of building and running that layer as a product, with developers as its customers. Done well, it does not remove capability from teams — it removes toil, and puts the safe path within easy reach.

What an IDP is, and what it is not

An IDP is not a single tool you buy, and it is not "we installed a developer portal." It is an integrated set of capabilities that together form paved roads — supported, opinionated ways to do the common things. The core building blocks:

• A self-service interface. A portal, CLI, or API where a developer says "I need a new service" or "spin me a preview environment" and gets it, without a human in the loop for routine requests.
• A service catalog. A live inventory of what exists — who owns each service, its dependencies, runbooks, and health — so the platform is navigable rather than archaeological.
• Templates and scaffolding. Golden-path project templates that generate a new service already wired for CI/CD, observability, secrets, and security defaults — the difference between a good practice being documented and being the default.
• Infrastructure abstractions. Reusable, reviewed modules (Terraform, Crossplane, Helm) so a team requests "a Postgres database" instead of authoring cloud primitives and getting the encryption and backup settings wrong.
• A golden-path pipeline. A standard build, test, and deploy path most services ride for free.
• Baked-in observability and security. Logging, metrics, tracing, and policy enforced by the platform, not left to each team to remember.

The point is integration. Any one of these on its own is just tooling; wired together behind a self-service front door, they become a platform.

Platform as a product, not a project

The single biggest predictor of whether an IDP succeeds is whether it is run as a product. A project ends; a platform has users, a roadmap, and a lifecycle. Treating it as a product means a few concrete commitments:

• Developers are customers, and adoption is voluntary in spirit. If the paved road is slower or more painful than the workaround, engineers route around it. The platform earns usage by being the easiest correct option, not by mandate.
• You measure it. Track adoption of golden paths, lead time for a change, deployment frequency, and time-to-first-deploy for a new service. The DORA metrics are a reasonable north star for whether the platform is actually moving delivery.
• You gather feedback and iterate. A platform team that ships templates nobody asked for is building shelfware. Talk to the teams you serve, watch where they struggle, and pave the roads they actually walk.

This framing also clarifies staffing. Under the Team Topologies model, a platform team exists to reduce the cognitive load of stream-aligned teams delivering business value. Its output is a well-documented, reliable internal product — not a queue of tickets it services by hand.

Golden paths, not golden cages

The sharpest tension in platform engineering is between standardization and flexibility. Push too hard toward "one supported way" and you build a golden cage that blocks legitimate needs, breeding resentment and shadow infrastructure. Leave everything optional and you have a documentation site, not a platform.

The resolution is a golden path that is genuinely easier than the alternatives but not the only path:

• Make the common case effortless and the escape hatch possible. Most teams take the paved road because it is fastest; the few with real reasons to diverge can, and the platform learns from why they did.
• Enforce guardrails, not handcuffs. Encode the non-negotiables — encryption, network policy, tagging, identity — as policy the platform applies automatically. Leave genuinely reversible choices to teams.
• Version and deprecate deliberately. Paved roads change. Provide migration paths and support windows the way any product would, so improving the platform does not strand its users.

Good platforms constrain the dangerous and irreversible while leaving room for the creative and reversible.

Buy, build, or assemble

Almost no one builds an IDP entirely from scratch, and almost no one buys it whole. The realistic path is assembly — integrating a developer portal, a pipeline, IaC modules, and a secrets and policy layer into something coherent for your estate. A few decisions shape the effort:

• Portal. An open-source developer portal gives you the service catalog and a plugin surface for scaffolding and self-service. It is a framework, not a finished product — budget for the integration work.
• Provisioning. Decide whether infrastructure is requested through pipelines that run IaC, or through a control-plane approach where developers declare desired state and controllers reconcile it.
• Standards live as code. Templates, modules, and policies belong in version control and go through review like any other software, so the platform is reproducible and auditable rather than a hand-configured snowflake. Publish how the platform works as first-class internal documentation, because a self-service platform nobody understands is not self-service.

Do not overbuild. Start with the one or two golden paths that cover the majority of your services and expand from evidence, not ambition.

Where to start

Pick the single most painful, most repeated workflow — usually "stand up a new service" or "get a database" — and pave exactly that road end to end: template, pipeline, infrastructure module, and the security defaults, behind one self-service request. Ship it to two or three willing teams, measure their time-to-deploy before and after, and let that result recruit the next teams. Resist the urge to platform everything at once; a narrow paved road that people love beats a broad one nobody trusts.

Building an IDP is as much an operating-model change as an engineering one, and it rests on solid cloud infrastructure underneath the paved roads. If you want help designing a platform your developers actually adopt, or the foundations it runs on, talk to our team.