Getting a Second Opinion on a Software Rewrite Proposal

A developer or an agency just told you the system needs to be rewritten, and the number attached to that sentence has six figures in it. Before you sign anything, a second opinion software project review from someone with no stake in winning the rewrite contract can tell you whether that conclusion holds up, and what it will actually cost to find out.

This happens constantly, and it is not necessarily because an agency is trying to inflate a bill. Codebases do accumulate real problems. But "rewrite" is also the answer an agency reaches for when a cleaner, cheaper path exists and nobody has taken the time to look for it, or when the team recommending the rewrite is the same team that would be paid to build it. Either way, the responsible move is the same: ask questions that test the claim before committing a year of runway to rebuilding something that might only need six months of focused repair.

What exactly is broken, and how do they know

Ask the agency to name the specific problems, not a general impression. "The codebase is messy" is not a finding. "Three services share one database table with no foreign keys, and the checkout flow calls the payments API synchronously with no retry logic" is a finding, and findings like that can be checked by someone else in an afternoon.

Ask what they measured to reach their conclusion, and how. Did someone read the code, run a static analysis tool, time how long a feature takes to ship compared to six months ago, or talk to the two engineers who already quit over it? Each of those produces a different kind of evidence, and a proposal built on one engineer's impression after a day of looking around deserves more scrutiny than one built on actual numbers.

Ask what happens to the features that are still running while the rewrite happens. A six-month or twelve-month rewrite usually means a long stretch where the old system still needs bug fixes and the new one is not ready for production traffic. If the proposal does not address this, treat it as incomplete. Keeping features shipping while someone fixes the foundation covers the alternative: splitting the work so the business does not freeze for a year.

And ask how the data moves. A rewrite is not just new code, it is a migration of every customer record, transaction, and historical report into a new schema, usually while the business keeps operating. Get specifics on how that migration will be tested, what the rollback plan looks like if something breaks halfway through, and who is accountable if customer data is lost or corrupted during the move.

These questions work best asked directly in a meeting rather than over email, where follow-up questions are easier to deflect. Bring whoever on your side has the sharpest technical judgment, even if that person is not a developer, and write down the answers you get. A vendor who is confident in their own assessment will not mind the scrutiny.

Red flags that show up in rewrite proposals

A few patterns are worth watching for, because they turn up often enough to be predictable.

The proposal includes no comparison against keeping the current system and fixing specific problems one at a time. If refactoring was never seriously evaluated, the recommendation is one-sided by design.

The timeline and cost estimate have no range and no stated assumptions. Software estimates are never exact, and a single number with no caveats about what could push it higher usually means the real number surfaces later, after the contract is signed.

The team proposing the rewrite is the same team that would staff it, with no independent technical review built into the process. That is not automatically a sign of bad faith. Plenty of agencies do good work on both ends. But it removes a natural check that exists when a different party looks at the same evidence.

The pitch leans on urgency without naming a specific, dated risk. "This needs to happen now" is a feeling. "The authentication library has an unpatched vulnerability disclosed last month" is an argument.

What a second opinion software project review actually costs and delivers

A proper second opinion software project review does not need to take long or cost anywhere near what the rewrite itself would. Most independent reviews run one to two weeks, done by someone who reads the actual code, talks to the engineers who maintain it, and checks the specific claims in the rewrite proposal against what they find.

How bad is it really? What a two week codebase assessment tells a non-technical owner walks through what that engagement looks like in practice: a ranked list of what is actually wrong, what is already fine and does not need touching, and a cost range for fixing the real problems instead of replacing the whole system.

What you want out of this kind of review is a decision you can defend to your board or your co-founder, not just a second number to weigh against the first one. A good review will say plainly whether the original rewrite recommendation was reasonable, overstated, or missing a cheaper option entirely, in terms a non-technical owner can act on.

The deliverable should be something you can actually hand to your board, or back to the agency that proposed the rewrite, rather than a private verdict you are asked to take on faith. Expect a written report naming the specific problems found, which ones are serious enough to justify starting over, and which could be fixed where they stand. A reviewer who cannot produce something concrete and sharable has not really done the work.

None of this is about discrediting the agency that proposed the rewrite. Some rewrites are genuinely necessary, and a second opinion that confirms the original advice is just as useful as one that overturns it. Either way, you are making a six-figure decision with actual evidence behind it instead of trust alone.

When the rewrite really is the right call

Sometimes the original advice turns out to be correct. If the codebase has grown so tangled that every new feature breaks three old ones, if the underlying framework has been unsupported for years and cannot be patched for known vulnerabilities, or if the team cannot safely deploy without a rollback process that takes hours to run, a rewrite can genuinely cost less than years of continued patching.

When to rewrite vs. refactor: a decision framework for legacy systems lays out a scoring approach for the technical side of this decision, weighing codebase health, business risk, and team capability against each other instead of arguing about them in the abstract. Whoever runs your second opinion should be working through something close to that framework, not just offering a personal view.

The point of getting a second opinion on a software project is not to avoid an expensive decision. Rewrites are sometimes the right expensive decision. The point is making sure the number you are asked to sign off on reflects the actual state of the system, not just how one meeting happened to go.

Getting a review before you sign

If you are holding a rewrite proposal right now and something about the number or the reasoning feels off, that instinct is worth a week of someone else's time to check. We offer this through our legacy code optimization and code quality consulting work: a review of the actual code against the actual proposal, flagging where the two do not line up, with a plain answer about whether a full rewrite, a staged refactor, or something smaller fits your situation. Reach out at hello@wolf-tech.io or visit wolf-tech.io to set one up.