Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    Internal Developer Platform

    The self-service layer a platform team offers product teams, run as a product with developers as customers. If you have to raise a ticket, it's a service desk, not a platform.

    Growingtended planted 1 min read
    On this page

    An Internal Developer Platform (IDP) is the set of self-service tools, templates and APIs that let product teams build, deploy and operate services without waiting on another team.

    Platform as a product

    The mindset shift is treating internal developers as customers. A platform team that works like a product team does user research, keeps a roadmap, measures adoption and earns usage, rather than mandating it.

    Self-service is the point. If developers need to ask someone, it’s not a platform; it’s a service desk with extra steps.

    Typical capabilities

    • Service scaffolding (Golden Paths)
    • CI/CD and environments
    • Infrastructure provisioning, often through infrastructure-as-code modules
    • Secrets management and access control
    • Observability wired in by default (Observability)

    Common building blocks: a developer portal such as Backstage, a service catalogue, templates, and an orchestration layer over cloud APIs.

    The Team Topologies framing

    In Team Topologies, stream-aligned teams deliver product value and a platform team exists to reduce their cognitive load by providing internal services. The default interaction is X-as-a-Service, with short facilitating phases while a team onboards.

    That cognitive-load lens is also how to decide what to build: platform the supporting capabilities every team repeats, buy the generic ones, and leave the core alone. See Where Platforms Fit: DDD Subdomains.

    Measuring success

    If the platform is working, delivery gets faster and safer. Lead time and deployment frequency should improve as friction drops, without change failure rate rising. That’s what DORA Metrics measure. Adoption, and what developers say in surveys, are the product metrics.

    In practice

    The closest I’ve come is building a low-code workflow platform: templates and reusable building blocks that let workflow designers ship new automation without writing a service each time. Same principle, different audience. The lesson that carried over: the platform’s real competitor is “we’ll just build it ourselves”, and you only beat that by being genuinely easier. More in Building a Low-Code BPMN Workflow Platform.

    • #platform-engineering
    • #idp
    • #team-topologies
    • #developer-experience
    • Building a Low-Code BPMN Workflow PlatformGrowing
      Internal Developer Platform · Where Platforms Fit: DDD Subdomains · API Modelling · Bulletproof React · Zustand Transient Updates · AJAX Polling
    • DORA MetricsGrowing
      DORA metrics are Observability for the delivery process, and the scorecard for an Internal Developer Platform: if the platform is working, these numbers move.
    • Golden PathsGrowing
      …once you know why. The full metaphor is in Golden Paths and the Recommended Routine, and the platform side in Internal Developer Platform.
    • Golden Paths and the Recommended RoutineGrowing
      …and versioned; reference modules, don't copy them. Measure whether teams actually find it faster — inside an Internal Developer Platform, adoption is the metric. Expect graduates. A path that nobody can leave has become…
    • Rolling Out an API GatewayGrowing
      Fallacies of Distributed Computing · Building a Low-Code BPMN Workflow Platform · Internal Developer Platform
    • Skill Trees as Platform Capability MapsGrowing
      …t teams actually ask for (the top of the tree), from interviews, not guesses — this is the product side of an Internal Developer Platform. Work downwards: for each, what has to be true first? Stop when you hit things tha…

    ↪ Links to (5)