PAPER
How to Actually Start a System
Most systems are not designed incorrectly. They are started incorrectly.
The failure does not begin in the middle of the system. It begins in the first few decisions, when the shape of the system is still undefined and the pressure to move is high. That is where most teams make the same mistake.
They start building before they know what they are building.
Systems do not fail because they were built poorly.
They fail because they were started without clarity.
This applies most directly to systems that have a defined starting point. Greenfield builds, major platform replacements, or systems where the initial shape can be decided before implementation begins.
The First Mistake
When a new system begins, the work usually looks like progress. Endpoints are defined. Schemas are created. Services are named. Tickets are written. Code starts to accumulate.
It feels productive because something is happening. But none of those activities define the system. They describe pieces of a system that has not yet been decided.
So the system begins to take shape through implementation. Each decision is made in isolation. Each piece works in its local context.
The system emerges instead of being designed. At first, this works. Then it compounds.
What Actually Needs to Be Defined
Before implementation begins, very little needs to be written. This is not about fully designing the system before writing code. It is about defining enough structure to prevent the system from drifting as it is built.
What does need to be defined is structural.
The first is the system boundary. What is this system responsible for, and what is explicitly outside of it. This is not a vague description. It is a line. If the line is unclear, the system will expand until it absorbs responsibilities it should not have.
The second is the primary flow. Not every flow. Not every edge case. The dominant path through the system. What happens from the moment input enters the system to the moment it produces a result. This defines how information moves.
The third is ownership of state. Where does state live. Who is allowed to change it. Under what conditions. If ownership is not defined early, it becomes shared. Shared ownership removes accountability. Once that happens, correctness becomes difficult to maintain.
These three decisions establish the structure of the system. Everything else builds on top of them.
What Not to Do
Most of the early work teams focus on is unnecessary at this stage. Full service decomposition is premature. Exhaustive domain modeling is premature. Schema is premature when it attempts to fully define the system before the system itself is understood — enough structure to validate ownership and flow is necessary, but no more.
These things feel like progress because they produce artifacts. But without a defined boundary, a clear flow, and explicit ownership, they are guesses.
Those guesses get encoded into code. Once they exist in code, they become harder to change. So the system stabilizes around early assumptions, whether they are correct or not.
The First Artifact
A system does not need a large design document to begin. It needs a small number of correct decisions written down clearly.
What is the system. What is it not. How does information move. Where does state live. Who owns it.
If those are clear, the system can be reasoned about before it is implemented. If they are not, the only way to understand the system is to read the code that produced it.
That is not design. That is excavation.
Transition to Implementation
Once the structure is defined, implementation changes. It becomes constrained.
Each piece of code has a place. Each service has a responsibility. Each interaction follows the defined flow.
At that point, development accelerates. Not because more people are working or tools are faster, but because decisions have already been made and understood.
Where AI Fits
AI amplifies whatever process it is given.
If a system is started without structure, AI will generate code that reflects that lack of structure. It will fill in gaps with assumptions and create connections that feel correct locally but are inconsistent globally.
If a system is started with clear boundaries, defined flow, and explicit ownership, AI becomes extremely effective. It is no longer guessing. It is executing.
The difference is not the tool. It is the starting point.
The Real Constraint
The reason teams avoid this work is that it feels slow. There is no visible output. No endpoints to demo. No code to review.
But this is where the system is actually determined.
Once implementation begins, most of the important decisions have already been made, either explicitly or implicitly. Defining them early is not overhead. It is the moment where they are still easy to change.
The Bottom Line
Systems do not fail because they were built poorly. They fail because they were started without clarity.
The first decisions constrain the system. Later decisions refine it, but they do so within the boundaries that were set early.
If those initial constraints are intentional, the system will hold. If they are not, the system will drift until it has to be corrected.
And correcting a system is always more expensive than starting it correctly.
Continue reading
Papers