You have heard two things that sound like opposites: start small so you never over-build, and get the foundations right so you never paint yourself into a corner. Both are true, and the whole skill is knowing which one applies to the decision in front of you. Get it wrong one way and you build for scale you will never have; wrong the other way and a working app gets torn down and rebuilt. This page gives you the one rule that tells the two apart.
One question sorts every call
Before you add anything, ask one question: is this cheap to add later, or brutal to retrofit? If you can bolt it on the day you actually need it, defer it. Adding it before then is over-engineering, effort spent on a problem you do not have yet. If skipping it now forces a painful rebuild later, put a minimal version in today, so there is something to grow on.
Grow into scale you do not have yet
Most heavy machinery is cheap to add the day you need it. Deploy from your own machine while it is just you, and add continuous integration, a service that runs your tests automatically on every change, once a second person joins or the suite gets slow. Run one plain server before you reach for orchestration. Keep the app as a single program until real scale forces you to split it into separate services. Starting heavy here only buys you problems you do not have yet.
Invest early in what is brutal to retrofit
A few things are the deliberate exception: cheap to seed now, brutal to add later. Testing is the sharpest one. Start it from day one, even a thin near-empty scaffold, because adding one more test onto an existing habit is easy, while forcing tests into an untested app is brutal. You do not defer it the way you defer CI. The same holds for clean module boundaries so you can later split the app instead of rewriting it, your written spec, version control, and basic security. None has to be elaborate; each just has to exist. The Plan, Architect, and Test parts build these in full; here, just know they sit on the invest-now side.
GROW INTO IT LATER INVEST FROM DAY ONE
(cheap to add when needed) (brutal to retrofit)
---------------------------- ----------------------------
continuous integration testing, even a thin scaffold
extra servers, orchestration clean module boundaries
splitting into services the written spec
version control
basic security
Design so you can split, not rewrite
"Start small" only works if you started in a shape that can grow. The real expert skill is to design so you can split, not refactor: lay the seams that let a small thing scale later without a rewrite, so you neither over-build for scale you lack nor box yourself into a corner you can only escape by starting over. Knowing where those seams go is judgment, which is why this book is opinionated on purpose: for each decision it tells you whether to grow into it or invest now, and why. This page is the rule behind every one of those calls.
This prompt sorts your own project against the rule:
Act as a senior engineer sorting my build decisions.
I will list the parts of my project and what I am
tempted to add. For each one, tell me whether it is
cheap to add later (defer it, adding it now is
over-engineering) or brutal to retrofit (invest a
minimal version today). Give me the one reason for
each call, and flag anything that would force a
rewrite later if I skip it now.
My project and the decisions I am weighing:
Do this now: list every piece you are tempted to add, sort each into grow-into-it-later or invest-now, and set up only the invest-now side today.
