NestJS in Production: What They Don't Tell You

Why NestJS

After years of Express spaghetti, NestJS felt like a breath of fresh air. Dependency injection, decorators, modules. Structure where there was chaos.

At Scalapay we migrated three microservices from Express to NestJS over six months. Here's what we learned.

The good

The module system is genuinely great. Each domain gets its own module with clear boundaries. Testing becomes easier because you can mock entire modules.

@Module({
  imports: [PaymentModule, NotificationModule],
  controllers: [CheckoutController],
  providers: [CheckoutService],
})
export class CheckoutModule {}

Pipes and guards saved us hundreds of lines of validation boilerplate. Instead of checking req.body.amount in every controller, we had a single @IsPositive() decorator.

The tricky parts

Circular dependencies. They will find you. Two modules that need each other will crash at startup with a cryptic error. The fix is forwardRef(), but the real fix is redesigning your module boundaries.

Memory usage. NestJS apps are heavier than plain Express. Our cold start went from 80ms to 250ms. For serverless, this matters.

Would I use it again?

Yes, for any backend service that will grow beyond a single file. The structure pays for itself within three months.