"Should we fix the backend MVP, or start over?"
That's how HeyPractice opened the conversation with us. A working product, real users, and a backend with all the logic sitting in the controllers and no test coverage anywhere. A roadmap and a hiring plan were both riding on the answer.
Most sources answer that question with "it depends." We think it depends on 4 things, and you can check all 4 without an engineer in the room.
The question behind "refactor vs rewrite" The honest answer: neither, until you've answered 4 questions What AI actually changed, and what it left alone The nuance vendors skip: incremental is also the longer invoice What gets kept when you rebuild How to tell whether a vendor's answer is honest FAQTL;DR: AI made writing software dramatically cheaper. Understanding software still costs what it always did. So the refactor vs rewrite decision now turns on how recoverable your system's specification is, not on how ugly the code looks. Run the 4 signals below, module by module, and the answer usually comes back partial.
The question behind "refactor vs rewrite"
Ask 10 engineers what these words mean and you'll get 4 definitions. The highest-ranking page on this query is a Reddit thread arguing about the terms. So, plainly. Refactoring changes the internal structure of code while the behaviour it produces stays the same. Rewriting replaces the implementation and re-derives the behaviour from scratch, usually on a different stack.
The confusion is expensive because the two carry different risks. Refactoring risks spending a year and arriving at the same ceiling. Rewriting risks shipping a product that does 80% of what the old one did, 6 months late, with the missing 20% turning out to be the part that billed customers.
Both risks are real. Neither is settled by looking at the code.
One boundary. This article covers code-level decisions. For questions about where the workload runs, our lift and shift versus refactor guide for cloud migration covers that decision instead.
The honest answer: neither, until you've answered 4 questions
The decision comes down to whether you can recover what the system does without reading the code. We call it the Specification Recovery Test, and it has 4 signals.
| Signal | The question | Points to refactor | Points to rebuild |
|---|---|---|---|
| 1. Behaviour recoverability | Can we write down what this does, without reading the code? | Yes, or close. Docs, tests, or people still hold it | No. The behaviour lives only in the code and the authors have gone |
| 2. The safety net | If we change this, does anything tell us we broke it? | A regression net exists, or it's cheap to build | Nothing catches a break except a customer |
| 3. The commercial anchor | What in here earns money and must not move? | Something specific: rankings, billing, a live integration, a compliance state | Nothing that can't be reproduced |
| 4. The dead-runtime clock | Is the stack on a date somebody else set? | Supported, and upgradeable in place | End of life passed, or passing inside 12 months |
The test earns its keep on one detail. A system scores differently per module. Run it on the whole platform and you'll get a mushy average. Run it on the billing service, then the admin panel, then the integration layer, and you'll get 3 different verdicts.
That's what happened at HeyPractice. Our audit named 8 defects and came back split: keep the database structure, models, and migrations, replace the rest. The data model scored well on signal 1 because it was legible and the domain hadn't changed. The controllers scored badly on signal 2 because nothing tested them. You can read what we did with HeyPractice's backend for the longer version.
Signal 2 is the one teams underrate most. With Traders Alloy the previous vendor couldn't get a pipeline running at all, which meant every change was a guess. We built the pipeline on Jenkins across backend and frontend before touching anything architectural, because a safety net changes the answer to the whole question.
What AI actually changed, and what it left alone
Two years ago this decision was priced on developer hours, and both options were expensive in roughly the same currency. AI moved one side of that ledger a long way, and left the other side sitting where it was.
Start with what got cheaper. Google ran 39 identifier migrations over 12 months, submitting 595 changes and 93,574 edits. 74.45% of the code changes were LLM-generated, and the engineers estimated a 50% cut in total migration time (Ziftci et al., Google). Mechanical rewriting at scale got genuinely cheap.
We measured the same thing ourselves. Fieldera, our field operations platform, was generated from a single requirements document for $1,609 in AI spend across 5.5 days, producing 82 database models, 343 API endpoints, and around 454 automated tests. Fieldera is at design-partner stage and was built by us in Brocoders, so read that as a measurement of our method.
Now the side that stayed expensive. METR ran a randomised trial with 16 experienced developers on 246 real issues, in repositories they'd contributed to for years, averaging over 1,000,000 lines of code. With AI tools allowed, they took 19% longer. They'd predicted a 24% speedup, and afterwards still believed they'd got one (METR).
The two findings separate cleanly once you look at the work. Google's migrations were specified before a line was written. METR's issues were open-ended. The speedup lands on specified work.
There's a third number worth sitting with. Across 623 million changes between 2023 and 2026, GitClear found the share of "moved" code, the signature of refactoring, fell from 21% in 2022 to 3.8% by mid-2026, while block duplication rose 81% and long-term code updates dropped 74% (GitClear).
Teams with AI assistance are refactoring less and duplicating more. Which means the legacy problem is being manufactured faster than anyone is clearing it, and the systems arriving on your desk in 2027 will score worse on signal 1 than the ones arriving today.
The nuance vendors skip: incremental is also the longer invoice
Plenty of agencies publish a version of "we almost always choose incremental modernization." We counted 5 or more of them on this query alone, and not one ranks in the top 10 for it.
Incremental is usually the safer engineering call, and we make it ourselves most of the time. It's also the longer engagement, the bigger monthly invoice, and the one recommendation a modernization vendor can give without putting revenue at risk. None of those pages says so.
Worth naming, because we sit in the same conflict. We in Brocoders sell rebuilds, and an article recommending rebuilds is an article recommending us.
The way we handle that is to sell the verdict separately from the work. Our Modernization Diagnostic runs 2 weeks at a fixed price from $6,000, and produces an architecture map, a dependency graph, a security and data review, a test coverage assessment, a prioritised risk register, and a written refactor versus rebuild recommendation that is permitted to say do not rebuild. Several clients have bought it and gone elsewhere with the answer. That's the point of pricing it standalone.
What gets kept when you rebuild
Lake ran a property management platform where the monolith physically capped growth. Property managers refused to use it until data sync was solved, which put the architecture in the middle of every sales conversation.
We rebuilt the platform in 3 months with a team of 5. Connected properties went from around 500 to 40,000, an 80x increase.
The decision worth studying is what stayed. We kept the WordPress content pages exactly where they were, because they carried the organic rankings and a new stack would have done nothing for them. Signal 3, the commercial anchor, said leave it alone.
The pattern repeats. PayPilot's legacy payroll platform was renovated without ever pausing the business, because a payroll system that stops loses customers. When an acquirer handed us ShineUp's inherited codebase, we stood it up in their own AWS at a fixed price in 2 to 3 weeks, with no architectural opinions attached, because what they needed was possession. And with CoreHealth we rewrote the previous contractor's codebase, added integrations, and shipped in 6 weeks with a team of 5, which grew into 3 platforms.
The thing worth protecting is almost always commercial: rankings, billing continuity, a live integration, a compliance state. Find it first, and the rebuild scope shrinks around it.
How to tell whether a vendor's answer is honest
Assume every vendor's recommendation is partly a sales position, including ours, then test it with 4 questions.
Did they ask to see the thing the system actually depends on? When David Ciccarelli hired us at Lake, he put it this way: "He was the only one of 150 vendors who asked to speak with the integration partner that we were working with." A vendor pricing a decision without touching its riskiest dependency is pricing a guess.
Can they name a condition under which they'd recommend against the work? If no answer exists, the recommendation carries no information.
Is the verdict per module or per system? A whole-system answer usually means nobody read the system.
Do they treat modernization as a project with an end? CondoGenie has been running with us since 2018, 8 years and ongoing: a Rails upgrade in August 2025, a Playwright migration from June to September 2025, a Stripe API migration in February 2026, and a frontend toolchain move off unsupported Node 14 and 18 to Node 24.19.0 LTS in flight, across 1,806 modules in 4,241 files. Runtimes keep reaching end of life whichever option you pick.
Where to start
Run the 4 signals on your 3 most troublesome modules this week. You'll probably get a split verdict, and a split verdict is a scope you can actually fund.
If you'd rather have it written down and argued, our Modernization Diagnostic delivers that verdict in 2 weeks from $6,000, and it's allowed to tell you not to rebuild. For deeper reading on the rebuild side, see our guide to legacy application modernization.
Frequently Asked Questions
Refactoring restructures existing code while keeping its behaviour identical. Rewriting replaces the implementation and re-derives the behaviour, usually on a new stack. Refactoring preserves accumulated fixes you may not know about. Rewriting gives you a clean architecture and asks you to rediscover them.
When the system's behaviour exists only in the code, nothing tests it, nothing commercially fragile is embedded in it, and the runtime is at or near end of life. Those 4 conditions together make refactoring the more expensive path, because every change is an archaeology project with no safety net.
Partly. AI is strong on mechanically specified work: Google reported 74.45% of code changes LLM-generated across 39 migrations, with a 50% cut in migration time. On unspecified work in large mature codebases, METR measured experienced developers running 19% slower with AI tools. Specified work got cheaper. Exploratory work stayed where it was.
It depends on signal 2. Where a regression safety net exists, maintenance stays affordable for years. Where nothing catches a break, maintenance cost rises with every release, and a rebuild that includes a test suite usually wins inside 2 years.
Our own range runs from 2 to 3 weeks for standing up an inherited codebase, to 6 weeks for a rebuilt MVP with integrations, to 3 months for a full platform rebuild with a team of 5. Scope drives the number, and the stack barely touches it.
You route traffic through a facade and replace functionality behind it piece by piece, retiring the old system gradually. It fails when the old system has no clean seams to cut along, which is exactly what a bad score on signal 1 predicts. Strangling a system you can't describe means running 2 systems indefinitely.
Yes, and it's usually the right answer. HeyPractice kept its database structure, models, and migrations while the rest was replaced. Lake kept its WordPress content pages through a full platform rebuild.
Ask what would make them say no, and check whether they've priced the diagnosis separately from the build. A vendor whose assessment is free is a vendor whose assessment is a sales call.