Technical Debt Due Diligence: How to Challenge a Remediation Estimate

1. Separate acquired risk from optional improvement

A code scanner can identify potential issues. It cannot establish which work the buyer must fund, how long that work will take, or whether an acquisition makes sense. A large backlog may mix security exposures, unsupported components, inconvenient design choices, cosmetic cleanup, and features the buyer does not actually need.

Start by relating each material item to the intended operating plan. Is the buyer keeping the product as it is, changing its business model, transferring operations from the founder, or expanding its workload? A structural limitation can be tolerable under one plan and a near-term constraint under another.

• Required for continuity or a confirmed control weakness: identify the affected workflow, supporting evidence, and conditions that make action necessary.
• Required for the buyer’s plan: state the planned change that creates the need. Do not present an optional expansion as an unavoidable repair.
• Improvement that can wait: record why deferral is reasonable, who accepts the trade-off, and what would trigger reconsideration.
• Unresolved exposure: request the missing evidence or a bounded investigation. Absence of proof is not a confirmed failure, but it is not a pass either.

2. Require an evidence trail before a price tag

For a material finding, request the reviewed revision and environment, the observed condition, the affected business process, and the limits of the check. A maintenance concern should explain why a likely change is difficult; a recovery concern should identify which recovery claim lacks evidence. Labels such as “legacy architecture” are not an estimating basis.

For example, an unsupported dependency may require a configuration change, a replacement library, or a broader integration redesign. Until compatibility and usage are understood, a fixed implementation estimate hides the most important uncertainty. Scope a discovery step and identify the decision it must resolve.

3. Estimate an outcome, not a vague refactor

“Improve maintainability” is not a bounded engineering task. An estimate should describe the target behavior, the systems and workflows in scope, the work needed to change them, and evidence that the result works. It should distinguish repair from redesign and explain why the chosen approach is proportionate.

Ask where investigation, implementation, regression checks, migration, release coordination, and operating validation appear in the plan. They need not be separate tickets, but they must be accounted for or explicitly excluded. Removing an implementation defect without protecting the behavior from regression may leave part of the intended outcome unfinished.

• Completion evidence: identify the checks, deployment records, reconciliation results, or runbook demonstration required for acceptance.
• Dependencies: name required access, target-team availability, provider changes, specialist review, and related work that must finish first.
• Shared work: allocate a common test harness, upgrade, or migration once. Do not charge its full effort to every finding.
• Alternatives: state whether containment, a targeted repair, or a staged replacement could meet the buyer’s need with different trade-offs.

4. Check the arithmetic without mistaking it for evidence

Fictional illustration only — the following tasks, effort ranges, and rate are invented to explain an estimate. They are not a client result, supplier quote, market rate, or recommendation for a real system.

Suppose a narrowly defined change is allocated 6–10 engineering days for implementation, 3–5 for regression and integration checks, and 1–2 for release and verification. If these are non-overlapping activities performed by one engineering role, the arithmetic range is 10–17 person-days. At an assumed cost of €800 per person-day, the corresponding direct labor scenario is €8,000–13,600.

This calculation does not establish that the tasks are sufficient or that either bound is likely. It is not a statistical confidence interval. It also does not provide a calendar delivery date. If independent review, discovery, licensing, customer migration, specialist work, or ongoing infrastructure costs are excluded, list them beside the number rather than burying them in a footnote.

For a real estimate, use the actual proposed staffing and cost basis. Internal salary cost, a contractor day rate, and a supplier fixed fee are different measures. Do not combine them under one ambiguous “remediation cost” label. The assessment fee is also separate from the engineering cost of implementing its recommendations.

5. Ask which assumption could move the range

The most useful uncertainty discussion names a plausible change in scope or execution. A dependency upgrade might remain local if compatibility checks pass, but expand if a critical integration needs replacement. A range that silently combines those two outcomes is difficult to use in an investment discussion.

Separate the base work from conditional work and unresolved discovery. Record the evidence that determines which scenario applies, who can obtain it, and when the buyer needs the answer. If the unknown cannot be bounded responsibly, say so and estimate the investigation rather than inventing an upper limit.

The GAO Cost Estimating and Assessment Guide describes the importance of a technical baseline, work breakdown, assumptions, sensitivity, and risk analysis. Its context is program cost estimating, not a software acquisition price list. Here those principles inform questions for a scoped engineering estimate; referencing the guide does not make the estimate independently validated.

• Challenge exclusions: what necessary work is outside the displayed total?
• Challenge dependencies: what happens if a required person, access right, or provider decision is unavailable?
• Challenge the contingency: which uncertainty does the allowance address, and has the same risk already been included elsewhere?
• Challenge precision: is a narrow range supported by investigation, or merely by a detailed-looking spreadsheet?

6. Keep effort, staffing, and elapsed time separate

Ten person-days do not automatically mean two calendar weeks, and two engineers do not automatically halve the duration. Review capacity, sequencing, access windows, release constraints, and work that cannot run in parallel affect the schedule. The target team may also be supporting customers and continuing product delivery.

Ask which work uses existing capacity, which needs additional people, and what will be deferred. If an acquisition plan assumes both rapid feature growth and substantial stabilization by the same small team, the capacity conflict should be visible. Do not convert displaced roadmap work into a quantified revenue loss without separate supporting evidence.

Where additional specialist work is needed, confirm its scope and availability before relying on it in a delivery plan. A proposed staffing model is an assumption until the relevant people and access are available.

7. Turn the estimate into acquisition and 90-day decisions

Use findings and estimate confidence to distinguish information needed before a decision, transition conditions, prioritized stabilization, and improvements that can wait. A high-cost item is not automatically urgent; a small unresolved ownership or access dependency may matter sooner. Priority should reflect consequence, timing, and the buyer’s plan.

For each first 90-day priority, identify an accountable role, dependencies, acceptance evidence, and the date or event for reviewing the estimate. This is a sequence of proposed outcomes, not a promise that every issue can be closed within 90 days.

AWS DevOps Guidance recommends reviewing documented practices and operating evidence and treating gaps as technical debt and potential risks within an internal risk-management process. It does not supply a remediation price or require every gap to be fixed immediately. The buyer still needs a scope-specific judgment about which actions matter.

• Before the decision: resolve an uncertainty that could change the investment assumption, or make the remaining uncertainty explicit.
• At handover: establish the authorized access, operating knowledge, and responsibilities needed for continuity.
• After closing: implement the agreed priorities and collect completion evidence; update estimates as discovery and actual work replace assumptions.
• Defer consciously: record the residual risk and review trigger for work the buyer chooses not to fund now.

8. Questions to take into the findings briefing

Ask the reviewer to walk one material finding from evidence to business implication, completion criteria, effort, cost basis, and uncertainty. Then ask what would change the estimate. A report should make that chain easier to inspect rather than ask the investment team to trust a single aggregate number.

Useful follow-up questions are: Which items are required under our actual plan? Which ranges depend on unverified access or compatibility? Where is shared work counted? What would we learn from a short discovery step? Which estimate needs specialist validation? What capacity is assumed, and which costs remain outside the scenario?

A technical assessment can inform engineering priorities and budget scenarios where evidence supports them. It does not establish valuation, contractual protection, a supplier commitment, or whether the buyer should complete the transaction. The clearly fictional Shedko Advisory sample report illustrates evidence boundaries and effort assumptions; a real engagement requires its own authorized scope and inputs.