Technology decisions for a first version: decide now, or defer?
Which architecture choices are worth getting right before the first line of code, and which ones you can safely leave for later.
Founders building a first version usually hear two kinds of advice. One says plan everything properly or you will pay for it later. The other says just ship, you can fix it later. Both are partly right. The skill is knowing which decisions are expensive to change, and spending your care there.
Decide early: the choices that are hard to undo
- Your data model. Tables, relationships and identifiers spread into every part of the codebase. A few hours thinking about the core entities saves weeks of migrations.
- Authentication and user accounts. Retrofitting accounts, roles or organisations into a product built without them is painful. Choose a proven approach early.
- Where data lives and who can see it. Privacy, data location and access rules are far easier to design in than to bolt on.
- Your main language and framework. Pick something your team knows well and can hire for. Boring is a feature.
Defer: the choices that are cheap to change
- Microservices. A well-structured single application is faster to build and easier to run. Split it when you have a reason.
- Heavy infrastructure. A managed database and a simple hosting setup will carry most products much further than people expect.
- Premature scaling. Design so you can scale, but don't pay for scale you don't have.
- Building your own version of a commodity. Payments, email, search and analytics are usually better bought than built at the start.
Spend your care on decisions that are expensive to reverse. Move fast on everything else.
Build versus buy
A useful rule: build the thing that makes your product different, and buy or reuse almost everything else. If a feature is core to why customers choose you, owning it is worth the effort. If it is plumbing, a reliable service is almost always the better use of your time and money.
Leave room for AI without betting the product on it
If AI is part of your plan, keep the model behind a small interface in your code so you can change providers or models without touching the rest of the product. Store the inputs and outputs you are allowed to keep, so you can evaluate quality later. And make sure the product still works, more slowly or more manually, if the AI step fails.
Write decisions down
For every significant choice, write a short note: what you decided, what you considered, and why. It takes ten minutes, and it saves the next person, often you in six months, from re-arguing the same question.
Get a second opinion before the big ones
The cheapest time to fix an architecture mistake is before it is built. If you are about to make a decision that will be hard to undo, we are happy to review it with you, and to build it with you if that helps.