Questions before a rewrite: what mentors should ask

Why rewrite advice goes wrong

Rewrite advice often sounds smart because messy products are easy to judge from the outside. Old code looks slow, awkward, and expensive to maintain. Starting over feels clean. For a mentor, that can seem sensible. For a small startup, it's often a risky bet.

Most small teams don't pay for a rewrite with code alone. They pay with time.

Two engineers who stop shipping for 10 weeks do more than write a new version. They also stop doing the work that keeps the company alive: fixing bugs, helping sales, improving onboarding, and shipping the small product changes that reduce churn.

The cost usually shows up in plain ways:

• support tickets stay open longer
• promised fixes slip
• sales calls get harder
• customers lose patience

Customers rarely care that the new codebase will be nicer later. They need the current product to work now. If reporting breaks, login fails, or billing blocks a team, they expect a fix today. A rewrite doesn't pause those expectations.

That creates a hard split. One product pays the bills. The other consumes the team. Small companies feel that split fast.

Advice goes wrong when mentors move from "this code looks bad" to "you should rewrite it" without checking the business first. Bad code can still be the right code for now. A startup with one engineer, six months of runway, and a handful of demanding customers does not have the same options as a funded team with spare capacity.

That's why questions matter more than opinions about code quality. Mentors need facts about team size, runway, product risk, and customer pressure before they give a technical answer. Without those facts, a rewrite is not a plan. It's a guess, and the team pays the bill.

Ask about the team first

The first questions before a rewrite are about people, not code. A shaky codebase can still move fast if the team knows it well. A clean new stack can stall for months if only one person understands the old system and nobody has spare time.

Start with the shipping rhythm. How many engineers actually push production code in a normal week? A team of six on paper may really be two people shipping, one founder reviewing, and three people tied up in support, sales requests, or hiring.

Then ask who can change the current system without breaking it. Mentors often miss the real risk here. If one senior engineer holds most of the working knowledge, a rewrite does not remove danger. It often spreads that danger into a bigger project with more unknowns.

A short question set works well:

• Who shipped code last week, and how many of them can do it again next week?
• Which parts of the current product can only one person change safely?
• What business work stops if the team spends the next eight weeks rebuilding?
• Can this team maintain the live product while building a replacement?

The third question matters more than many mentors expect. If the same engineers who would lead a rewrite also handle outages, customer fixes, onboarding changes, and security patches, the rewrite is already under strain before it starts.

Dual maintenance is the trap. Teams say they will keep the old product stable while building the new one, but small teams rarely do both well. Bug fixes pile up in the old system. The new system slips. Morale drops because nobody sees finished work.

A simple rule helps: if the team cannot name at least two people who understand the current system, and cannot free a steady stream of time for new work, the rewrite is probably a staffing problem dressed up as a code problem. That doesn't mean never rewrite. It means fix the team shape first, or narrow the scope until the team can carry it.

Ask about runway before code quality

Clean code does not pay next month's salaries. If a startup has six months of cash left, the first question is not whether the code feels messy. It's whether the team can reach a revenue or funding event before the money runs out.

Ask for one plain number first: how many months of cash remain at the current burn rate. Don't accept a vague answer like "we should be fine until summer." A mentor needs a date, because rewrite advice changes a lot when the company has 12 months left versus four.

Then ask what must happen before that date. Maybe the team needs a paid pilot to convert, a renewal to land, or a bridge round to close. If nobody can name the next money event, a rewrite gets much harder to defend.

The next part is where many teams get honest. How much runway can they spend without shipping anything customers will notice? For some startups, that number is two weeks. For others, it's one release cycle. If the answer is "maybe a couple of months," nobody has done the math.

A rewrite almost always eats time before it creates visible value. Even a small team can burn 6 to 10 weeks rebuilding login, billing, admin tools, testing, and deployment before a customer sees a single improvement. That's why runway has to enter the conversation early, not after a code review.

One more test matters: what happens if the rewrite slips by one quarter? That delay can cancel a sales window, push a fundraise into weaker numbers, or leave support issues unresolved while the team rebuilds behind the scenes. Code problems hurt, but timing problems kill companies faster.

A startup with five months of cash and a renewal coming in eight weeks usually should patch the product, ship what customers need, and buy time. A startup with 18 months of runway and a codebase that blocks every release has more room to rebuild. The code matters, but the calendar usually decides first.

Ask what product risk looks like

A rewrite deserves attention only when the current product creates real business risk. "The code feels old" is not enough. Ask what breaks, who feels it, and what it costs in lost revenue, lost trust, or missed deadlines.

Start with the damage. Which bugs stop a customer from paying, signing up, or finishing the main task? Which issues create compliance trouble, security gaps, or manual work every week? If a flaw blocks invoicing or corrupts customer data, that's a product problem. If a module is annoying to work in but rarely fails, that's a team problem.

This is where the discussion gets sharper. The team has to separate unstable areas from ugly ones.

• Which issue blocked sales, renewals, or onboarding in the last month?
• Which part fails in production more than once?
• Which problem creates legal, security, or audit risk?
• Which risky area could the team replace on its own?
• What evidence shows the current stack will fail at the next stage?

The fourth question matters more than mentors often think. A full rebuild is rarely the first fix. If one reporting job times out, the team may only need to replace that job. If checkout fails under load, they may only need to isolate checkout and harden it. Small repairs give proof faster and cost far less.

Ask for evidence, not opinions. Error logs, outage notes, churn from one broken feature, support volume, failed deals, and manual workarounds tell a clearer story than "our stack cannot scale." Teams sometimes blame the stack when the real issue is weak monitoring, poor tests, or one bad integration.

A simple example helps. If a startup says the whole app is risky, ask what happened last week. If they point to two failed exports and one billing outage, you already know more. Exports may need cleanup. Billing may need urgent work. The whole product probably does not need a rewrite.

Product risk should look concrete. If nobody can name the failure, the cost, and the proof, the case is still weak.

Ask where customer pressure comes from

Customer pressure is easy to misread. A founder says users are unhappy, and a mentor jumps to a rewrite. That skips the real question: what are customers actually unhappy about?

Most customers do not care whether the codebase feels clean to the team. They care about what blocks them now. In practice, complaints usually fall into a few buckets: missing features, slow performance, reliability problems, or weak integrations.

Ask for specifics:

• What do customers ask for most often: new features, better speed, fewer failures, or integrations with tools they already use?
• Which accounts might leave soon, and what exact problem is pushing them there?
• Do support tickets pile up around one weak area, or do they show many small annoyances across the product?
• Would a rewrite fix the thing customers complain about now, or would it only give the team cleaner code?

Those answers change the advice fast.

If the loudest pressure comes from two big prospects who need a CRM integration, a rewrite won't help much. The team probably needs to build that integration and tighten the sales promise. If customers complain that reports take 40 seconds to load, the team may need to fix one slow service, not rebuild the whole product.

Sometimes the pattern does point to deeper code trouble. If support tickets, churn notes, and account calls all point to the same unstable area, the team may need a focused rewrite of that part. That's very different from replacing the whole product.

A small startup can get this wrong quickly. Picture a team with one engineer and a few paying customers. Three accounts threaten to leave because syncs fail every morning. A full rewrite could take months. Those customers won't wait months. They want the sync to work next week.

Ask for names, examples, and recent complaints. If nobody can point to a clear customer pain that a rewrite solves, the pressure is probably internal, not market-driven. That's a warning sign.

Use the answers in this order

The order matters more than most mentors admit. If you start with code taste, you can talk yourself into a rebuild the company cannot carry.

Start with customer pressure. Ask what customers need right now, what deals are stuck, what bugs keep coming back, and what requests the team hears every week. Ugly code is annoying. Lost renewals, missed pilots, and support fires cost money now.

Then put product risk next to runway. If the product still changes every month, a full rewrite adds two risks at once: you may rebuild the wrong thing, and you may run out of cash before it ships. A startup rewrite decision only makes sense when the company can survive the delay.

After that, look at team capacity. A team of three cannot usually keep the current product alive, ship promised work, and rebuild the core at the same time. Mentors miss this part because the rewrite sounds clean on paper. In practice, the same engineers still answer incidents, unblock sales, and fix customer pain.

A simple order works well:

1. What customer pressure is live today?
2. How much runway is left if delivery slows down?
3. Can this team keep shipping while rewrite work happens?
4. What is the smallest change that removes the current pain?
5. Does that point to a patch, a module swap, or a real rewrite?

That last step should stay narrow. If one billing service keeps breaking, replace that module. If the product works but the admin area is slow, patch it. Save a full rewrite for cases where the current system blocks the business and there is enough time and team strength to absorb the hit.

Write the decision in one plain sentence. For example: "We will patch onboarding for six weeks because sales needs it now, runway is short, and the team cannot stop feature work." If you cannot write that sentence clearly, you don't have enough information yet.

A realistic example from a small startup

A three-person SaaS team wanted to replace its old backend after months of slow fixes and strange bugs. A rewrite sounded clean and satisfying. The code annoyed everyone, and each new change felt slower than the last.

Then a mentor asked better questions. Who will do the work? How much runway is left? What product risk hurts first if nothing changes? Which customers are pushing hardest right now?

The answers changed the plan quickly. The company had seven months of runway and no spare engineer. Two large customers were waiting on reporting fixes, and both expected updates within six weeks. If the team missed that window, the risk was not technical debt. The risk was lost revenue.

Once that was clear, a full rewrite looked hard to defend. The team would spend months rebuilding code customers could not see while urgent reporting problems stayed open. That would raise delivery risk, burn runway, and strain the customer relationship.

The mentor did not tell them to ignore the backend. He shifted them from a full rewrite to staged cleanup. They kept the current system running, fixed the reporting path first, and added tests around the parts that broke most often. They also chose one painful area to replace later instead of touching everything at once.

Their plan was simple:

• Ship the reporting fixes for the two customers first.
• Put tests around the current reporting code before deeper changes.
• Clean up the worst backend module after the deadline passes.
• Recheck runway and team capacity before any larger rebuild.

They also set boundaries. No new database migration, no broad service split, and no side work that didn't help reporting or stability. That kept the team from turning a six-week customer problem into a six-month engineering project.

This is where rewrite advice often goes wrong. Old code can be ugly and still be the right code to keep for now. In this case, the safer move was not glamorous. It gave the team a real chance to keep customers, protect cash, and earn time for deeper changes later.

Mistakes mentors make when they push a rewrite

The most common mistake is simple: they see messy code and treat it as proof that the whole product is broken. Messy code often means the team moved fast under pressure. It does not always mean the product needs a fresh start.

A mentor can look at a rough codebase, feel secondhand pain, and jump straight to "rewrite it." That advice sounds clean. Real startups are not clean. A product can have ugly internals and still make money, keep users happy, and survive with a few careful repairs.

Another mistake is ignoring support work. During a rewrite, bugs still show up, customers still ask for help, and someone still has to ship small fixes. If the team has three engineers and two of them disappear into a rebuild, the third person becomes the support desk, the release manager, and the firefighter. That's how teams slow down without noticing at first.

Mentors also overestimate how fast new code ships. New code feels faster because nobody has touched the sharp edges yet. Then the team hits the old problems again: edge cases, unclear specs, missing tests, rushed handoffs, and half-finished product decisions. Repaired code can be ugly, but it often ships this week. Rewrite code may not ship for months.

Customer promises make this worse. If the team already told paying users that reporting, onboarding, or API fixes will land this quarter, the calendar is already full. A rewrite does not pause those promises. It adds a second deadline on top of the first.

Good mentor advice stays tied to the team's actual constraints:

• Who keeps support moving while the rebuild happens?
• Which promised fixes can wait, and which cannot?
• What ships sooner: a narrow repair or a clean rebuild?
• What breaks if the team spends eight weeks on internals?

Bad rewrite advice is usually abstract. Startups fail for concrete reasons: not enough people, not enough time, and customers who won't wait.

Quick check before you say rewrite

A rewrite should clear four checks. If one answer is vague, the mentor should pause. Most bad rewrite advice starts when people react to messy code before they look at time, money, and customer impact.

Use a short yes-or-no test:

• Can the team describe the exact problem in one sentence? "Deploys fail because the current app cannot separate customer data" is clear. "The codebase is terrible" is not.
• Can the founders say what the rewrite costs in runway, in months? A real answer sounds like "four months of burn, plus one month of slower sales work," not "probably a quarter."
• Can customers tolerate the delay? If not, does the team have a bridge plan such as a limited patch, manual support, or a partial release?
• Did the team rule out a smaller fix that removes the biggest risk? If a narrow change solves the blocker, a full rewrite is usually the wrong call.

The first question matters more than it looks. Teams often mix three different problems into one complaint: slow development, unstable production, and a weak product idea. A rewrite helps only one of those, and sometimes none.

Runway is where mentors often get too casual. Losing five months is not an abstract tradeoff for a six-person startup. It can mean one less sales cycle, one missed fundraise window, or two engineers gone before launch.

Customer pressure changes the answer quickly. If ten active customers need bug fixes every week, pausing delivery for a clean rebuild can damage trust. If customers mostly want one missing workflow and the current stack blocks it, the case gets stronger.

A good mentor should push for one final sentence before giving advice: "We are rewriting because this specific risk cannot be removed with a smaller fix, and we can afford the delay." If the team cannot say that plainly, they are not ready for a rewrite.

Next steps when the picture stays unclear

When the answer is still fuzzy, stop debating the codebase and run a one-hour review. Put the founder, the lead engineer, and the mentor in the same room. These questions work better in one focused conversation than in a week of scattered opinions.

Keep the review narrow. Ask what breaks if the team changes nothing for the next 90 days. Ask what customers feel now, what the team can ship this month, and how much cash the company can spend while it fixes the problem.

Then compare only three paths:

• Patch the current product and remove the worst bottlenecks.
• Rebuild one risky part while the rest of the product keeps running.
• Start a full rewrite only if the current product blocks sales, support, or compliance.

Do not treat those options as equal. Most small teams should pick the smallest move that protects revenue and keeps learning going. Messy code can stay alive for a while. Lost customers and burned months hurt much more.

A simple case makes this clear. A startup with four engineers, six months of runway, and two live pilots rarely needs a clean slate. It may need a faster signup flow, fewer outages, or one painful module replaced first. That's less exciting than a rewrite, but it gives the team time to learn what customers actually need.

If the room still can't tell code pain from business risk, an outside view helps. Oleg Sotnikov at oleg.is does this kind of fractional CTO and startup advisory work, and a short consultation can help sort product pressure, team limits, and delivery risk before a company commits to a full rebuild. The goal is simple: make the next move small, useful, and hard to regret.