Guide

Delivery

Platform as a product

Treat internal engineers as customers, measure adoption and time to a safe production deploy, and choose a thin platform over a thick one until a clear need forces a thicker abstraction.

89 of 162 · 2 min read

A platform succeeds when internal engineers choose it and get value from it. That makes the platform a product, and the engineers using it are its customers. The product mindset changes what the platform team measures, documents and builds. It also changes what gets refused.

The big idea

Think of a software company that sells a library. Its success depends on whether developers choose the library, keep using it, and say so. Building features nobody asked for does not help. Internal platforms work the same way. The customers are other engineers, and they can always go around you.

Walking through it

Good platform teams do these things:

  • Know the users and their jobs. Who are you building for, such as a product backend, an ML team or a mobile team? What job are they hiring the platform for, such as "run a stateless API" or "run a scheduled job"?
  • Measure adoption. Track the percentage of services on the golden path, the time to first deploy, the median CI duration, and the tickets for things the path should do itself. Survey customers each quarter with structured interviews.
  • Write documentation by task. Pages such as "deploy a new HTTP service" help more than reference alone. Version the docs with the platform.
  • Offer a support model. Office hours, a chat channel with response targets, and enabling engagements for migrations. A ticket queue alone is not enough.
  • Deprecate deliberately. Announce, run both versions, migrate, then delete. Zombie internal APIs are how platforms become hated.

Roadmaps should be visible inside the company. Priority comes from user pain, such as noisy deploys, slow CI, or missing self-service, rather than from interesting projects. A platform team that ships a service mesh nobody asked for while CI takes forty minutes has missed the product.

Trade-off

A thin platform is templates, shared CI and a catalog. A thick platform is a custom deployment API, an internal PaaS and a DSL. Thin platforms ship faster and stay debuggable with the upstream tools. Thick platforms can give a better experience, but they risk becoming a small product that lags Kubernetes and the cloud by years. Start thin, and go thicker only when a clear, repeated need forces it. Staff a thick platform like a real product.

Common mistakes

  • Measuring tools built. That rewards the trap. Measure adoption and time to a safe deploy.
  • No deprecation plan. Old internal APIs linger and drag the team down.
  • Support by ticket only. Teams get stuck waiting, and stop asking.

Check yourself

  1. What should you measure to know the platform is working? Adoption, time to a safe production deploy, and the number of tickets for things the platform should handle itself.
  2. Why is a thin platform the safer default? It composes upstream tools that stay debuggable, and it ships faster. A thick platform is harder to staff and easy to fall behind on.

Key takeaways

  • Treat internal engineers as customers, and measure what they gain.
  • Document by task, support with office hours and enabling work, and deprecate deliberately.
  • Default to a thin platform, and go thicker only when a repeated need forces it.

Further learning

The overall platform picture is in platform engineering. The build-or-buy decision is in build vs buy.

Team Topologies key conceptsExplore key concepts of Team Topologies: four team types, interaction modes, platform-as-a-product, and more. Tools and practices included!Team Topologies - Organizing for fast flow of value

Platform engineering

Internal developer platforms, golden paths and treating infrastructure as a product. Cut cognitive load without building a second Kubernetes.

Golden paths

A golden path is an opinionated, maintained way to create, ship and observe a service. It should be the easy default, not a prison, and the test is whether a new hire can reach production in a day.

Build vs buy for platforms

Most platform parts should be bought or taken from open source. The homegrown PaaS trap is a custom YAML dialect that only three people understand, and that nobody funds to upgrade.