Our Work  /  Ops & back-office
Ops & back-office

We rebuilt the 15-year-old app our whole operation ran on, in two weeks

One in-house app scheduled every job and held 15 years of records, and it couldn't be backed up, connected to anything, or changed. We rebuilt it from scratch with AI in two weeks, spent five more testing and cutting over, and switched the whole team without downtime or a single training session.

Live in production

One old app ran everything, and nobody could safely touch it

For 15 years, one in-house app - built by a contracted developer for the previous owners - ran the entire home-services side of the business. Reception booked appointments in it, reps managed their schedules in it, production attached records to it, and every technician opened it to know where to go and what the job needed. It held a decade and a half of client notes and scanned carbon-copy tickets.

It had three fatal flaws. You couldn't really back it up. Our IT provider kept warning that a crash could take weeks to recover from, because the stack was so old. You couldn't connect it to anything. Every sale was typed by hand three times - into the CRM, the scheduler, and the ERP - and we had to email the developer just to get a customer list out. And you couldn't change it without paying the one developer who touched it every couple of years. Texting a customer or taking a card payment digitally wasn't even on the table.

The options were all bad: keep living with the risk, spend tens of thousands of dollars and wait six to twelve months for a traditional rewrite, or move to per-seat software and bend the business around someone else's workflows.

ReceptionSales repsProductionEvery technicianThe 15-year-old app15 years of records insideno backup you could trustCRM✕ERP✕Texting✕Payments✕one sale, typed by hand into three systems

The worst part of it was certainly the risk that it could break and not be recovered.

They laughed. Two weeks later they had a login.

In a regular meeting with our outsourced IT provider, with about five of their people in the room, they flagged the risk again and pushed us to commission a replacement. We said we'd rewrite the whole thing ourselves, with AI, in two weeks. They laughed - not because they thought it was impossible, but because they thought it was a joke.

Two weeks later, to the day, we emailed them a username and password for a cloud-hosted, completely rewritten version of the app, with all 15 years of data already in it and every legacy function recreated.

ABOUT SEVEN WEEKS, END TO END2 weeks: rebuild~5 weeks: testing and staged rolloutThe IT meeting"two weeks," we saidLogin emailedworking, in the cloud, all the dataFully livenobody stopped workingthe two weeks is the build, not the whole project

They all laughed at me. And they laughed at me not because they thought that it was impossible and I was being foolish. It was almost worse than that. They thought I was just making a joke.

We knew it was done because 215 tests said so

The first move wasn't writing code. We had the AI read every source file in the old app, inventory every feature, and write a list of 215-plus tests the replacement had to pass, each one traced back to the legacy file it came from. That list became the definition of done.

The "with AI" part, concretely: one person and an AI coding agent. We described each screen and workflow of the old app in plain language, the agent wrote the code, and we ran the result against that test list until it passed.

Then we rebuilt to match the old app's exact screens and workflows, moved the live data across with a migration we could rehearse and re-run safely, and staged the cutover so old bookmarked links kept resolving. Nobody had to stop working for the switch.

Test inventory: what the rebuild must dosample rowsAREA OF THE OLD APPTESTSSchedulingappointments, overlaps, day view, print38Clientssearch, phones, emails, addresses41Notes and recordsjob notes, scanned tickets, history29Users and roleslogins, permissions, who sees what22Technician viewtoday's stops, job details26Lookups and reportspick-lists, reports, exports59Derived by reading every source file of the old app215+

Zero training, and the new features found their own way in

Because the screens and workflows matched what the team already knew, we didn't run a single training session or do any change management. Technicians and office staff took to it overnight, and only later started noticing the new things: the features they'd wanted for years that the old silo made impossible.

Today the scheduler links to the CRM and the ERP, tracks payments live, sends automatic confirmations, requests reviews from happy customers, and suggests appointment times that fit the crew's existing routes. The replacement wasn't the finish line. It was the door.

CRMcontacts sync both waysERPorders and productionPaymentstracked liveConfirmationssent automaticallyReview requeststo happy customersRoutingdrive-time optimizedThe rebuilt schedulercloud-hosted, backed up,and ours to change

Our technicians and our employees just took to it like a fish to water. They started to realize that there were new features that were really helpful.

The honest part - the old data fought back, and so did habits

Two weeks got us a working app. It took about five more weeks of testing and staged rollout to be fully live, so call it seven weeks end to end, and the settling period had real bumps.

The migration "worked," and then 15 years of messy records hit the new app's stricter rules: 126 cross-streets were buried in the wrong address field, old records carried color codes in a format the new app rejected, so an entire edit form refused to save, and free-text phone fields ("call this number or that one, extension whatever") overflowed a column and crashed the sync. After go-live, someone typed 12:00 AM instead of PM and the appointment simply vanished from the calendar - the record existed, the calendar just refused to draw it. The first double-booking check cried wolf on every back-to-back appointment.

And the most humbling one: in a few spots where we had "improved" a layout, the team quietly preferred the old way, and we changed it back.

A lot of it was just slight user experience or user interface edits where I was trying to improve the user interface for the legacy solution. But our team actually liked it the old way.

Build software onto the business you have

Here's what we'd tell any owner stuck on aging software: with off-the-shelf SaaS, you bend the business to fit the product - new workflows, training, and a migration you don't control. Rebuilding your own means you're not forcing a square peg into a round hole. The software fits the business you already run.

And the move anyone can copy on day one costs nothing: before you build, have the AI list every feature of the old system and write the tests the new one has to pass. Then you know it's done because a document says so, not because it feels done.

You are not trying to fit a square peg into a round hole. And that's a radical improvement.

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

This is the app our whole operation runs on

This is a real business-critical system, rebuilt and running in a real small business. If you're stuck on aging software you can't change and can't safely replace, tell us about your setup. We'll tell you honestly whether a rebuild makes sense, and with Managed Intelligence we build it, then maintain and monitor it for you.

Talk through the fit →