Inside the book

The Platform Problem

Why Good Teams Build Systems That Don’t Fit Together

Read the first chapters free Join early access

The problem

The failure does not start in the codebase.

It starts when many teams make locally correct decisions on a surface users experience as one system.

The symptoms look familiar: shared abstractions that break, uneven adoption, duplicated work, unclear support paths and standards that depend on memory instead of structure. The cost lands first on the people who use the system. Only later does it become visible as architecture.

A scan works one way in one application and another way in the next, in the same shift.
A design system protects yesterday's workflow while the product keeps changing.
A platform team becomes the queue every product team has to pass through.
Goals reward each team for local delivery, and the shared cost lands somewhere else.

Based on real systems

Eight years of platform work, told through the places where the architecture reached the people using it.

The book does not start from a framework. It follows real problems in warehouse operations, design systems, frontend architecture and team incentives, told in the order they happened.

A warehouse operator using four systems in one shift

The book starts on the warehouse floor, where the fragmentation of the organization reaches the operator, who pays for it with his attention.

A design system that froze the product's workflows

Shared components solved real problems. They also encoded the product as it was when we designed them, and the product kept changing.

A platform team accountable without authority

The team answered for the stability of the system but did not control what entered it. The book follows the design it created to change that, and what happened to it.

Who it is for

For people responsible for shared technical systems.

The book is written for engineers, tech leads and managers who build or operate systems that several teams share. The stories happen in frontend platforms for warehouse operations, but the same mechanism appears in backend platforms, data infrastructure, mobile tooling and internal APIs. You do not need to work on frontend to use it.

Staff engineers

For engineers asked to shape technical direction without owning every implementation detail.

Tech leads

For leads who turn local delivery pressure into choices that other teams can live with.

Platform teams

For teams building what other teams depend on, where control, support and adoption meet.

Engineering managers

For leaders balancing autonomy, coordination, accountability and the cost of shared systems.

Design system teams

For teams whose components, tokens and patterns become the shared language of product work.

Architects

For people whose decisions last long after the meeting where they were made.

You will get the most from it if

Your team builds something that other teams depend on.
You answer for problems in parts of the system you do not control.
A correct solution of yours was praised in meetings and then left out of the roadmaps.
Your shared libraries are used everywhere, and the product still feels like several systems.
You need to explain a technical problem to people who decide in product terms.

What you will learn

Decisions called technical also decide who pays the cost.

Each chapter starts from a real situation and shows the mechanism behind it. By the end of the book, you will understand:

Why good engineers, good tools and open forums still produce a fragmented system.
Chapter 1
How to recognize a layer that decides more than its name says.
Chapter 2
Why a correct fix does not spread, and when the lack of adoption is structural.
Chapters 3 and 5
How to treat technical decisions as product decisions about who pays which cost.
Chapter 4
Why a design system can freeze your product's workflows, and what to model instead.
Chapters 6 and 7
How failure changes when several teams compose code in one shared runtime.
Chapters 8 and 9
Why platform teams become a queue, and what happens when accountability and authority separate.
Chapters 10 and 11
Why an intact contract does not protect behavior, and which decisions cannot stay local.
Chapters 12 and 13
Who answers for a failure, and how incentives decide what happens to an architecture.
Chapters 14 and 15
What AI tools change in all of this, and what they do not.
Epilogue

What the book covers

A four-part argument about platforms, ownership and scale.

Each part looks at the same problem from a different position, because the author's role changes from one part to the next. Each part ends with Questions for Your Own Team, a short set of exercises for your own context.

Part I · Chapters 1–5

The Organizational Failure Mode

How many teams, each making decisions that are right for that team, produce a system nobody intended. Why good tools and good engineers do not fix it, why there are no purely technical decisions, and where individual influence stops.

Chapter 1One Business, Several SystemsFree to read
Chapter 2The Moment the Platform Stopped Being a LayerFree to read
Chapter 3The Browser PromptFree to read
Chapter 4There Are No Technical Decisions
Chapter 5The Ceiling of Influence

Part II · Chapters 6–9

The Shared Abstraction Trap

The story of a design system: what it did well, the workflows it froze, the new kind of failure that composition brought, and why a shared component cannot guarantee the same behavior for the person using it.

Chapter 6The Workflow We Froze
Chapter 7What the Card Was Made Of
Chapter 8Where the Complexity Went
Chapter 9The Scan That Did Not Feel Done

Part III · Chapters 10–13

Platform Architecture

A platform team in the middle of dozens of teams: the queue every change passes through, accountability without authority, contracts that stay intact while behavior breaks, and the design created to move decisions out of the queue.

Chapter 10The Queue
Chapter 11Accountable Without Authority
Chapter 12The Contract Was Intact
Chapter 13Decisions That Could Not Stay Local

Part IV · Chapters 14–15 and the epilogue

Operating at Scale

What a design for control does not cover, who answers for a failure, and the incentives that decided what happened to the design. The epilogue asks what AI tools changed, and what they did not.

Chapter 14Who Answers for a Failure
Chapter 15Architecture Follows Incentives
EpilogueThe Same Problems, Faster

The book opens with a prologue on the warehouse floor and ends with notes, a glossary and recommended reading.

How the book works

Real stories first, then questions for your own team.

The book shows each mechanism through what happened, and then helps you look for the same mechanism in your own team.

Step 1
A short introduction
Each part opens with a short introduction that prepares the stories ahead and the question they explore.
Step 2
Real stories
The chapters are stories told as they happened: the decisions, the mistakes, what each one cost and what the author understood from it.
Step 3
Questions for Your Own Team
Each part closes with questions and exercises that ask you to look at your own context and try something concrete, so your team can avoid the patterns you have just read about.

An exercise from the book

Pick a technical problem that has come back to your backlog more than twice without a real fix. Before choosing a technical solution, write down who owns the problem as a product outcome. The question is about the person responsible for the user experience this problem creates, and not the person who owns the code. If the answer is “nobody, formally”, the problem is a product decision being made by accumulation, by each team on its own, without anyone noticing.

Part I, Questions for Your Own Team · Who owns the problem as a product (chapter 4)

What you will try with your team

Rewrite an item of technical debt as a product risk, and compare how people react to each version.
Trace a recent incident that crossed teams to the point where two pieces of correct code met.
Check whether the last lesson your team learned the hard way is written where the next team will meet it before its code ships.
When leadership asks for a specific solution, write the goal behind it in one sentence, and look for a cheaper way to reach it.
Write how a structural change would move the number your leadership actually looks at, and when.

In four parts, from the warehouse floor to the platform team: 15 chapters
And exercises for your own team, at the end of each part: 47 questions
With the sources the book cites and eleven recommended readings: Notes and glossary

Early access

Be the first to know when the book is out.

Join the early access list. You will also get publication notes and new articles.

No spam. Only updates about the book and related essays.

Written by Walker de Paula, a software engineer and technical leader who spent eight years building shared frontend systems for warehouse and logistics operations. About the author