Early technology decisions are made with the least information and are the hardest to reverse. The goal is not to pick the perfect stack but to avoid choices that become expensive to undo.
Optimise for change, not scale
Almost no early product fails from insufficient scale. Many fail from being too slow to change. Prefer boring, well-documented technology with a large hiring pool over something novel that impresses.
Questions worth answering honestly
- Can we hire people who already know this in our market?
- Who operates it at three in the morning?
- What does the documentation and community look like in five years?
- How hard is it to extract our data if we leave?
Where to allow complexity
Spend your complexity budget on whatever genuinely differentiates your product. Everything else should be the dullest option that works: managed databases, standard frameworks, conventional deployment.
Avoid one-way doors
Keep business logic out of vendor-specific services where you reasonably can, keep your data model portable, and avoid coupling everything to a single provider's proprietary features unless the gain is decisive.
Write the decision down
Record what you chose, what you rejected and why. In two years the reasoning matters more than the decision, and nobody will remember it.
Choose the technology your team can still operate confidently on a bad day, not the one that looks best in an architecture diagram.
Where to start
Write a one-page record for your three biggest technology decisions. If you cannot justify one in writing, reconsider it now rather than later.
