Every few months a new framework promises to make you ten times faster. Most teams that adopt one discover the same thing: the framework was never the bottleneck.
Start boring on purpose
The stack you pick is a bet on what you will be able to debug under pressure. When something breaks at 2am — and it will — you want a stack where the error message leads somewhere, the Stack Overflow answers are five years deep, and the person on call has seen the failure before.
That usually means:
- Pick what your team already knows. A familiar tool at 80% of theoretical speed beats an unfamiliar one at 100%.
- Pick what hires well. You are choosing the pool of people who can help you later.
- Pick what fails loudly. Silent failures cost more than slow ones.
The best stack is not the fastest one. It is the one your team can reason about when it misbehaves.
A default that works for most products
For a web product with users, payments and data, this gets you a long way:
| Layer | Default | Why |
|---|---|---|
| Web | Next.js | One framework for pages, routes and API |
| Data | Postgres | Relational until proven otherwise |
| Auth | Managed provider | Do not build sessions yourself |
| Payments | Stripe or Razorpay | Regulated, well documented |
| Hosting | Vercel / Fly / Render | Deploy on push |
You can replace any row later. That is the point — each is a component, not a foundation.
Where complexity actually comes from
It is rarely the language. It is:
- Too many services too early. Three repos and a message queue before product-market fit is a tax you pay daily.
- Premature abstraction. The interface you write before the second use case is almost always wrong.
- Config sprawl. Every environment variable is a way for production to differ from your laptop.
A useful test before adding anything:
Can I explain, in one sentence, what breaks if I remove this?
If the answer takes a paragraph, you do not need it yet.
Decide once, write it down
The most valuable artifact is not the stack — it is the short document that says why. Six months on, someone will ask why you are not using the newer thing. A paragraph written while the reasoning was fresh will save that argument.
Keep it to one page:
- What we chose
- What we rejected, and the one reason why
- What would make us revisit
What to do this week
Pick the boring option, ship something a real person uses, and let the pain tell you what to change. Architecture decisions made against real traffic are worth ten made against a whiteboard.