I bought a biz and now I want to rewrite the core software

1. The Situation

Mike bought a business that came with legacy software.
It had been around for 15 years, originally built on a general-purpose CMS (think WordPress, Joomla!, etc.), and over time had grown into a complex web of custom code.

A lot had been built in-house: analytics, customer support, ticketing, newsletter systems, you name it.
The sale included:

• The existing dev team

• Existing employees

• A large user base that knows the app inside out

• A few “whale” customers spending multiple six figures per year

Mike’s idea was simple: make some improvements, refresh the design, boost conversions and sales, and, after a couple of years, flip it for a $5-8M profit.

2. The numbers

• 💰 Revenue: $1.2M ARR / $100K MRR (most growth happened during COVID)
• 💸 Purchase price: $5.6M (mix of loan and equity)
• 📢 Ad spend: $30K/month on Meta
• 👥 Team + hosting + ops: ~$40K/month
• 📈 SDE around $30K — but with $20K in loan repayments, effectively $10K buffer
• ⚠️ Churn is rising; post-COVID slowdown likely

Given these facts, I was brought in to define a rewrite strategy.

3. The legacy problem

Legacy code has one BIG pro: It makes money.
And one big con: Changes can be expensive. 

This application was quite outdated.
But no critical vulnerabilities existed. It just took a while to add features or make changes.

So, Mike starts wondering.

Do I keep patching this thing, or do I rewrite it from scratch?

4. The options

Option 1: Keep improving old app

Facts:

• It works. It makes money.
• Users are used to it. Some have been around since the start.
• There’s heavy ad spend bringing in traffic.
• The UI looks dated, new user retention is blamed on this
• Mike suspects that $30K/month on ads is poorly spent when visitors land on something that looks 15 years old.

Pros:

• No drastic changes that alienate loyal users
• Keeps cash flowing
• Lower short-term risk

Cons:

• Increasingly difficult to add new features
• Risk of security and performance decay
• Falling behind modern competitors
• Higher maintenance cost over time

Option 2: Rewrite the Whole Thing

⚠️ Big Warning: I have NEVER seen a full one-go rewrite done right (on time or on budget). It’s very hard to do it right. It has to be treated like an entirely new application. Not a “Version 2”.

Pros:

• Modern tech stack, faster and more secure
• Opportunity to completely redesign the UX/UI
• Easier to scale and extend in the long term
• Might attract new customers and retain existing ones better

Cons:

• Very time-consuming and expensive
• You’re effectively running two products (the old one still needs maintenance)
• Months of dev before a single user sees anything
• Risk of alienating existing users
• Potential SEO and brand disruption

You’re betting big money that a brand-new system will work better than the one already paying your bills. And the thing is, the rewrite will longer than planned, and when the new app hits users, I guarantee a huge amount of bug fixing and usability tweaks that will add a few more months.

Option 3: The Step-by-Step Rewrite

This is the middle path — and often the smartest one.

Pros:

• Incremental improvements without shocking users
• Less risk, since you can test and adjust along the way
• Easier on cash flow
• Always have a usable product (you can pause at any time)
• Faster feedback cycles — users see value sooner

Cons:

• Takes longer overall
• Technical challenges in making old and new parts work together

Think of it like renovating one room at a time instead of tearing down the whole house. If for some reason construction has to stop, you have a usable house for the whole time. (remember churn is increasing, cashflow situation may change, prepare for that!)

5. How to decide

Rewriting is a technical choice, but most of all is a capital allocation decision.
Ask yourself:

1. Can you afford to fund two parallel teams for 12-18 months? (one to run the existing app, and one to build the new one)
2. Can your business survive if the rewrite fails or overruns?
3. Is your biggest problem really the codebase, or is it churn, marketing, or positioning?

If you can afford to keep the current team running the existing app while a new team builds a replacement, fine, go for it.
But most small and mid-sized companies can’t.
That’s where a gradual rewrite shines.

⚠️Big warning: I have NEVER seen a full one-go rewrite done right (on time or on budget) in an SMB. It’s very hard to do it right. It has to be treated like an entirely new application. Research must be done to dig into every little bit of functionality that has been made over potentially decades of development. User interviews have to be conducted to ensure the UI works for your current users, if the original team is no longer with you, there may be secret gotchas that you don’t know about.

I’ve heard “Oh but we assumed […] many times”. Sometimes things are built a certain way due to hidden constraints that are only obvious when you attempt to rebuild again.

There was a hypothesis that paid traffic landing on a old-looking page was hurting conversions. This can be tested by working only on the user onboarding part of the app. Doing it all from scratch for 18 months to test all your assumptions in one go is way to risky. Test them one-by-one.

6. Focus on Core vs Commodity

Not everything in your old app needs to be rebuilt.
Outsource or integrate where it makes sense. In this case, we can get rid of the:

• Newsletter system
• Customer support
• Analytics
• Ticketing system
• Other non-core functionality

By removing this from the core app we potentially reduce its complexity and free up resources.

7. The bottom line

A full rewrite is a GIANT bet with mostly risk guaranteed.
A gradual rewrite is a series of small bets. If an individual one fails, you don’t miss much sleep over it.

A gradual rewrite gives you the best of both worlds, progress without gambling everything.

You only get good at this after losing $1M+ doing it wrong.
(Ask me how I know.)

8. Need help making this call?

If you’re facing this kind of decision: legacy code, big rewrite, uncertain roadmap.

I help businesses like yours as a fractional CTO.

You’ll get someone who asks the hard questions and keeps you from making million-dollar mistakes.

I’m not gonna bury myself in code. With me you get an executive brain that happens to understand engineering intimately. If that sounds useful, get in touch!