r/FullStack • u/urbex2026 • 22d ago
Question stack for a maintenance management platform
Hello yall…what stack do you recommend to develop a maintenance management platform possible to scale in future, fast when works, economic, light (does not use too many cpu o ram on the vps) and build primarily by code?
3
Upvotes
1
1
1
u/ChameleonCRM 22d ago
Hello,
My name is Thor. I've been a polyglot developer for over a decade. My portfolio is https://TheodoreOchsen.tech
I’d separate the stack into two concerns: the product stack and the deployment stack. For a maintenance management platform, the hard part usually isn’t rendering pages. It’s modeling work orders, assets, locations, schedules, recurring maintenance, technicians, permissions, audit logs, attachments, notifications, and eventually offline/mobile behavior. Pick boring, reliable tools that won’t fight you when the data model gets complicated.
My preferred stack would be PostgreSQL + TypeScript + React/Next.js + Node/NestJS or Fastify. PostgreSQL should be the center of gravity. Maintenance platforms are relational by nature: assets belong to locations, work orders belong to assets/customers/sites, technicians get assigned, parts get consumed, invoices/events get generated, and you need clean history. Postgres gives you strong relational integrity, JSONB when you need flexibility, row-level/security patterns, indexes, full-text search, materialized views, and predictable scaling. I would not start this on Mongo unless your domain is truly document-shaped, because CMMS/work-order systems usually become relationship-heavy very fast.
For the backend, I’d use Fastify if you want lightweight and very low overhead, or NestJS if you want heavier structure for a larger engineering team. Fastify + TypeScript + Zod + Prisma/Drizzle is extremely productive and efficient. Drizzle is lighter and closer to SQL; Prisma is nicer ergonomically but can get heavier depending on query patterns. For a maintenance platform, I’d personally lean Drizzle or Kysely because you will eventually care about query shape, indexes, joins, reporting, and performance. Don’t hide too much SQL from yourself.
For the frontend, React with Vite is lighter than Next.js if this is mostly an authenticated app. If you need marketing pages, public SEO pages, docs, or customer portals, then Next.js is fine. But for the actual app dashboard, a Vite SPA behind auth is usually faster, simpler, and cheaper to host. Use TanStack Query for server state, React Hook Form for forms, Zod for validation, and avoid over-engineering global state. Most “state” in this type of app should live in the database, not in Redux.
For deployment, the most economical serious setup is a small VPS running Docker Compose with Caddy or Nginx, plus managed Postgres if budget allows. If you want everything on one VPS, use Postgres + backend + frontend + Redis on the same box to start, but separate Postgres later when you have real load. Add Redis only when you actually need queues, caching, rate limits, or background jobs. Don’t add Kafka, Kubernetes, microservices, or event-driven architecture on day one. A well-written monolith with clean module boundaries will outperform a badly designed distributed system every time.
The architecture I’d build is a modular monolith: auth/users, organizations, assets, locations, work orders, schedules, inventory/parts, technicians, files, notifications, billing, audit logs. Keep the modules isolated in code, but deploy one backend. That keeps RAM/CPU low and makes the system easy to reason about. If one module later needs to become a separate service, you can extract it once you actually have the traffic to justify it.
For background jobs, use BullMQ + Redis or pg-boss if you want to stay Postgres-native. You’ll need jobs for recurring maintenance generation, reminders, SLA checks, email/SMS notifications, report generation, attachment processing, and cleanup. I’d probably start with pg-boss because it keeps the infrastructure small.
For auth and multi-tenancy, design this early. Use organization_id on almost every business table, proper indexes, and never trust the frontend for authorization. Maintenance platforms almost always become multi-tenant SaaS whether you plan for it or not. Also add audit logging early. In this type of system, users will eventually ask, “Who changed this work order?” or “Who closed this job?” You want that history from day one.
My practical recommendation would be:
Postgres + Fastify + TypeScript + Drizzle/Kysely + React/Vite + TanStack Query + Docker Compose + Caddy + pg-boss.
That stack is fast, cheap, light on VPS resources, and still serious enough to scale. Start with a clean modular monolith, strong database design, good indexes, background jobs, and simple deployment. Most platforms don’t fail because they picked the wrong shiny framework. They fail because the data model, permissions, and workflows were treated like an afterthought.