Article
Founders are told to avoid premature optimisation, and it is good advice. Most early technical decisions are cheap to change: the framework, the hosting, the CSS approach, the queue. Swap them when they hurt. But a few decisions are expensive to reverse, because every feature built afterwards assumes them. Getting those right in the first week is not premature; it is the one place where planning pays for itself many times over.
1. Where the boundaries between tenants and users live
If your product serves organisations, the question is how data belongs to them. Is a record owned by a user, by an organisation, or by both? Can a user belong to two organisations? Can data move between them? Every table, every query, and every permission check encodes the answer, and changing it later means touching all of them.
Decide it explicitly. Write the model down: organisations own data, users are members with roles, a user can belong to many organisations. Then enforce it in one place, usually a row-level policy or a base query, rather than trusting every developer to remember. The cost of getting this right in week one is a day. The cost of retrofitting it into a product with customers is a quarter.
2. What is the unit of money, time, and identity
Three fields cause a disproportionate share of production bugs: amounts, timestamps, and identifiers.
Amounts stored as floating-point numbers drift. Store integers in the smallest unit of the currency, with the currency alongside, and do arithmetic in that unit. Timestamps stored without a timezone are ambiguous forever; store UTC and convert at the edge. Identifiers that are sequential integers leak information and cannot be generated by clients; identifiers that are random are safe and mergeable.
None of these are hard to do at the start. All of them are painful to change once there is data, because a migration has to guess what the old values meant.
3. Which system is the source of truth for each fact
Products integrate: a CRM, a payment provider, an email tool, a warehouse. Each holds a copy of something, such as the customer's email address, their plan, or their address. When two copies disagree, which one is right?
If this is not decided, it is decided by accident, differently in each place the data is written, and the disagreements surface as support tickets. Decide it per fact: your database owns the customer's plan, the payment provider owns the card, the CRM owns the sales notes. Sync in one direction for each fact and write the direction down.
What these have in common
Each decision is invisible when it is right and everywhere when it is wrong. None require much code. All require someone to have seen the consequences before, which is the argument for having a senior engineer in the room for the first week even if the build itself is small.
The rest of the architecture can be wrong and fixed. These three are the ones to get right before the second feature is built.