Back to Publications
nextjs
architecture
startups

Why I Chose Next.js for Everything

June 10, 2024·2 min read

When you're a solo founder building multiple products simultaneously, stack consistency isn't a nice-to-have — it's a survival strategy.

The case for a single stack

Every product I'm building — Reasy, CaseTime, ArtCollection — runs on the same core: Next.js, TypeScript, Tailwind CSS, PostgreSQL, and Vercel. Here's why.

Context-switching is expensive

Jumping between a Rails backend, a React frontend, and a React Native mobile app means constantly reloading mental models. With Next.js and a shared component library, I stay in one paradigm.

Shared infrastructure

I built ShipKit — a SaaS boilerplate with auth, billing, teams, and email — that I use as the foundation for every new product. A bug fix in ShipKit improves every product simultaneously.

Deployment simplicity

Vercel makes deployment trivial. Push to main, preview deploys on PRs, automatic rollbacks. When you're one person, eliminating operational overhead is critical.

The tradeoffs

No stack is perfect. Here's what I give up:

  • Performance ceiling — for compute-heavy workloads, Go or Rust would be better
  • Mobile — Next.js doesn't solve mobile. I use React Native separately
  • Vendor coupling — I'm optimized for Vercel, though the apps are portable

The pragmatic approach

As an engineer, I'm drawn to exploring new technologies. As a founder, I've learned that boring technology is a feature. The best stack is the one you know deeply and can ship with quickly.

Next.js isn't always the right answer. But for SaaS products with web-first distribution, it's the best answer I've found.