CAPS
Capstone project management for a university — milestone tracking, faculty/student RBAC, and a single review surface that replaced three other tools.
Context
Capstone reviews at LDRP were running across Google Drive, email threads, and the occasional WhatsApp scramble. Faculty wanted milestone visibility; students wanted to know when they were blocked; the program coordinator wanted a single dashboard. Nobody had it.
CAPS was the answer — an internal tool, but built like a product. Hundred-plus users from day one.
Approach
I owned the backend architecture: Postgres + Prisma with carefully normalized schemas for projects, milestones, tasks, submissions, and reviews. Foreign keys for everything that had a relationship; no enums faked as strings; soft-delete only where it actually mattered.
RESTful APIs sat on top — predictable verbs, predictable shapes — with JWT auth and role-based middleware (faculty, student, coordinator) gating every route.
The frontend
Built in React with Tailwind. The hero move was collapsing submission and reviewinto one screen — students upload right where faculty leave comments, and the diff between drafts is visible without leaving the row. The "submit vs review" mental switch is what kills most of these tools, so we removed it.
Outcome
Four cohorts of capstone projects have run through it. The program coordinator hasn’t opened the old spreadsheet in a semester. The faculty side is what surprised me — they ended up using it for office hours scheduling too, which we never designed for.
What I would change
The notification system was an afterthought, and it shows. If I rebuilt it I’d start there — a proper event bus with topic-based subscriptions, not a row in the database that the frontend polls. Also: more keyboard shortcuts for faculty, who are the power users.