A founder calls us. They have a product, real revenue, and an inherited codebase written by a developer who is no longer reachable. The product works. The code is held together by tape. Onboarding a new engineer takes six weeks. Every deploy is a small adventure.

The question is always the same: "Should we rewrite this or fix it?"

There is no universal answer. There is, however, a framework that gets us to the right answer in about a day of review.

We recommend a full rewrite when at least two of these are true:

1. The data model is structurally wrong. Not "a few columns are awkward"—structurally wrong. The kind of wrong where you can't add the new product line without a multi-month migration. We've seen single-tenant schemas that need to be multi-tenant, document stores that should have been relational, and event-sourced systems that nobody on the team actually understands.

2. The team can't safely change the code. This is the canary. If even senior engineers refuse to touch a particular module because nobody knows what will break, the cost of every future feature in that area is multiplied. You're already paying a rewrite tax, just slowly and without the upside.

3. The framework or runtime is end-of-life. A Rails 4 app, an Angular 1 app, a PHP 5 codebase. These are not rewriting because of style; they're rewriting because security updates are not coming and skilled hires don't exist.

If two or more of these apply, the rewrite is cheaper than the alternative. We've sat with founders who white-knuckled the "we can refactor our way out" position for eighteen months before accepting the math.

The opposite case is much more common than founders expect:

1. The product works and customers are happy. A working product with technical debt is worth far more than a half-finished rewrite. Most rewrites we've watched from the outside took 18 months and lost the company at least one full release cycle of revenue.

2. The pain is concentrated in 20% of the code. If you can name the three files where 80% of the bugs live, you can rewrite those files specifically. This is called the strangler-fig pattern and it is the right answer far more often than people admit.

3. The team understands the existing system. Tribal knowledge has enormous value. A rewrite throws away every hard-won lesson the existing code encodes, including ones the team doesn't realize they've internalized.

For about 70% of the inherited-codebase work we do, the answer is neither pure rewrite nor pure refactor. It's a quiet, incremental replacement:

• New features get built behind a clean module boundary with modern tooling
• Old code stays untouched as long as it's working
• When old code needs to change anyway, we replace it instead of patching it
• Within 6–12 months the new code is the majority and the old code can be retired

This is slower than a rewrite to announce but faster than a rewrite to actually ship. It also doesn't gamble the entire company on a long migration.

A client came to us last year with a five-year-old Rails monolith powering a marketplace doing real revenue. They wanted to "modernize." The pressure to rewrite from scratch was strong—their team had been hearing the word "rewrite" in standups for over a year.

We spent three days reviewing the code. The verdict:

• The data model was sound. No structural problem.
• The Rails version was current. No end-of-life pressure.
• The team understood the code but was scared of one particular service—the billing engine, which had grown into a 12,000-line file.

We recommended: do not rewrite the platform. Rewrite the billing engine, behind a feature flag, over the next eight weeks. Leave everything else alone.

Eight weeks later, the billing engine was a small, well-tested module with a clean API. The team's morale recovered because the scariest part of the codebase was no longer scary. The platform shipped twelve new features in the following quarter, all of them previously blocked by the billing engine's complexity.

A full rewrite would have shipped zero features in those eight weeks, taken at least a year to complete, and risked the company's relationship with every customer mid-migration.

The assessment itself is a fixed-fee engagement: three days, a written report, and a 90-minute presentation to the founder and CTO. We are not incentivized to recommend a rewrite. We are incentivized to be right, because half our work comes from referrals from previous assessments.

The recommendation is honest. Sometimes it's "you need a full rewrite, here's what that looks like." Sometimes it's "don't change anything, your code is better than you think." Most of the time, it's somewhere in between.

The goal is the smallest change that solves the actual problem.