Emerging

A single front door to your platform, where developers go to deploy services, provision infrastructure, read documentation, and understand service health.

Without a unified portal, developers work around the platform, not through it. Shadow IT grows. The platform team has no visibility into what's actually being used. An IDP changes that and gives the platform team a product to own.

Start with a developer portal (Backstage is the default open-source choice). Catalogue your existing services. Add your CI/CD templates as scaffolding. Connect your cloud provider for self-service provisioning. Measure weekly active users from day one.

Opinionated, well-maintained ways to build and deploy a service. The path of least resistance that happens to also be the path of best practice.

Without golden paths, every team makes independent technology decisions. This produces inconsistency, security gaps, and a support burden the platform team can't sustain. Paved roads guide teams toward good defaults without mandating them, and that's the difference between adoption and enforcement.

Identify your top 2-3 service archetypes (REST API, async worker, and frontend app cover most teams). For each, define the stack, deployment pattern, observability setup, and security baseline. Package them as scaffolding templates in your IDP. Keep them maintained. An unmaintained golden path becomes a dead end.

Developers can create environments, databases, queues, and other common resources themselves, without opening a ticket or waiting for the platform team.

Every resource request that goes through a ticket is a tax on developer time and a drain on the platform team. If provisioning common infrastructure takes a week, developers find workarounds. Self-service removes the bottleneck and lets the platform team focus on building, not fulfilling.

Find the five most common infrastructure requests in your ticket queue. Build IaC-backed self-service workflows for each, triggered from the IDP or via GitOps PR. Add sensible guardrails (size limits, cost caps, required tags). Measure ticket volume before and after.

Defined, published reliability targets for the platform itself, so developers know what they can depend on and the platform team knows what they're accountable for.

Without SLOs, platform reliability is a matter of opinion. Developers say it's broken; the platform team says it's fine. Measured SLOs make reliability a shared fact and give the platform team the data to prioritise fixes over features.

Start with three capabilities: IDP availability, CI pipeline success rate, deployment frequency. Set targets. Build dashboards. Publish them to developers. Review them in your weekly platform meeting. Treat a breach as an incident.

Platform documentation that lives in version control, is updated alongside the code it describes, and is published automatically so it's actually current.

Documentation that's six months out of date is actively harmful. It sends developers down dead ends, destroys trust in the platform, and generates support requests that shouldn't exist. Docs-as-code makes keeping documentation current a normal part of shipping, not a separate task that gets skipped.

Move docs into Git repos alongside the code they describe. Pick a static site generator and automate publishing. Add a documentation check to your PR review template. Use your IDP to surface service-level docs automatically so developers find them without searching.