The architecture decisions you can safely defer
Most architecture advice for early-stage products is a list of things to avoid. That framing is not useful, because the interesting question is never whether something is good practice. It is what happens if you turn out to be wrong.
Reversibility is the axis that matters. A decision you can undo in an afternoon should be made quickly and revisited when it hurts. A decision that requires a data migration, a coordinated deploy and a week of everyone's attention should be made once, carefully, at the start.
This sounds obvious written down. It is not how most early architecture conversations actually run, because the decisions that feel weighty are the ones with vendor names attached, and those are usually the cheap ones to change. The expensive decisions tend to be small, unglamorous, and made in the first week by whoever was writing the first migration.
Cost to reverse, not cost to build
Teams tend to sequence architecture work by how expensive it looks to build. The better sequence is by how expensive it is to change later, and those two orderings are almost inverted. Adding a caching layer is a large piece of work and easy to remove. Choosing how you identify a tenant is fifteen minutes of work and touches every query you will ever write.
The asymmetry compounds. A reversible decision made badly costs you the price of reversing it, once. An irreversible decision made badly costs you a fraction of every piece of work you do afterwards, forever, and that tax is invisible because you never see the version of the codebase where the decision went the other way. Teams do not notice they are paying it. They notice that everything takes slightly longer than it should and cannot say why.
One caveat on the chart: these costs scale with how much code exists, not with how much time has passed. A team that has shipped nothing for six months can still reverse most of them cheaply. A team that has shipped hard for six weeks may already be past the point where tenancy is worth changing. Volume of code is the clock that matters.
Safe to defer
Service decomposition. A well-organised monolith with clear module boundaries can be split later, and the split will be better informed because you will know where the real seams are. Splitting early guesses at seams and then hardens the guess into a network boundary.
The signal to watch for is deployment coupling rather than code size. When two parts of the system have to be released together every time, and different people own them, the seam has announced itself and the split is now informed rather than speculative.
Caching. Add it when a query is slow and you can name it. Caching added before there is a measurement is a source of stale-data bugs paid for in advance.
The same reasoning applies to queues and background workers. Both are correct answers to problems you can name and expensive answers to problems you are anticipating. A synchronous call that takes 200ms does not need a queue in front of it, and putting one there converts a simple failure into a distributed one.
Multi-region. Almost always premature, frequently expensive, and rarely what your latency problem turns out to be.
When latency is genuinely the complaint, it is usually the number of sequential round trips rather than the distance of each one. Fixing that is a week of work in the application. Multi-region is a quarter of work in the infrastructure and does not fix it.
Container orchestration. A platform-as-a-service will carry you a long way. Move when the constraint is real, not when the architecture diagram feels insufficiently serious.
The honest test is whether anyone on the team has operated the thing you are proposing at three in the morning. If not, you are adding a system that will need to be learned during the first incident, which is the worst possible time to learn it.
Your own design system. Use something off the shelf and restyle it. The decision to build your own is reversible in weeks and almost never urgent.
Everything in this list shares a property: the cost of deferring is bounded and visible, and the cost of doing it early is unbounded and hidden. That is the pattern worth learning, because it generalises to decisions I have not listed.
Decide once, at the start
None of these five requires a long meeting. Each is an hour of thinking and a paragraph of justification, and doing them properly in week one is the cheapest engineering work available at any stage of a company. They get skipped because in week one they are decisions about a product that does not exist yet, and it feels premature to spend an hour on tenancy when there are no tenants.
Ask what fraction of the codebase changes if this turns out to be wrong. Below a tenth, decide now and move. Above half, spend the afternoon.
The test has a useful second form for arguments that will not resolve. If two engineers disagree and neither can name what fraction of the codebase changes under each option, the disagreement is about taste and should be settled quickly, in the room, by whoever will maintain it.
Deferring is not neglecting
A deferred decision should be written down as deferred, with the condition that will force it. "We are on a single Postgres instance; we revisit at 500 writes per second." That sentence in a repository document is the difference between a deliberate choice and a thing nobody got round to, and it is the difference an incoming CTO or a technical due-diligence reviewer will notice immediately.
In practice this is ten lines of markdown per decision. Teams that keep them ship faster, because the same argument does not get relitigated every quarter by whoever joined most recently.
It matters commercially too. Technical due diligence looks for exactly this. A reviewer who finds a single Postgres instance and no explanation assumes nobody thought about it. A reviewer who finds a single Postgres instance and a note saying the team revisits at 500 writes per second concludes that the team knows what it is running, which is a materially different assessment of identical infrastructure.
