Why We Chose NestJS + Next.js as Our Default Stack

Every development team eventually needs to pick a default stack — a set of technologies they know deeply, can move fast with, and trust in production. Ours is Next.js on the frontend and NestJS on the backend.

Here's why.

The Problem with Stack Fragmentation

Early on, we were picking different technologies for every project. Express for one backend, Fastify for another. Create React App, then Vite, then Next.js. Each project was a fresh evaluation.

The result: slower ramp-up, inconsistent patterns, and a team that was perpetually re-learning rather than deepening expertise. Stack fragmentation is a hidden tax on velocity.

Why Next.js

Next.js has become the obvious choice for React-based web applications. But the reason isn't the marketing — it's the specific features that matter for production apps:

App Router and RSC. Server Components changed how we think about data fetching. Colocating data access with the components that need it means less boilerplate and better performance by default. We were early adopters of the App Router and it's paid off.

API routes. For smaller projects, Next.js API routes let us ship without a separate backend. For larger projects, we still use NestJS — but Next.js handles lightweight endpoints, webhooks, and edge functions without overhead.

Deployment story. Vercel + Next.js is genuinely the best frontend deployment experience available. Zero-config, preview deployments, edge functions, and a CDN that just works.

TypeScript-first. The Next.js team treats TypeScript as a first-class citizen. This matters when your entire team uses TypeScript end-to-end.

Why NestJS

NestJS is controversial in some circles. The Angular-inspired decorator pattern isn't for everyone. But for teams building serious backends, the tradeoffs are worth it.

Structure at scale. Express is great until you have 50 endpoints and no consistent organization. NestJS forces a structure — modules, controllers, services, providers — that makes large codebases navigable. When a new engineer joins, they know exactly where to look.

TypeScript-native. Not an afterthought. NestJS was built for TypeScript from day one. Combined with class-validator and class-transformer, you get runtime validation that matches your TypeScript types.

Dependency injection. Mocking services in tests becomes trivial. Complex dependency graphs become manageable. It's the difference between code that's technically testable and code you'll actually write tests for.

The ecosystem. NestJS has first-class integrations for everything we use: TypeORM and Prisma for databases, Bull for job queues, Passport for auth, Swagger for API docs. The integrations are maintained and opinionated, which means less glue code.

The Integration

The NestJS + Next.js combination works because they share a language (TypeScript) and can share types. We typically structure projects like this:

/apps
  /web    — Next.js frontend
  /api    — NestJS backend
/packages
  /types  — Shared TypeScript interfaces
  /utils  — Shared utilities

Using a monorepo (we prefer pnpm workspaces or Turborepo) means the frontend team can import types directly from the backend. When the API changes, TypeScript catches mismatches at compile time — not at runtime in production.

What We Use Alongside

The full stack we deploy on:

| Layer | Technology | |-------|-----------| | Frontend | Next.js 14 (App Router) | | Backend | NestJS | | Database | PostgreSQL via Prisma | | Caching | Redis | | Auth | NextAuth / Supabase Auth | | Storage | S3 / Cloudflare R2 | | Deployment | Vercel (frontend) + Railway or AWS (backend) | | CI/CD | GitHub Actions |

When We Deviate

This stack isn't universal. We deviate when:

• The project is small enough that Next.js API routes handle everything — no need for a separate NestJS service.
• The project is mobile-first — then it's React Native + NestJS, with Next.js only for the admin dashboard.
• Web3 is the primary layer — we adjust based on the chain requirements.

The default is a starting point, not a constraint. But having a default means we spend our energy on product problems, not infrastructure decisions.

---

Have a project in mind? Book a call and let's talk through the right stack for your use case.