Every two or three years, a new framework appears, the conference circuit lights up, and a wave of teams scrap working systems to chase it. Six months later, half of those projects are stuck in the "almost migrated" phase, and the framework's GitHub commits have slowed to a trickle.
We've watched this cycle long enough to develop a simple filter: three questions, asked in this order, that have saved our clients real money.
Question 1 — Will it be here in five years?
This sounds obvious, but it's the question most teams skip. The honest answer is rarely about technical merit — it's about adoption, funding, and the project's underlying business model.
Quick test: who pays the salaries of the core maintainers?
- Big tech with skin in the game (React → Meta, Angular → Google) — long horizon
- Profitable independent company (Vue → community + sponsors, Svelte → Vercel) — solid
- Single founder + Patreon — risky for production work
- Acquired and renamed — investigate carefully
Question 2 — Can someone else maintain it?
You're not building for yourself. You're building for the developer who will inherit this code in three years — and that developer will be cheaper to hire if the stack is mainstream.
A useful proxy: search for the technology on a major job board. If you see more than 200 active job listings for it in your country, you'll find people. Below 50, you'll struggle.
Our 2026 mainstream stack
For most of our SMB and mid-market clients, here's what we ship:
- Frontend: Next.js (React) or Astro for content-heavy sites
- Styling: Tailwind CSS — universal, easy to read three years later
- Backend: Node.js for full-stack, Python (FastAPI) for AI-heavy work
- Database: PostgreSQL — boring, battle-tested, will outlive us
- Hosting: Vercel, Cloudflare Pages, or AWS depending on scale
- Auth: Clerk or Auth.js — don't roll your own
Notice what's not on this list: anything launched in the last 12 months without a clear funding model.
Question 3 — Does it match the actual problem?
This is where most "best practices" articles fail. The right stack for a real-time multiplayer app is different from the right stack for a marketing site, even if both could technically run on either.
Three quick rules of thumb we use:
For static / content-heavy sites
Use a static site generator like Astro or Next.js in static export mode. Pages load in under a second, hosting costs almost nothing, and there's no server to break at 2 AM.
For SaaS / dashboards
Server-rendered React (Next.js App Router) plus PostgreSQL. Every senior developer in 2030 will still recognize this stack.
For e-commerce
Headless commerce (Shopify, BigCommerce) + a custom frontend, OR WooCommerce + WordPress if you need plugin flexibility and a smaller budget. Avoid building a custom commerce engine unless you have very specific needs.
What about the new shiny thing?
We're not anti-experimentation — we just keep it in the right place. New tools earn trial work on internal tools, prototypes, and side projects. They earn production deployment after we've watched them survive at least one major version bump and one founder transition.
"Boring technology is a feature, not a bug. The most expensive systems we're hired to fix are the ones built on something that was 'the future' three years ago."
Bottom line
Pick the stack your future maintainer will recognize. Pick the one with funded maintainers. Pick the one that solves your problem, not the one trending on Twitter.
If you're about to start a build and want a second opinion before locking in your stack, we offer a free 30-minute architecture review. No upsell — just an honest read from a team that's seen what happens five years later.
