Project Management System
Project Management System
A comprehensive enterprise platform built for a precision engineering company — centralizing project tracking, employee management, customer CRM, billing, and granular access control into one cohesive system.
Client
PMS
Role
Full-Stack Developer
Timeline
2024 – 2025
Completion
99%
By the numbers
2,392+
Projects tracked
298+
Customer records
38/38
Tests passing
99%
Overall completion
The Problem
An engineering firm running on spreadsheets and chaos
A precision manufacturing and tooling company in New Delhi had grown rapidly but their internal operations hadn't kept up. Project data lived in Excel files. Employee records were scattered. Billing was manual and error-prone. There was no unified way to know what was happening across the business.
No centralized project tracking
Projects were tracked in disconnected Excel files. Status updates happened over WhatsApp, making oversight nearly impossible at scale.
Employee management was fragmented
No single source of truth for designations, assigned projects, or employee records. HR data was spread across multiple files with no version control.
Billing was slow and error-prone
Creating invoices meant manually copying data between tools. Payment tracking was difficult, causing delayed follow-ups with customers.
Zero access control
Everyone had access to everything — or nothing. There was no way to give an Application Engineer project visibility without also exposing billing data.
The Solution
One platform to run the entire operation
A full-stack system that brings every department under one roof — built around the idea that different roles need different views. A technical head shouldn't wade through billing data. A billing manager shouldn't need to navigate employee salary records.
Live Dashboard
Real-time overview of all projects by status — Unassigned, Assigned, In-Progress, Review, Delivered — with financial summaries: billed, payment received, dues, and pipeline value.
Project Management
Full project lifecycle with status workflows, tab-based filtering, team assignment, sortable tables, and data export. Currently tracking 2,392+ projects across multiple clients.
Employee Management
Complete employee profiles with designations, addresses, education, CTC, and joining dates. Card-based visual directory alongside a structured table view. Full CRUD with nested relation handling.
Customer CRM
Centralized customer database with 298+ company records. Owner details, state, active status, and project associations. Instant search and filter across all records.
Billing & Invoicing
Professional invoice creation linked to projects and customers, with auto-generated sequential numbers by company series. Billing history with search, pagination, and PDF download.
Granular Access Control
Per-designation permission toggles for READ, CREATE, EDIT on each entity, plus workflow permissions: Can Assign, Can Mark In-Progress, Can Review, Can Deliver, Can Bill, Can Hold, Can Cancel.
Technology Stack
Built with the right tools
TypeScriptLanguage
ReactFrontend
Node.jsBackend
Express.jsBackend
PostgreSQLDatabase
PrismaORM
Redux ToolkitState
ZodValidation
VitestTesting
Tailwind CSSStyling
TurborepoMonorepoArchitecture
Monorepo (Turborepo)
PMS/
├── apps/
│ ├── frontend/ # React application
│ └── http/ # Express API
└── packages/
├── db/ # Prisma schema & migrations
├── common/ # Shared Zod types
└── tests/ # Test suitesDevelopment Journey
How it was built
Phase 01
Understanding the real workflows
Before writing a single line of code, I spent time understanding how the team actually worked. What I found was more complexity than expected — different engineers had distinct responsibilities, projects moved through multiple status stages, and billing required linking specific customer-project-payment relationships.
Phase 02
Designing the database and monorepo
I chose a monorepo structure with Turborepo to keep the frontend, backend, database schema, and shared validation types in sync. Zod schemas in the shared common package meant both the API and React frontend validated data against identical rules. The Prisma schema was designed to be normalized — Employee to Designation relationships, Project to Customer associations, and a Permissions model flexible enough to evolve with new roles.
Phase 03
API with tests from day one
I followed a test-driven approach for core modules. Every endpoint had test cases written before or alongside implementation. By the time the frontend was being built, the API had 38/38 tests passing with 100% coverage on authentication and employee management. Swagger UI was integrated for interactive API documentation.
Phase 04
React + Redux connected to real data
The frontend was built with React 18 and Redux Toolkit. Axios interceptors handled JWT cookie-based auth transparently across all requests. The component library — tables, modals, forms, skeleton loaders, toast notifications — was built from scratch with Tailwind CSS to ensure complete design consistency across all 10+ pages.
Phase 05
Live with real data, real users
The system went live with actual company data — 2,392 projects, 298+ customers, 8 active team members using the platform daily. Real-world usage revealed edge cases and refinement priorities that documentation never would have surfaced, and now directly shapes the development roadmap.
Engineering Challenges
Hard problems, real solutions
Permissions that actually work in practice
Problem
Designing a permissions system flexible enough to support 'Can Review but not Deliver' or 'Can Read Customers but not Create them' required a schema that could grow without breaking existing roles.
Solution
Built a separate Permissions model linked to Designations, with boolean flags for each action per entity type — rendered as toggle switches in the UI for easy management.
Updating nested Prisma relations safely
Problem
Updating an Employee's designations or addresses (one-to-many relations) while maintaining data integrity required careful handling — a simple overwrite would drop relation metadata.
Solution
Used Prisma's nested upsert inside transactions, with custom diffing logic to detect which relations needed to be created, updated, or disconnected.
Dual company invoice series
Problem
The company operates under two legal entities with separate invoice sequences that must auto-increment correctly and never collide under concurrent requests.
Solution
Implemented series-specific counters with a database-level lock during invoice creation to guarantee sequential uniqueness even under concurrent load.
Quality & Testing
38 tests. 0 failures.
Testing wasn't an afterthought. Core API modules were built with 100% test coverage from the start — each endpoint covers the happy path, validation errors, auth failures, duplicate records, and edge cases.
| Method | Endpoint | Tests | Passing |
|---|---|---|---|
| POST | /admin/signup | 6 | 6 |
| POST | /admin/signin | 5 | 5 |
| POST | /admin/signout | 1 | 1 |
| POST | /employee/create | 10 | 10 |
| GET | /employee/:id | 3 | 3 |
| PUT | /employee/:id | 13 | 13 |
Project Roadmap
What's done, what's next
Phase 1 · Completed
Phase 2 · Completed
Phase 3 · Future