NestJS gets a fair amount of criticism, most of it aimed at projects that treated it like a folder structure rather than an architecture. Used well, it's one of the fastest ways to ship an API-driven MVP that doesn't need to be thrown away when you raise.
The principle that keeps a NestJS codebase sane as it grows is strict module boundaries. A module owns its domain, its entities, and its public API — and other modules talk to it through a service interface, never by reaching into its repositories. The moment a feature module imports another module's repository, you've coupled two domains and made both harder to change.
We treat the database as an implementation detail of each domain. Entities live with the module that owns them; cross-domain reads go through a service method, not a join. This feels heavier on day one and pays for itself by month three, when adding a feature doesn't require untangling a dozen unexpected dependencies.
The rest is discipline: keep controllers thin, push logic into testable services, and don't let your DTOs leak into your responses. None of it is glamorous, but it's exactly what lets an MVP become a production system without a rewrite.
