SIT Manager is a full institute management system we shipped for Suvaidya Institute. The previous two agencies had quietly stalled for nine and six months respectively. We shipped the first working version in fourteen days, and the full system replacing eight years of fragile legacy PHP in under eight weeks.
This is what that actually looked like.
The starting position
A PHP monolith, built in 2017, extended by four different developers over six years. No tests. No type system. Admin flows that only the founder's cousin knew how to run. Every feature request had become a production incident waiting to happen.
The founder did not want a rebuild. He wanted an exit. Every month the old system ran was a month of risk he couldn't quantify.
The stack we chose, and why
Next.js 15 with App Router, Postgres on Supabase, Drizzle for the ORM, TanStack Query for client state, Tailwind and shadcn/ui for the surface. This is our default stack for institute-class CRUD systems, and deviating from it would have been malpractice given the timeline.
The rule: pick your default stack for the shape of problem, and deviate only when the project has a reason. SIT Manager had no reason to deviate.
The migration, before and after
Before: two agencies, fifteen months, nothing shippable, data stuck in a schema nobody dared touch.
After: eight weeks end-to-end. The migration was the work. We built an extraction pipeline that pulled the old database into a shadow Postgres instance, normalised on the way in, and ran on a cron until the cutover. The cutover itself was thirty minutes of downtime on a Sunday night.
Every admin flow has a tested counterpart in the new system. The founder's cousin no longer has cursor control over prod.
What we'd do differently
Two things. First, we introduced real-time notifications in week six and should have waited until after cutover. It added scope during the most fragile part of the engagement.
Second, we under-invested in admin tooling. The legacy system's best feature was a terrible UI that, nevertheless, let the founder poke any record. We rebuilt the cleanliness first and the pokability second; a founder-class admin console should have shipped in week three.
Heuristics
- Migrations are the work. Treat them with the same rigour as features, not as a lift-and-shift afterthought.
- When a legacy system runs, the cutover day is the product. Rehearse it. Time it. Have a rollback.
- Founders who have been burned twice test for speed; founders who have been burned once test for attention. Know which one you're selling to.
The shape of SIT Manager is a template we've reused twice since, and will reuse again. The rule that made it ship on time is the one-page scope rule we use on every build.
Written 2024-12-11 by Naman Barkiya.