NestJS
We build NestJS backends where the structure is the point: modules, dependency injection and clear boundaries that keep a codebase legible as the team around it grows.
| In production | Since 2019 |
|---|---|
| Projects | 3 |
| Evidence | Scaled to ~50 people |
- Module and boundary design
- GraphQL and REST APIs
- Queue and worker processes
- Real-time gateways over Socket.IO
- Microservice decomposition, when it is warranted
- Test setup that a team will actually keep
The team is going to grow
Convention is worth more than cleverness once more than three people touch the code. Nest's structure is the cheapest way to get it.
Long-lived business logic
Products expected to run for years benefit from explicit modules and injectable services far more than from the fastest possible framework.
Real-time alongside HTTP
Gateways sit next to controllers in the same application, which keeps chat, presence and notifications from becoming a separate system.
You need testable seams
Dependency injection makes the awkward parts, payment providers and third-party APIs, straightforward to stand in for.
A small service or an MVP
The structure is overhead when there is not much to structure. For a week-long build we reach for Hono on the edge instead.
Edge-first products
Nest expects a long-running Node process. If the product should run at the edge, that is a different architecture, not a config change.
A team that will not maintain the conventions
Nest is only worth it if the boundaries are respected. Half-followed, it is just more files.
Where it has been proven
The live-streaming platform ran on NestJS with GraphQL, Postgres, Redis and RabbitMQ, across ECS microservices in the US and Asia, with Socket.IO and a Redis adapter behind real-time chat and HLS adaptive video. It was written from the first commit and carried through six years of growth, from three engineers to a company of around fifty, and through an acquisition.
That is the real test of this framework choice. The question is never whether it works at the start; it is whether the twelfth engineer's change costs about what the third engineer's did. Modules and injection are what kept that true.
Nightpixel used it for the platform behind a game catalogue, a token wallet and server-to-server integration with third-party game servers. Sakurai uses it for an agent platform exposing internal services as MCP tools.
What we bring to it
Mostly judgement about boundaries. Nest makes it easy to create modules, which makes it easy to create too many, and a codebase split along the wrong seams is worse than one that was never split. We size the decomposition to the team you actually have.
Not the default answer
For most new work we start on the edge with Hono, and only reach for Nest when the shape of the problem calls for it: a long-lived backend, a growing team, real-time alongside HTTP, or logic complex enough that structure earns its cost.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.