Golden Bricks in Platform Engineering: How Composable Services Accelerate Delivery

Platform engineering should have a product focus, as developers are customers. – Daniel Bryant, GOTO Copenhagen 2026

---

The problem: fragmented tooling and soaring cognitive load

When I first moved from monolithic Java apps to micro‑services, the promise of independent deployment quickly turned into a nightmare of scattered tooling. Every team had to stitch together a database, a CI pipeline, a logging stack and a monitoring solution. The mental overhead of remembering which version of a Helm chart to use, which IAM role to grant, or which secret‑management API to call grew faster than the codebase itself. In practice, developers spent more time “making the plumbing work” than delivering business value.

Two symptoms dominate such environments:

1. High lead time – provisioning a new environment can take days, often because a ticket must be routed through multiple owners.
2. Unreliable releases – manual steps introduce variance, leading to a higher change‑failure rate.

Both symptoms are classic signals in the DORA metrics suite and directly impact the bottom line.

---

The solution approach: golden bricks, not golden paths

Bryant proposes flipping the mental model from a golden path (a single prescribed way to ship) to a set of golden bricks – small, composable, self‑service capabilities that developers can assemble into the workflow that best fits their problem. Think of each brick as a well‑defined API or CLI that abstracts a concrete piece of infrastructure:

Brick	Example	Consumer benefit
DB‑as‑a‑Service	Managed PostgreSQL instance provisioned via a REST endpoint	No need to understand cluster sizing or backup policies
CI‑as‑a‑Service	Parameterised pipeline definition submitted through a GitHub Action	Teams get a consistent pipeline without writing YAML from scratch
Feature‑Flag Service	Simple toggle API with rollout semantics	Rapid experimentation without redeployments
Observability Bundle	Centralised metrics, traces and logs exposed through a side‑car injector	Uniform telemetry without per‑team instrumentation decisions

The bricks are composable: a team can combine DB‑as‑a‑Service with CI‑as‑a‑Service and a Feature‑Flag Service to build a full delivery pipeline in minutes. Because each brick is a contract‑first API, the underlying implementation can evolve (e.g., switching from a self‑hosted PostgreSQL cluster to a cloud‑native offering) without breaking downstream code.

Architectural layering

Bryant visualises the platform as three concentric layers, each with clear boundaries:

1. Infrastructure orchestration – raw compute, storage and networking (e.g., Terraform, Pulumi). This layer never talks directly to application code.
2. Platform orchestration – the golden bricks themselves, implemented as managed services, operators, or SaaS integrations.
3. Application consumption – developer-facing CLIs, SDKs, or UI portals that invoke the bricks.

By keeping these layers separate, teams can upgrade the platform logic without touching the infrastructure layer, and developers can adopt new bricks without rewriting their applications. The separation also prevents the dreaded leaky abstraction where a change in the platform forces a cascade of changes in every consuming service.

---

Measuring success: adoption, experience, outcomes

Treating the platform as a product forces you to answer three questions, each tied to concrete metrics:

1. Adoption – How many teams are using each brick? Simple usage counters (API calls per month) reveal which bricks deliver value and which are dead weight.
2. Developer experience – How quickly can a developer provision a resource? The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) and the DX Core 4 (Time to First Success, Time to Resolution, Frequency of Use, Net Promoter Score) give a quantitative view of friction.
3. Business outcomes – What is the impact on lead time, deployment frequency, and change‑failure rate? These DORA‑style metrics close the loop between platform health and product velocity.

If adoption stalls, it is feedback: either the brick does not solve a real problem, or its API is too hard to use. If satisfaction drops, the platform team must iterate on documentation, SDK ergonomics, or error handling.

---

Trade‑offs and pitfalls

Trade‑off	Description	Mitigation
Flexibility vs. standardisation	Golden bricks give freedom, but too much freedom can re‑introduce inconsistency.	Define a core set of mandatory bricks (e.g., logging, security) and allow optional extensions.
Operational cost	Running managed services incurs cloud spend.	Use usage‑based billing and enforce quotas per team.
Leaky abstractions	If a brick exposes internal details, changes become painful.	Hide implementation behind versioned APIs and provide deprecation timelines.
Governance overhead	Product‑style roadmaps require stakeholder alignment.	Adopt lightweight OKRs focused on adoption and DX metrics.

The biggest mistake is treating the platform as a one‑off project. Without continuous feedback loops, the platform becomes stale, and developers revert to ad‑hoc scripts, recreating the original problem.

---

Practical steps to start building golden bricks

1. Map developer pain points – Conduct short interviews or analyse ticket data to surface the most frequent manual steps.
2. Prioritise low‑hanging bricks – Choose capabilities that are repeatable, have clear success criteria, and can be automated quickly (e.g., a “create‑namespace” API).
3. Define contracts first – Draft OpenAPI specs, SDK signatures, and CLI flags before writing any code.
4. Iterate with a pilot team – Release the brick to a single high‑traffic team, collect adoption and DX metrics, then refine.
5. Publish a product roadmap – Communicate upcoming bricks, deprecation plans, and SLA expectations.
6. Instrument everything – Export usage counters to a monitoring system (Prometheus, Datadog) and feed them into the adoption dashboard.

---

Real‑world example: Netflix’s “Model Lifecycle Graph”

Netflix recently open‑sourced its Model Lifecycle Graph (MLG) – a set of golden bricks for ML model versioning, validation and deployment. Each brick is a REST service with a stable contract, allowing data scientists to plug MLG into any CI pipeline. The result was a 30 % reduction in model‑to‑production lead time and a 15 % drop in rollback frequency, directly aligning with DORA metrics. The public repo is a good reference for building composable services: https://github.com/Netflix/model-lifecycle-graph.

---

Conclusion

Golden bricks shift platform engineering from a heavyweight “one‑size‑fits‑all” pipeline to a lightweight, composable product suite. The approach reduces cognitive load, accelerates delivery, and, when measured with adoption, experience and outcome metrics, provides clear evidence of business impact. The trade‑offs are real – you must balance flexibility with governance and guard against leaky abstractions – but the payoff is a platform that scales with the organisation rather than becoming a bottleneck.

If developers avoid the platform, that is feedback in itself. If the platform makes the right thing easy, developers will choose it. – Daniel Bryant

---

Author: Ben Linders – Agile, Lean and Continuous Improvement specialist. Follow him on Twitter @BenLinders.