Most tech stack regrets don't come from picking the "wrong" framework. They come from choices that didn't fit the team, the budget or the next two years of the business.
Here's the checklist we work through before writing any code.
01Start from constraints, not trends
Who will maintain this in two years? What skills are easy to hire for where you are? What's the budget for hosting and tooling? A popular, well-documented stack that your future team already knows is usually worth more than a newer option with a small community.
02Choose boring technology on purpose
Mature tools have known failure modes, plenty of answers online and stable upgrade paths. Save your "innovation budget" for the parts of the product that actually differentiate you — not for the database or the build system.
03One language across the stack, where it fits
Using TypeScript on both the web front end and the API, for example, lets the same developers work across both and share types between them. It isn't right for every project, but for small teams it removes a lot of friction.
04Default to a relational database
Most business software is full of relationships: customers, orders, jobs, invoices. A relational database such as PostgreSQL handles these well, enforces consistency and still supports flexible fields when you need them. Start there unless you have a clear reason not to.
If you can't explain in one sentence why you need something other than a relational database, you probably don't.
05Don't split into microservices too early
A well-structured single application is faster to build, cheaper to host and easier to debug. Split services out later, when a specific part genuinely needs to scale or deploy on its own.
06Pay for managed infrastructure
Managed databases, hosting and authentication cost a little more per month and save a lot of engineering time. For a small team, that trade is almost always worth it.
07Add monitoring from day one
Error tracking, uptime checks and basic logs cost little to set up at the start and are painful to add after something breaks in production.
The best stack is the one your team can still change confidently two years from now.
The short version
- Fit the team and the hiring market.
- Prefer mature, well-documented tools.
- Keep the architecture simple until it hurts.
- Buy managed infrastructure; build what differentiates you.
