You are about to ask your agent to build the app, and it will happily generate whatever runs. Left alone, it pours every feature into one growing tangle that works on Friday and cannot be safely touched by Monday. This chapter gives you the one architectural decision that keeps the app changeable as it grows: build it as separate parts from the very first file.
4.1.1Separate concerns from the start
The oldest rule in software is separation of concerns: each part of the app does one job and knows as little as possible about the others. Payments handle payments, accounts handle accounts, and neither reaches into the other's internals.
You do not enforce this by hand. You tell the agent the app is made of distinct areas that each stay behind their own door, and you hold it to that every single time it adds a feature.
4.1.2Start with a modular monolith
A modular monolith is one program you run and deploy as a single thing, split inside into clear modules with clean lines between them. One app on the outside, many tidy rooms on the inside.
This is the right starting architecture for almost everyone. You get the simplicity of one codebase to run, build, and debug, plus the internal boundaries that let you change one area without disturbing the rest.
4.1.3Avoid the mud ball and premature microservices
Two failure modes sit on either side. The big ball of mud is what you get with no boundaries at all: every part reaches into every other, and one change ripples everywhere at once.
The opposite mistake is splitting the app into separate deployed services too early, premature microservices. A solo builder who does this trades a problem they have, organizing code, for problems they do not: networks between services, version mismatches, and failures spread across machines.
4.1.4A foundation that bends instead of breaks
Clean modules are what let the app bend instead of break. A new feature drops into the area it belongs to, a bug stays contained to one room, and you can hand your agent one module at a time without it needing the whole app in its head.
If you ever genuinely outgrow the single app, the boundaries you drew are the seams you cut along. A module with a clean edge lifts out into its own service; a mud ball has to be rewritten. You are not choosing against scale, you are earning the right to it later.
Do this now: before you generate a line of the app, write down the three or four distinct areas it is made of (say accounts, billing, notifications) and tell your agent to build each as its own module with a clean boundary, not one shared pile.
