⚙ Platform Engineering

The Platform Engineering Manifesto

Inspired by the Agile Manifesto, we are uncovering better ways of building and operating internal developer platforms — by doing it and helping others do the same.

Through this work we have come to value:

we value
Developer outcomes
over platform outputs
we value
Platform as a product
over platform as a project
we value
Golden paths
over golden cages
we value
Self-service
over ticket-driven operations

12 Principles

01
Make the right thing the easy thing — not the only thing
Golden paths guide developers towards safe, reliable outcomes with security built in by design. They must always include escape hatches for teams that need to diverge responsibly.
20 examples
02
Treat the internal developer platform as a living product
Platforms have no delivery date. They have users, roadmaps, feedback loops, and product lifecycles — and they must continuously evolve to remain useful.
20 examples
03
Measure from day one
Technical sophistication without adoption delivers nothing. Track adoption, lead time, change failure rate, and developer sentiment from the start.
20 examples
04
Manage everything as code
Infrastructure, pipelines, security policies, and golden path configurations belong in version control — testable, reviewable, and repeatable.
20 examples
05
Right-size your platform
Match complexity to organisational need. Build for the problem you have today, not the organisation you may one day become.
20 examples
06
Start with a minimal viable platform
Ship the thinnest platform that delivers real value to real teams, then iterate. Validate with actual users before building the next layer.
20 examples
07
Adopt before you build
Apply established patterns, open standards, and proven tools before writing bespoke solutions. Build only where genuine differentiation is needed.
20 examples
08
Deprecate gracefully
Every tool, API, and integration has a lifecycle — and retiring things gracefully is as important as introducing them. A published deprecation policy prevents the platform from becoming a museum.
20 examples
09
Build the foundation before the portal
A portal built on a broken foundation will be abandoned. Invest in capabilities, reliability, and contracts first — the interface amplifies what is already there.
20 examples
10
Treat developer experience as a product in its own right
The platform's interface — documentation, onboarding, error messages, and CLI ergonomics — is as important as its capabilities. Developer experience is not polish; it is the product.
20 examples
11
Invest in people, process, and culture — amplified by tools
Tools are multipliers, but only when the right culture and clear processes already exist. No tool compensates for a lack of product thinking or stakeholder trust.
20 examples
12
Define and honour the platform contract
The platform's job is to absorb operational complexity so developers need not manage it themselves. Make this deal explicit — through SLOs, documented ownership, and a published process for stepping off the path.
20 examples