Build the Business Case

A step-by-step framework, language translation guide, and objection-handling playbook for presenting technical debt to non-technical stakeholders — and getting a yes.

5-step framework Free reference Board-ready template

The 5-step framework

01
Quantify the cost

Convert the abstract ("our codebase is a mess") into a specific annual dollar figure ("$1.2 million per year in lost productivity"). Use the Cost Calculator to get there.

02
Model the growth

Project the 5-year compound cost if nothing changes. Unaddressed debt doesn't stay flat — it compounds as workarounds accumulate.

03
Estimate the investment

Define concrete resource requirements — "3 engineers for 2 months," not "some refactoring time." Specificity builds credibility.

04
Calculate the payback

Determine the number of months until the investment pays for itself. The ROI Calculator models this directly.

05
Frame it as risk

Reposition the narrative from "refactoring" to "delivery-risk reduction." Executives fund risk mitigation more readily than code cleanup.

Language translation guide

The same fact lands very differently depending on the words used. Translate before you present.

AvoidUse instead
"Refactoring""Engineering efficiency investment"
"Technical debt""Delivery risk"
"The code is bad""Velocity declining 5% quarterly, $X impact"
"We need to rewrite the codebase""A phased modernization roadmap"
"We're slow because of tech debt""Delivery-risk exposure of $X per quarter"

One-page template

Slide-ready format — swap in your own numbers from the Cost Calculator and ROI Calculator.

// Technical Delivery Risk Reduction
Current annual cost$[X]
5-year projected cost (unaddressed)$[X]
Proposed investment$[X]
Payback period[X] months

Objection handling

"We can't afford to pause feature development."

Teams already spend roughly 33% of their time on debt-related work (Stripe Developer Coefficient). Addressing debt frees more capacity than the initiative consumes — it's not a pause, it's a reallocation.

"How do we know this will actually work?"

Reference DORA metric benchmarks and commit to specific, measurable success targets up front (see the Success Metrics table below) — then report against them monthly.

"Why not just hire more engineers?"

Hiring adds capacity without addressing the root cause — the debt keeps compounding under the larger team too. Run the cost comparison in the ROI Calculator.

"This is an engineering problem, not a business one."

Connect the technical issue directly to revenue, retention, and outage cost — the same categories the Cost Calculator breaks out. Debt is a business problem wearing a technical disguise.

"What's the timeline, and how do we measure it?"

Outline a phased approach with monthly tracking against the DORA dashboard — deployment frequency, lead time, change failure rate, and MTTR (see the Metrics Guide).

Success metrics (6-month targets)

MetricTarget change
Deployment frequency+40%
Lead time for changes−30%
Incident rate−25%
Velocity trendStabilized

FAQ

What's the single most important number for a CFO?

Payback period. It converts a technical initiative into the same unit CFOs already use to evaluate every other capital request — months to break-even.

How do I translate this for a non-technical audience?

Lead with the dollar figure and the risk framing, not the technical detail. Save the "why" (complexity, coupling, coverage) for follow-up questions — most executives won't ask, and the ones who do will appreciate the depth being available rather than front-loaded.

// Ready to present?

Get the numbers behind your business case.

Run the Cost Calculator and ROI Calculator to populate the template above with your own figures — or talk it through directly.