Don't Rewrite. Evolve.

We hear the same story from mid-sized companies all the time: A neglected, revenue-generating application keeps the business running, but it’s been left alone for so long that everyone is terrified to touch it.

The interface looks like the year it was built. The code framework is several versions behind. Small changes take weeks because every change risks breaking something a customer depends on. Eventually someone proposes the nuclear option, a ground-up rewrite. Twelve to eighteen months, a parallel team, and a hard cutover.

Rewrites fail more often than they succeed. The old system keeps changing while the new one is being built. The new application painfully rediscovers every edge case the old code already handled. And during the big rewrite, the product your customers actually use gets zero investment.

We Built One of Those Apps

Essential CEU is a continuing-education platform for California care facilities. We built it eight years ago. It processes real subscriptions and purchase orders, and issues real compliance certificates every day. It is exactly the kind of app most agencies would tell you to rewrite.

This April, our team of two set out to prove the rewrite wrong. The plan had three rules:

1. Subtract before you add, so legacy weight comes out before new features go in.
2. Keep the app releasable every single week.
3. Let research, not nostalgia, decide what gets touched next.

The First Move Was Demolition

Years of accumulated dead weight came out first, including an entire unused billing system and a stack of outdated third-party add-ons. Subtraction is the unglamorous half of modernization. It is also what makes everything that follows faster and safer. In the age of AI, it's easy to overlook this step. LLMs make it so simple to build flashy new features on top of old application fault lines.

Then We Rebuilt What Customers See

With the ground cleared, we rebuilt the sign-in system on modern, supported foundations and added passwordless login. Customers now get in with a fingerprint or a face scan instead of a forgotten password.

We redesigned the homepage, simplified the navigation, rebuilt the marketing pages, added a new course player with audio transcripts, and cleaned up the post-course quiz and certification flow. Week by week, the public site and the logged-in app converged on one consistent look instead of two aging ones.

Then We Touched the Money

Every product has a system nobody wants to touch. Here it was pricing. Rebuilding how the product packages and sells its courses meant touching billing and real revenue, the kind of change businesses defer for years.

We did it in small, safe steps, each one verified before release. Rigid subscription tiers became flexible certification bundles customers can buy once, with free trials. The groundwork for per-seat pricing went in alongside. The whole thing shipped in weeks.

193 Commits Later

Between April and late July, 193 production commits landed on that 8-year-old codebase. There was no downtime, no feature freeze, and no cutover weekend.

A fresher interface is the visible payoff. The bigger one is optionality. When the business decided to test one-time certification bundles against subscriptions, the codebase could express that idea in days instead of quarters. When research showed the pricing page was silently killing conversions, the fix was a normal week of work.

That is the difference between a rewrite and an evolution. A rewrite bets everything on one future. Continuous modernization keeps the app ready for whichever future the data reveals.

Your app is not legacy. Your process is, and that is fixable. Reach out if you have a gnarly application that needs new life.