How to Scope a Code Remediation Project Without Guessing

Last updated October 2026

To scope a code remediation project without guessing, run a timeboxed audit first, turn every finding into a line item with a pass/fail “done when” test, size each item into a small set of buckets, and quote a range that narrows as decisions are made. Scanner debt totals measure fix minutes, not the verification, data, and architecture work driving cost.

Key takeaways

A remediation estimate made before anyone has read the code is a guess with a number attached. Construx’s research on the Cone of Uncertainty puts early estimates anywhere from 0.25x to 4x of the final result.
Static analysis totals, such as SonarQube’s technical debt figure, add up per-issue fix minutes for maintainability issues. They leave out characterization tests, data repair, deployment work, and anything architectural.
The unit of scope is a finding with a test, not a file, a module, or a sprint. If an item cannot be tested as done, it is not scoped yet.
Quote remediation as a range with named assumptions, and commit to narrowing it at fixed checkpoints. That is what makes a fixed price on the later phases safe for both sides.

Why do code remediation estimates go wrong?

Most remediation quotes fail for the same reason most software estimates fail: the number is produced before the decisions that determine it. Steve McConnell’s Cone of Uncertainty white paper at Construx shows estimates at the initial concept stage ranging from 0.25x to 4x of actual effort, a 16x spread, narrowing through 2x, 1.5x, and 1.25x as the project definition firms up. The paper’s central line applies directly to remediation: “The Cone narrows only as you make decisions that eliminate variability.”

Remediation has its own version of those decisions. Is the payments module being fixed or replaced? Does the data already in production need repair, or only the code that writes it? Is the target “safe to keep selling” or “ready for a due diligence review”? Until those are answered, any single number is a coin toss.

The stakes grow with size. A McKinsey study with the University of Oxford of more than 5,400 IT projects found that large projects, those with initial budgets above $15 million, ran 45 percent over budget on average and delivered 56 percent less value than predicted. Remediation projects are usually far smaller, but the mechanism is the same: scope was committed before it was understood.

What does a scanner’s remediation estimate actually measure?

Teams often reach for a static analysis total as a shortcut. It is useful, but read the definition first. SonarQube’s metric documentation defines technical debt as “the sum of the maintainability issue remediation costs,” where each issue’s cost is “the effort (in minutes) evaluated to fix the issue.” Its debt ratio divides that total by an assumed cost to develop each line of code, 30 minutes by default.

That gives you a consistent signal for comparing codebases or tracking a trend. It does not give you a project scope, because the expensive parts of remediation are not code smells:

Verification. Before you change behavior you have to pin it down. Writing characterization tests around untested code often costs more than the fix itself.
Authorization and data exposure. A missing access check is one line to fix and days to prove fixed across every endpoint.
Data repair. If bad code has been writing bad records, the remediation includes finding and correcting them, which no scanner sees.
Architecture. Duplicated business rules, tangled modules, and a schema nobody versioned show up as many small issues or none at all.
Delivery plumbing. Environments, migrations, CI, and rollback are scope, and AI-built prototypes usually have none of them.

Use the scanner output as one input to the audit. Never paste its total into a proposal.

How do you scope a code remediation project in five steps?

Timebox the discovery. Fix the audit’s length and price up front, and fix what it produces: a findings register, a risk ranking, and a range estimate. Our walkthrough of how to audit an AI-generated codebase in 10 days lays out a workable sequence.
Write every finding as a line item with a “done when” test. “Improve auth” is not a line item. “A user logged in as account A gets a 403 or 404 on every account B resource” is. The test is what makes the item estimable and, later, what proves it was delivered.
Size each item into buckets, not hours. Bucketing is faster and more honest than false precision. Any item too big for the largest bucket gets split until it fits.
Tag every item with the decision it depends on. “Assumes we fix the existing billing module rather than replace it.” When the decision is made, the item either firms up or moves out of scope.
Price in phases. Commit firmly to the stop-ship tier, which is small and well understood after the audit. Quote the rest as a range that narrows at a named checkpoint, typically after the first tier ships and the characterization tests exist.

What does a scoped remediation line item look like?

A findings register works when every row answers the same five questions. Here is the structure we use, with illustrative rows:

Field	What it records	Example
Finding	The defect, stated as observed behavior	Order totals are computed in the browser and accepted by the API
Tier	Stop-ship, fix this sprint, or before scaling	Stop-ship
Done when	A pass/fail test anyone can rerun	An API request with an altered total is rejected and logged
Size bucket	S (under 1 day), M (1 to 3 days), L (3 to 10 days), or split	M
Depends on	The decision or unknown that could move the estimate	Whether discount rules move server-side in the same change

The bucket boundaries are a convention, not a law. What matters is that they are few, that they are agreed before sizing starts, and that nothing larger than the top bucket survives into the plan. A ten-day item is a project of its own and needs its own breakdown.

How wide should a code remediation estimate be at each stage?

Map the stages of a remediation project onto the cone and state the range out loud. A useful working version:

Before anyone has read the code: do not quote remediation at all. Quote only the audit.
After the audit, before key decisions: a range for the full program, with the stop-ship tier priced firmly and each remaining tier carrying its assumptions.
After the stop-ship tier ships: characterization tests now exist around the riskiest paths, the fix-or-replace calls have been made, and the remaining tiers can move to a fixed price.

This is the same logic behind gradual replacement. Martin Fowler’s Strangler Fig article argues that replacing a system piece by piece makes “both investment and returns occur gradually and visibly,” and that the team learns more about the system with each piece. Phased remediation scope buys exactly that: every checkpoint converts unknowns into decisions before the next commitment is made.

What belongs inside a code remediation project’s scope, and what does not?

Scope creep in remediation usually arrives as “while you are in there.” Draw the line in writing before work starts:

In scope: every register item and its test, the characterization tests needed to change code safely, data repair tied to a finding, and the delivery plumbing required to ship fixes (migrations, CI, rollback).
Out of scope unless added as new line items: new features, UI redesign, framework migrations that no finding requires, and performance work without a measured target.
Decided separately: whether a module is rescued or rewritten. Our rewrite or rescue decision framework covers how to make that call per module rather than for the whole codebase.

When a new problem surfaces mid-project, and one will, it goes into the register as a new row with its own test and bucket. It does not get absorbed silently into an existing item, because that is how a scoped project turns back into a guess.

Should code remediation be fixed price or time and materials?

Both, in sequence. The audit and the stop-ship tier suit a fixed price because the work is bounded and the tests define done. The later tiers start as time and materials inside a capped range, then convert to fixed price once the checkpoint narrows them. Our fixed-price vs. time and materials guide covers the contract mechanics, and the pillar guide, AI code rescue: what it is, what it costs, and when you need one, puts remediation cost in context.

Frequently asked questions

How long does it take to scope a code remediation project?

Long enough to read the code and run it, and no longer. TopDevz’s Rescue Audit is scoped to 10 business days from kickoff to executive readout. Scoping from a call or a repository glance produces a number, not a scope.

Can I use SonarQube’s technical debt figure as my remediation estimate?

No. It sums estimated fix minutes for maintainability issues. It does not include verification, authorization testing, data repair, architecture changes, or deployment work, which usually make up most of the effort.

What is a “done when” test in remediation scoping?

A pass/fail check attached to each finding that proves the fix, such as a cross-account request returning a 403. It makes the item estimable, defines delivery, and gives buyers and auditors evidence instead of a claim.

How TopDevz scopes remediation

Our $4,950 Rescue Audit is the timeboxed discovery step: senior engineers read and run your code, then return a ranked findings register with tests and size buckets. The fee is credited toward remediation if you have us do the work. Those engineers come from a pool of 15,643 vetted developers averaging more than 10 years of experience, and if the work needs an ongoing team rather than a project, Delivery Pods start at $15K per month with 30-day notice.

Book a Code Review

If you have a remediation quote that is a single number with no tests behind it, or no quote at all, get the findings first. Book a Code Review.