Who builds and runs what
Treat layers and ownership as two separate dimensions. Layers are technical: web, mobile, BFF, services and data. Ownership is organisational: who delivers business value. Most of the trouble comes from mixing the two up.
Product teams own slices, the platform owns the foundations
Each product team cuts down through every layer for its capability. Platform teams cut across, but provide only each layer's foundations, such as templates, libraries, tooling and runtime, never the features.
| Layer | Search team | Checkout team | Payments team | Platform foundations |
|---|---|---|---|---|
| Web | Search pages | Basket and checkout pages | Payment form | Web platformApp shell, micro-frontend integration, web design systemMicro-FrontendsApp Shell |
| Mobile | Search feature module | Checkout feature module | Payment sheet module | Mobile platformCore module, module system, release train, mobile design systemApp ShellServer-Driven UI |
| BFF | Search BFF | Checkout BFF | Payment endpoints in the checkout flow | Backend platformBFF template, chassis and pipelineService TemplateMicroservice Chassis |
| Services | Search service | Order service | Payment service | Infrastructure platformService chassis, templates, mesh, API gateway, CI/CDMicroservice ChassisService MeshAPI Gateway |
| Data | Search index | Orders database and events | Payments ledger | Infrastructure platformManaged databases and the event broker, as self-serviceAsynchronous MessagingChange Data Capture |
A useful test: if a business feature has to wait on the platform team, the boundary is wrong.
Four kinds of team, and how they work together
Product (stream-aligned) teams
Own a business capability through every layer, and build and run it. Most teams are this type.
Works with others by: Consume the others: the platform as a service, enabling teams through coaching.
Platform teams
Own each layer's foundations and the cross-cutting contracts, offered as a self-service product. Never business features.
Works with others by: Consumed as a service. Collaborate briefly when building something new with a product team.
Enabling teams
Specialists in security, accessibility or performance who coach product teams for a while, then move on.
Works with others by: Facilitation, with a goal and an end date.
Complicated-subsystem teams
Own a component that needs scarce expertise, such as fraud scoring or the identity provider.
Works with others by: Consumed as a service through a clear API.
Read more in Team Interaction Modes, You Build It, You Run It and Inverse Conway Maneuver.
Keep each team's cognitive load manageable
The platform's job is to reduce how much each team has to know, not to do the work for it. No team can be expert in React, Swift, Kotlin, GraphQL, Kafka, Kubernetes, OAuth and observability all at once.
Limit stack diversity on purpose
Pick one or two blessed stacks per layer and publish them in a tech radar, for example TypeScript for web and BFFs, Swift and Kotlin or one cross-platform framework for mobile, and Java or Go for services. A team may choose something else, but it carries the cost.
Align stacks to make ownership possible
Writing the BFF in the frontend's language, often TypeScript, is a big part of why client teams can realistically own their BFF.
Offer a paved road per layer
A micro-frontend starter, a BFF starter and a service starter, each with logging, auth, CI and deployment already wired in, so a team starts a new component in minutes.
Run the platform like a product
As the organisation grows, the platform splits into teams that mirror the layers: web, mobile and backend or infrastructure. Organising these teams by layer is right, because their customers are other engineers, not end users.
Self-service over tickets
Teams use the platform through templates, APIs and documentation, without filing requests.
Optional but compelling
The paved road should be the easiest path, not a mandate. If teams route around it, that is feedback.
Thin
Build only what several teams already need, and extract shared pieces after you see duplication, rather than designing everything upfront.
Who usually owns each pattern
A typical split, for a setup like the one above. See layers and cross-cutting concerns for where each pattern sits.
Product teams · 17
Each product team applies this in the services, screens and data it owns. The platform may offer templates or examples, but the design decisions belong to the team.
Platform and product teams · 15
A platform team provides the building blocks, such as a library, a managed service or a standard, and each product team applies them in its own code and configuration.
Platform team · 7
A platform team builds and runs this once, as a self-service product that every product team uses without rebuilding it.