Challenge a rewrite proposal with evidence, not fear

Why rewrite pitches feel hard to judge

A rewrite pitch usually arrives with one blunt message: the code is messy, and the business is at risk. Any founder will pay attention to that. Most can't inspect the code on their own, so they end up judging the claim through confidence, tone, and urgency.

That is where things get slippery. "Messy code" can mean old libraries, weak tests, slow releases, poor handoffs, unclear ownership, or all of them at once. Those are different problems, yet teams often bundle them together and present the whole bundle as a case for a rewrite.

A fresh start also sounds easier than slow repair. People picture a smaller codebase, fewer bugs, and faster product work. They don't picture the hidden cost: rebuilding edge cases, moving data, retraining the team, and running two systems at once while the new one catches up.

Founders also hear certainty before they see proof. A team under pressure may say, "We can't move unless we rebuild." That sounds technical, but it is often emotional. Frustration with weak release habits, unclear product decisions, or constant scope changes gets framed as a code problem.

A simple example shows why this is hard to judge. A startup misses three deadlines. The engineering lead says the current app is too tangled and asks for a full rebuild. Maybe the code really is rough. But maybe the team also changes priorities every week, ships without tests, and fixes production issues by hand. Rewriting the app won't fix those habits.

To challenge a rewrite proposal, separate code pain from delivery pain. They overlap, but they are not the same thing. When a team mixes them together, a rebuild can sound like the only serious option even when the real problem sits in planning, ownership, or release process.

Evidence worth asking for

Ask for a record of pain, not opinions. A strong case starts with the last six months of outages, missed release dates, support tickets, and customer-facing bugs. If the team can't show that trail, the rewrite claim is already weak.

Then sort each problem by source. Some issues come from code that is hard to change. Others come from unclear scope, slow code reviews, poor testing, or a release process that falls apart under pressure. Founders often hear "the code is the problem" when the team really means "our way of working is messy."

A short table is enough. It should answer five basic questions:

• What went wrong in the last six months
• Which part of the product caused it
• What blocked the fix
• Who owns that area today
• How often the same issue came back

That last point matters a lot. A bug that returns every month tells you more than one dramatic outage. Repeated trouble points to a pattern you can actually fix.

You also need a side-by-side cost check. Ask the team to compare the effort to repair the worst modules with the effort to rebuild the whole product. If three modules cause most of the support pain and release delays, fixing those areas may be faster and safer than starting over. Full rebuild estimates often leave out migration work, retesting, new bugs, and months of feature slowdown.

Keep the discussion tied to business damage. Which modules block sales demos, delay onboarding, create support load, or stop releases? If the team can't name them, the proposal is still too vague.

This is the level of evidence an experienced CTO asks for before backing a rebuild. It turns a tense meeting into a plain business discussion: what breaks, how often it breaks, what it costs, and whether a smaller fix solves most of it.

Metrics that mislead founders

Rewrite pitches often come with numbers that look serious but don't say much. Big totals create panic fast, which is why founders should ask what each metric actually means for customers, revenue, delivery time, or risk.

Lines of code and file counts are weak signals. A product with 300,000 lines is not broken because the number looks large. Some teams split code into many small files. Others keep more in fewer places. Those habits change the count, not the business risk.

Story points and velocity can mislead too. Teams estimate work in different ways, and many change their scale over time. If one team says it delivers 80 points a sprint and another says 30, that tells you almost nothing unless they size work the same way. Velocity is a team habit, not proof that the current system is beyond repair.

Old framework versions need context. A system can run well on an older stack if the team knows it, patches security issues, and ships changes without drama. Age alone is not a reason to rebuild. The better question is whether the current stack blocks hiring, security, performance, or product work right now.

Bug counts are easy to wave around in meetings. Raw totals hide the part that matters. Twenty small UI bugs are not the same as two billing failures. Read bug numbers with severity, customer impact, and trend. If serious bugs are falling and the team fixes them quickly, the headline number may look worse than the real risk.

Test coverage has the same problem. A report that says 85% can still hide fragile code, weak tests, or missing coverage in risky areas. A report that says 35% does not prove a rewrite either. Coverage matters only when you pair it with release failures, escaped defects, and how safely the team can change the code.

A quick check helps. Ask which metric connects to lost revenue, churn, outages, or missed releases. Ask for a 6 to 12 month trend instead of a one-week snapshot. Ask which problems a focused refactor would solve without a full rebuild. And ask what would stay broken even after a rewrite.

If the argument leans on code size, old tools, point totals, or one scary bug chart, the case is still thin.

When the real issue is process

A rewrite pitch may sound technical, but the pain often starts in the team's habits. If releases drag, nobody owns decisions, and QA happens at the last minute, the code is only part of the story. New code dropped into the same workflow usually becomes the same mess a few months later.

One pattern shows up all the time. The team says "every change is risky," but nobody can explain who approves requirements, who reviews code, or how they test before release. That is a process problem. If people start building before the work is clear, the product shifts mid-build, bugs pile up, and everyone blames the old system.

Ask the team to walk through one normal change. Pick something small, like updating a pricing rule or adding one field to a form. Then ask who wrote the requirement, whether it stayed stable, who reviewed the code, where it was tested, how it would be rolled back, and how long that full path took.

Those answers tell you more than a speech about "technical debt." If the requirement changed three times, the branch sat unreviewed for days, and QA found problems right before launch, the workflow is hurting the team every week.

A full rebuild won't fix unclear ownership. It won't fix weak review habits. It won't fix a release process with no staging and no rollback plan. In fact, a rewrite can make those problems worse because the team now has more moving parts, less historical context, and fresh bugs.

Picture a team that says the app is too fragile to update. Then you look closer and see product decisions happening in chat, engineers coding from memory, and testers seeing the feature for the first time on release day. That team does not need a new codebase first. It needs stable requirements, review rules, and a safer release flow.

If the rewrite proposal spends ten pages on architecture and zero time on process fixes, take that as a warning. The team may be trying to code its way out of management problems.

How to challenge the claim step by step

When a team says, "we need to rebuild," slow the conversation down. A rewrite pitch often sounds cleaner than the current mess, so people stop asking basic questions. That gets expensive.

Start with one sentence. Ask the team to describe the business problem without technical filler. Good answers sound like this: "New customer onboarding breaks twice a week," or "Each release takes four days and blocks sales demos." If they can't name the business problem clearly, they are pitching effort, not a result.

Then ask for three paths side by side: patch the worst part, rewrite one area, or rebuild the whole thing. This is where software rewrite vs refactor stops being an abstract debate and turns into a decision you can test.

Put the same facts next to each option: time to first result, total cost, main risks, expected business effect, and what stays in production during the work. Keep it plain. "Six months" means little on its own. "Six months, two engineers, delayed roadmap, and no user benefit until the end" tells the truth.

A full rebuild should also answer one uncomfortable question: what will this fix that a smaller change cannot fix? Teams often hide process problems inside a big technical proposal. Poor estimates, weak testing, no code ownership, and constant requirement changes do not disappear because the code is new.

Don't approve the plan from the slide deck. Ask for a proof task that fits into two weeks. Pick one painful area and ask the team to show progress in production, or at least in a close test setup. They might reduce deployment time, replace one fragile module, or ship one feature they said the current code blocked.

That short proof tells you a lot. You see how they estimate, how they work together, and whether the real issue is architecture or execution. If a team can't deliver a small proof with a clear result, a six-month rebuild claim should worry you.

The simplest rule is this: delay the big decision until the proof task ends. Pitches sell hope. Small delivered results are harder to argue with.

When a rebuild actually makes sense

Most rewrite pitches are weak. A few are real. A rebuild deserves a yes when the current system blocks the business in ways small fixes cannot remove.

One obvious case is vendor dependence. If the product sits on a platform, framework, or hosted service you can no longer use, the team may have no safe path except replacement. That happens when a vendor changes terms, ends support, or removes a feature your product needs.

Security and compliance can force the same choice. If sales keeps stalling because the product lacks access controls, audit logs, data separation, or other required safeguards, ask one hard question: can the team add them without tearing through the whole design? If the honest answer is no, patching will drag on and still leave you exposed.

A rebuild also makes sense when the system no longer fits the product you sell today. A tool built for custom projects may fail as a self-serve SaaS product. A single-tenant app may break when you need one product for many customers. Here, software rewrite vs refactor becomes a business decision, not just a code debate.

The migration plan matters as much as the code plan. A serious rebuild lets you move customers in stages, keep the old product alive, and roll back when something goes wrong. If the proposal depends on one giant cutover weekend, the risk is high and the plan is probably not ready.

Money matters too. You still need to support customers, fix bugs, and ship small wins while the new system is under construction. If the rebuild will consume the whole team and starve the current product for a year, it may be correct in theory and fatal in practice.

A solid rebuild case sounds plain. It names the business block, shows why smaller fixes will fail, explains how customers move safely, and shows how the company will pay for both tracks at once. If a team can't do that, founders should push back harder. A rebuild earns trust when it solves a real business limit, not when it promises cleaner code.

A simple startup example

A small SaaS company missed four release dates in two months. The engineering lead said the problem was old code and asked for a full rebuild. The pitch sounded urgent: the codebase was "too messy," developers were nervous about changing it, and every release seemed to drag.

The founder did not approve the rewrite on the spot. She asked for three things: outage history, support tickets tied to bugs, and a list of delayed releases with one reason for each delay. That simple request changed the discussion.

The outage data showed only one serious incident in the last quarter, and a bad deployment caused it. Support tickets pointed to billing edge cases and a few confusing settings screens. The release log told the bigger story. Most delays came from late testing, vague requirements, and messy handoffs between product and engineering.

So the team had a code problem, but not the one used to sell a full restart. One billing area had become fragile, and two engineers spent hours checking it by hand before each launch. That mattered. Still, it was one area, not proof that the whole product needed to go.

The founder chose a smaller plan. The team fixed the release process first. Product managers wrote clearer acceptance criteria. Engineers added smoke tests around billing and used a short checklist before each release. At the same time, they rewrote the billing area in parts, with tests around each step, instead of freezing the roadmap for a full rebuild.

Three months later, the team shipped twice on schedule. Support noise dropped, and the billing work caused fewer surprises. The company still had old code in many places, but it no longer had chaos around releases. When founders ask for evidence, they often find a process problem with one painful module attached to it, not a reason to start over.

Mistakes founders make in rewrite meetings

Founders often make the same first mistake: they treat confidence as proof. A lead engineer says the codebase is "unfixable," the room gets tense, and the rebuild starts to sound unavoidable. Strong opinions still need evidence. Ask for defect trends, delivery delays, support pain, and a side-by-side cost estimate.

Another mistake is accepting a bad comparison. Teams put today's messy product next to a perfect future version with no legacy bugs, no deadline pressure, and no strange customer behavior. That future version does not exist. A rewrite inherits product complexity very quickly, even if the code starts cleaner.

A few questions usually cut through the fog. Which customer problems disappear after the rebuild? Which current features will the new version lack for the first six months? How will users, data, and integrations move over? What happens if the new system slips by one quarter? What can the team fix now without a rewrite?

Founders also approve rebuilds without asking for a migration plan. That is risky. If the team can't explain how old and new systems will run, how data will stay correct, and how customers will avoid disruption, the proposal is not ready. It is just hope.

Customer freeze risk gets ignored too often. A long rewrite can stop product progress for months while competitors keep shipping. Sales hears "not yet," support keeps patching the old system, and customers wait longer for small fixes that matter now. That cost is real, even if it never shows up in the engineering plan.

One more mistake is keeping the discussion inside the same tired team loop. When people feel stuck, they often mistake frustration for technical truth. An outside review from a fractional CTO or senior architect can expose a process problem instead: weak code review, no ownership, rushed releases, or constant scope churn. Separate code problems from team habits before you approve anything expensive.

Quick checks before you say yes

A rewrite can sound clean and brave. It often hides a messier fact: nobody has pinned down the real business pain.

Start with plain language. If the team can't name the top three problems without jargon, pause the meeting. "The code is hard to work with" is not a business problem. "New customer onboarding takes three weeks, billing bugs keep coming back, and mobile changes miss every release" is.

A good proposal shows more than developer frustration. Engineers may be right that the current code slows them down, but founders should ask what customers actually feel. Are users waiting longer for fixes? Are sales calls stalling because one feature never ships? Is support spending hours on the same failure every week? If nobody can connect the rewrite to customer pain, the case is still weak.

Before you approve anything, check five things:

• Tie the three biggest problems to revenue, churn, support load, or delivery speed.
• Compare three options: full rewrite, partial rewrite of the worst area, and process fixes on the current product.
• Ask what customers notice now, not just what bothers the engineering team.
• Ask for a proof task that takes a week or two.
• Ask how the team will ship, monitor, and support old and new parts at the same time.

That last point matters more than many founders expect. Teams love the clean slate idea, then forget the ugly middle. For months, maybe longer, they will run two systems, two sets of bugs, and two release paths. If they have no plan for that, the rewrite cost is already understated.

Pricing tells you a lot too. If the team priced only the full rebuild and ignored a partial rewrite or a process repair, they may have fallen in love with the big project. Sometimes the real fix is smaller: better code review, tighter release rules, fewer urgent side requests, or one senior engineer cleaning up the worst area first.

The proof task is where weak arguments usually break. A team that understands the problem can test its claim quickly. A team that can't design a small trial probably doesn't understand the problem well enough to rebuild the whole product.

If you want one simple rule, use this: say no until the team can show business pain, real options, a small test, and a plan for the messy transition period.

What to do next

A rewrite meeting should end with a written decision, not a gut feeling. If the team says the product needs a rebuild, ask for a one-page brief. It should show the evidence, the real options, the risks of each option, and what happens if you wait one more quarter.

Keep that brief plain. If people need ten slides to explain why the code must go, the problem may be less clear than they think. You need a document you can compare, question, and revisit.

Then ask for a 90-day plan that starts with the most expensive problem. Pick the issue that costs the most money, time, or customer trust right now. That might be failed releases, slow onboarding for new developers, or one fragile area that keeps breaking in production.

The next steps can stay simple:

• Write the rebuild claim on one page.
• Name at least one non-rewrite option.
• Start with one high-cost problem in a 90-day plan.
• Assign one owner for each decision.
• Set a decision date before the meeting ends.

If your team can't agree on the facts, bring in a neutral reviewer. A fractional CTO such as Oleg Sotnikov at oleg.is can review the architecture, team process, and rebuild plan from the outside. That kind of second opinion is often more useful than another internal debate because it separates real technical limits from process mistakes and unclear ownership.

Do not leave the room with "we will think about it." Leave with a date, named owners, and one next action. Approve a small trial, request the missing evidence, or pause the rebuild claim until the team proves the first 90-day step. A rewrite is a business bet, so treat it like one.