Why architecture should start before the first sprint
15 March 2026Treating architecture as a later concern is one of the most expensive decisions a team can make. The cost of change compounds quickly once the codebase has momentum.
Architecture is not a phase — it is a context. When teams defer it, they are not postponing decisions. They are accumulating debt that every future feature will pay.
This does not mean UML diagrams before a single line of code. It means two or three days of asking the right questions before you start writing: How does data flow? What are the domain boundaries? How will components communicate? What classes of failure should we expect?
In every real project I have worked on, technical debt almost never comes from poorly written code. It comes from architectural decisions made too early without context, or too late when change is already expensive.
The second sprint is too late to discover that your entire service depends on a shared database that three other teams also write to. The fourth sprint is too late to realise that your event model does not cleanly separate commands from queries.
Reserve the time. Ask the questions. Draw the diagram on the back of a postcard. Then start writing code.