Choosing a Tech Stack Without Regret

Start from constraints, not preferences

• What does the team already know? Velocity in a familiar stack beats theoretical superiority in an unfamiliar one for at least the first year.
• Who can you hire? A niche language with a shallow local talent pool is a tax on every future vacancy.
• What does the problem actually demand? Most web products need a database, a request handler, and a front end; genuine requirements for exotic infrastructure are rarer than conference talks suggest.

Choose boring where it does not differentiate

The "choose boring technology" principle holds up: you have a limited budget of innovation tokens, so spend them where your product genuinely differs, and pick proven, well-documented tools everywhere else. Postgres, a mainstream framework, and a major cloud provider are unexciting precisely because they fail in known ways with documented fixes. Exciting failures are the expensive kind.

Design for replaceability, not permanence

You will be wrong about something, so the goal is making wrongness cheap. Keep business logic separate from framework plumbing, put clear interfaces around external services, and avoid deep coupling to any vendor's proprietary features until they earn it. A stack you can partially replace is a decision you can partially revise.

Finally, write the decision down: what you chose, what you rejected, and why. Future engineers inherit the reasons, not just the repository, and the documented context is what stops them from relitigating everything in year three.