For complex management software I use Angular on the frontend, NestJS on the backend and TypeScript across the whole stack. Not because they are “the best” in absolute terms, but because they give a large, long-lived application a clear structure, typed contracts between its parts and a single language for the whole team. They also have limits, and for some projects I would choose something else: those are covered towards the end.
Choosing a framework is not about finding a universal winner
Management software is not a brochure website. It has dozens of screens, long forms with interdependent rules, roles and permissions, and above all a long life: it will be changed for years, often by people other than those who wrote it. So the right question is not “which framework is fastest or most fashionable” but “with which stack will this project stay understandable and changeable for whoever maintains it”.
Why Angular for management applications?
Angular is a complete, opinionated framework. For a large back-office application that is an advantage:
- Forms. Reactive forms handle long forms, fields that depend on each other, and synchronous and asynchronous validation well.
- Routing. Lazy-loaded sections and route guards to hide areas from users without the right permissions.
- Dependency injection. Injectable services that are easy to swap out in tests.
- Consistent structure. Two Angular projects look alike: anyone joining the codebase knows where to look.
- Ready-made components. Angular Material provides consistent tables, dialogs, date pickers and form fields, which helps when the interface is mostly data.
Why NestJS on the backend?
NestJS brings an organisation similar to Angular’s to the Node.js backend:
- Modules that separate domains (bookings, suppliers, payments) and declare what they expose.
- Dependency injection, which keeps services composable and testable.
- Guards for authentication and authorisation, applied declaratively on controllers.
- Validation pipes that check incoming data before it reaches business logic.
- Queues and background jobs, through the official integrations, when asynchronous processing is needed.
Anyone who knows Angular finds their way around a NestJS project quickly, and vice versa.
TypeScript across the stack
Using TypeScript on both frontend and backend means:
- shared types: the shape of a booking is defined once and used by both sides;
- safer refactoring: rename a field and the compiler flags every place to update, in the client and the server;
- one language for the team: less context switching, simpler code reviews, people who can work across the whole stack.
There is one important limit, though: TypeScript does not validate data at runtime. Types disappear after compilation, and an HTTP request can contain anything. Explicit validation and tests are still required.
DTOs and shared contracts
My approach is to keep the contract separate from validation. The type lives in a shared library:
// libs/shared/types/src/booking.ts
export interface CreateBooking {
customerId: string;
date: string; // ISO 8601
guests: number;
}The backend implements it with a DTO that adds the validation rules:
// apps/api/src/bookings/create-booking.dto.ts
import { IsISO8601, IsInt, IsUUID, Min } from 'class-validator';
import type { CreateBooking } from '@app/shared/types';
export class CreateBookingDto implements CreateBooking {
@IsUUID() customerId!: string;
@IsISO8601() date!: string;
@IsInt() @Min(1) guests!: number;
}With NestJS’s ValidationPipe enabled, a request that breaks these rules is rejected before it reaches the logic. The frontend uses the same interface to type its calls: if the contract changes, compilation flags the problem on both sides.
Nx and monorepos
Frontend, backend and shared libraries sit in the same Nx monorepo, with rules that prevent the wrong dependencies between parts. I have described the structure I use in a dedicated article: how I organise management software in an Nx monorepo.
An illustrative architecture
An illustrative outline, to be adapted to each project:
Angular (back office)
↓ HTTP/JSON, shared types
NestJS API: guards, validation, controllers
↓
Domain services: bookings, suppliers, documents
↓
PostgreSQL or MySQL
↔ Redis and queues, only when background jobs are needed
↔ external providers: payments, email, other softwareThe travel agency management system I built uses exactly this stack: Nx, Angular, NestJS and MySQL. It is worth isolating each integration with external software in its own module, so that changing provider does not ripple through the rest of the code; I cover this in the article on APIs and business software integration.
When I would choose a different stack
- Content sites and landing pages. For a site like this one I use Astro: Angular would be overkill.
- CMS-driven sites, where the people writing content need an editor rather than an application.
- Very simple MVPs that need validating quickly, where Angular’s structure costs more than it returns.
- Teams with different skills. If the people maintaining the software work in PHP or another stack, staying there is often the better choice; I use PHP myself when the context calls for it.
- Existing software that works. Rewriting just to change framework rarely makes sense; I discuss this in the article on whether to modernise or rewrite legacy software.
It is also fair to say that Angular has a steeper learning curve than lighter libraries: a cost that pays off on large applications, not on small ones.
Long-term maintainability
No stack guarantees that software stays easy to maintain. What helps is the combination of a predictable structure, shared types, explicit validation, tests and clear boundaries between modules. Keeping dependencies updated regularly, rather than letting versions fall behind, matters too. In my projects the source code and documentation are handed over to the client, so whoever comes next can start from a readable codebase.
If you are building or evolving a complex management application, we can discuss its architecture. You can read how I work on custom management software, or get in touch.
Frequently asked questions
Does TypeScript replace data validation?
No. TypeScript checks your code at compile time, but data arriving in an HTTP request has to be validated at runtime, for example with DTOs and validation pipes.
When is an Nx monorepo worth it?
When frontend and backend share types and logic and are developed together. For a single small project it can be more structure than you need.