ERP Software
A 45-module freight and rail ERP, built by a four-person team.
- ERP
- Full Stack
- Real-Time
- TypeScript
- Duration
- 3.5 mo
- Team size
- 4
- Modules
- 45+
- Stack
- Next.js
Overview
This ERP is the main operational system used by a multi-branch freight and rail logistics company. Dispatchers, branch managers, operations staff, and finance teams use it daily to manage goods from the initial customer booking through to final, GST-compliant delivery — including Lorry Receipts, Vehicle Placement scheduling, Goods Received Notes, delivery challans, trip documents, and e-way bills, alongside rail rake bookings and live GPS wagon tracking.
I worked as Lead Full-Stack Developer on a four-person team, contributing across database design, backend APIs, frontend development, architecture, performance, security, and integrations. I took full ownership of rail operations, live GPS wagon tracking, delivery challans, Goods Received Notes, e-way bill generation, and performance work on the Vehicle Placement workflows. The team shipped the production-ready ERP in roughly three and a half months — more than 45 business modules, 25+ master-data modules, 185 permissions, and two real-time systems for GPS tracking and notifications.
The Challenge
The hard part was never a single feature — it was designing an ERP that could hold customer and vehicle management, branch operations, freight documents, rail operations, GPS integrations, GST compliance, and reporting without becoming impossible to reason about.
- New modules had to slot in without touching unrelated parts of the app, while still sharing consistent validation, permissions, search, pagination, and exports.
- Employees from multiple branches needed access strictly scoped to their branch, enforced on the backend, not just hidden in the UI.
- Dispatchers and branch staff use the system to make real-time operational calls, so high-traffic pages needed to stay fast even under heavy data volumes.
Architecture
The project is a Turborepo monorepo managed with pnpm, containing a Node.js / Express 5 / TypeScript / Prisma / PostgreSQL backend and a Next.js 16 / React / TypeScript frontend, plus shared internal packages for UI components, validation, and types.
Both apps follow a modular-monolith, vertical-slice structure — each business area keeps its database logic, API routes, validation, and UI together, so modules stay independent and changes in one area rarely ripple into another. Prisma defines the schema and migrations; Zod schemas are shared between backend and frontend so a request the API accepts is always a request the form could have sent, and TypeScript types are derived from the same schemas end to end.
Authentication uses JWTs in secure HTTP-only cookies, with an Axios interceptor that silently refreshes an expired session and retries the original request. The RBAC system checks both permissions and branch access server-side across 185 individual permissions, with the user's permission and branch data cached in memory for five minutes to avoid a database round-trip on every check. Redis and BullMQ handle background work — notifications and queued jobs — off the request path, and Socket.IO pushes live GPS positions and notification updates to the frontend. Multi-step operations (reserving Lorry Receipt number blocks, completing a trip) run in short Prisma transactions, with permission checks and data prep done before the transaction opens to avoid lock contention and timeouts.
I owned rail freight operations end to end — Prisma models and migrations for rail rake management, railway branch Goods Received Notes, wagon assignments, and dispatch/unloading tracking, plus the Express APIs and React interfaces that let branch employees run a rail shipment from booking through goods receipt, unloading, and completion.
On top of that I built the live GPS wagon tracking integration against a Traccar-based GPS provider, with an assignment system linking devices to wagons (a database constraint guarantees at most one active assignment per wagon) and a Socket.IO feed pushing new positions to the map in near real time.
Performance & Documents
Vehicle Placement Loading and Scheduling were the two most-used, slowest screens in the app. Profiling turned up repeated API calls for the same data, expensive queries, missing indexes, search-on-every-keystroke, and read-heavy lookups fetched over and over. I added Redis caching for that lookup data, wrote targeted Prisma migrations with composite indexes for the common query patterns, and debounced search input — noticeably faster pages with no change to the existing workflow. The same caching and indexing approach was later reused elsewhere in the app.
I also built the Delivery Challan module and Goods Received Note forms across the full stack, and implemented GST e-way bill generation straight from Lorry Receipt data so employees never re-enter shipment details. Puppeteer generates print-ready PDFs — consignment notes, trip sheets, and other transport documents — on the server. Separately, I tracked down and fixed a BigInt-to-JSON serialization bug that was corrupting large numeric values as they moved from PostgreSQL through Prisma and the API to the frontend.
Outcome
In about three and a half months, the four-person team delivered a production ERP spanning 45+ business modules, 25+ master-data entities, 185 permissions, branch-level data access, GST document generation, live GPS tracking, automated PDF generation, Redis caching, and background job processing. The rail operations and GPS tracking areas I led went from an empty schema to a complete production feature in a few weeks, and the performance approach I introduced for Vehicle Placement became the template the team reused for other high-traffic modules.
