Scope creep is an architecture failure.
Most disputed change requests trace back to a boundary nobody drew. So we draw it — what gets built, what stays, and where each number comes from — and everybody signs it before a line is written.
Thirty minutes · no predetermined package
Three documents, one page each.
Longer than that and nobody reads it, which defeats the point.
The current state — every system, what it holds, and which fields overlap.
The intended state — the same picture after the work, with the differences marked.
The boundary — what we build, what stays configured, and what nobody touches.
The ownership table — per field, which system wins when two disagree.
The first slice — what ships first, and why that piece rather than another.
What we are deliberately not solving, which is usually the longest list.
The document that makes change a decision.
What people ask about the architecture stage.
What is the boundary document?
One page stating what gets built, what stays configured, and what nobody touches. Signed before any code, and referred to whenever scope is questioned.
Why draw before building?
Because a wrong data model is expensive to unwind and a wrong feature is not. The decisions made in this week are the ones that are hard to reverse.
What if the architecture turns out wrong?
It sometimes does, and the document says what would make us redraw. Changing the picture deliberately is cheaper than discovering it during delivery.
Does this slow the project down?
It moves a week from the end to the beginning. Projects without it spend that week arguing about scope in month three.
Who needs to sign it?
Whoever will be asked to approve a change later. If they did not read the picture, they will dispute the boundary.
Can we use this with a different developer?
Yes. It is a description of your systems and your decisions, not a proposal.