NestJS or Next.js API routes: which backend for your startup?

Short answer

• Next.js route handlers: when the backend is mostly in service of the frontend — auth, form handling, CMS, marketing sites, thin CRUD.
• NestJS: when the backend has its own gravity — domain logic, queues, long-running jobs, multiple consumers, or a separate mobile app.

Signals that push us to NestJS

• More than ~15 distinct domain models
• Background workers (BullMQ), cron jobs, webhooks from many providers
• A mobile app or a partner integration also consumes the API
• You need strict DI, testable modules, and a clear layering discipline

Signals that keep us on Next.js

• One frontend, tight feature loops
• Edge-friendly reads, SSR/ISR-heavy
• Small team, speed of iteration matters more than architectural purity

The boring truth

You can always start with Next.js route handlers and extract a NestJS service later. The reverse — folding a NestJS backend back into a Next.js monolith — is rarer but also fine. Pick the simpler option that doesn't paint you into a corner.