NestJS isn't the flashiest backend framework available, and that's part of why it's behind almost every service we run. Boring, in this context, is a compliment.
What we needed across six products was structure that survives more than one engineer touching the code — modules, dependency injection and clear conventions that make a service written a year ago still legible today, rather than a framework so flexible that every developer builds it differently.
That legibility problem is easy to underestimate until you've lived without it. A lightweight, unopinionated framework lets a fast-moving engineer ship something quickly, but two engineers given the same loose framework will often structure a service in genuinely incompatible ways — different folder conventions, different patterns for handling errors, different assumptions about where validation happens. Six months later, maintaining both services means holding two different mental models in your head simultaneously. NestJS's opinions remove that variance almost entirely: a service for TheRehoboth's giving API and a service for Koinonia's message library look recognisably similar in structure, even though they do completely different things.
NestJS's opinionated structure means a new backend service starts from a shared shape instead of a blank slate, and it plays well with the rest of our stack — PostgreSQL, Redis, WebSockets for anything realtime — without fighting the framework to get there.
We also lean on it heavily for the less glamorous requirements that show up across every product regardless of what the product actually does: request validation, consistent error responses, authentication guards, rate limiting. Building those from scratch per service would mean either duplicating a lot of boilerplate or, worse, doing it slightly differently each time and creating exactly the inconsistency we're trying to avoid. NestJS's module system lets us build that shared plumbing once and drop it into every new service, so a new backend for a future product starts with security and reliability basics already in place rather than as an afterthought.
For a studio our size, the biggest backend risk isn't picking the "best" framework in the abstract — it's picking one inconsistently and ending up with six services that don't resemble each other. NestJS is how we avoid that, and the payoff is mostly invisible: it shows up as the absence of a certain category of bug and confusion, not as a feature anyone would ever put in a screenshot.