We rebuilt a business-critical 15-yr-old app in two weeks

A 15-year-old in-house app ran our entire operation - and it couldn't be backed up fast, connected to anything, or changed without paying its original developer. We rebuilt it from scratch in two weeks, then cut over with zero training. Nobody had to stop working for the switch.

The problem: A 15-year-old in-house app scheduled every sales and tech appointment and held 15 years of records and client notes - reception, reps, production, and every technician depended on it daily. Three fatal flaws: you couldn't back it up, connect it to anything, or change it without paying its original developer.
The old way: Live with the risk, pay $30-50k and wait 6-12 months for a rewrite, or move to per-seat SaaS and bend the business around its workflows. Meanwhile: handwritten carbon-copy service tickets, no texting, no digital payments - and days of waiting for a signed form to ride back to the office.
The AI way: I had the AI inventory every feature and generate 200-plus tests the rebuild had to pass. Then we rebuilt it to match the old app's exact workflows, moved 15 years of live data across, and staged the cutover so old links kept resolving. Adoption was overnight.
The impact: Two weeks to a running, cloud-hosted rebuild with all the data working. Zero training, zero change management - the team took to it instantly and only later found the new features.
What it unlocked: The rebuild opened doors the old silo made impossible: CRM and ERP links, live payment tracking, automatic confirmations, review requests, route optimization. The replacement was the start, not the finish.
The honest edge: "Two weeks" was the functional rebuild with the data live - not the whole project. Testing and staged rollout ran another five weeks, about seven weeks end to end. I'll always tell you which clock I'm counting.

In his words

If it ever went down for any long period of time, it would be a true catastrophe. We would be going back to paper and pen to run this business.

Derek, on the legacy scheduler

Built on:Next.js + PrismaPostgreSQLLegacy MySQL → Postgres migrationIdempotent upsert migrationAirtable ↔ Postgres SyncQueueStaged cutover + legacy URL redirects

Build your own

Everything below is how it was actually built - the real journey, the prompts, and a starter repo you can run.

Build journey & gotchas

The first move wasn't code: the AI inventoried every feature in the 15-year-old codebase and generated 200+ objective tests the rebuild had to pass before anyone trusted it.
A decoy backups folder held dumps frozen at Dec 2024 - a cutover run against the wrong file would have quietly migrated year-old data over everyone's live records.
The re-runnable migration had to refuse to overwrite two specific things on every pass, or a safe “catch-up” run would have clobbered them.
126 cross-streets were buried in the wrong address field, and legacy color values silently broke the new app's validation. The old data fought back.
The scary part after go-live wasn't bugs - it was the team quietly preferring the OLD layout in spots we'd “improved.”

The safe-retirement playbook

The ordered method any owner can follow to retire a business-critical system without downtime: replicate the exact workflows so there's nothing to re-learn, migrate live data with idempotent upserts, freeze the old system's writes, redirect old URLs, keep old links resolving on a buffer, and sync bi-directionally so nothing dead-ends.

Prompt pack

The prompts that turned a 15-year-old codebase into a feature inventory and a 200+ test suite - the exact starting move that made a business-critical rebuild trustworthy.

Runnable starter repo

A sanitized migration + staged-cutover scaffold you can point at your own legacy database and adapt.

The build breakdown is coming.

The real journey, the prompt pack, and a runnable starter repo behind this use case are being produced now. Join the early-access list and you'll be first in when it drops.

Join the early-access list See what membership will include →