Every debt item scored by monthly business cost. A parallel-track execution plan that keeps features shipping while the backlog shrinks. Fractional CTO retainer.
- Audit
- Architect
- Scale
monthly retainer
Who this is for
You're a CTO or VPE at a 10-50 person scaleup. Velocity has been declining for two or three quarters. Every new feature fights last year's shortcuts. Your board is asking pointed questions about engineering output, and you don't have a clean answer that doesn't sound like an excuse.
The pain today
- Every new feature takes longer than the one before it
- Debt sprints get vetoed because features stop shipping
- Can't tell which debt is actually costing vs which is theoretical
- Board asks about velocity — you have no business-framed answer
- Team morale drops as shortcuts compound into real problems
The outcome you get
- Full debt audit across five categories: code, infra, data, process, people
- Business-impact score per item — monthly cost in engineer hours, incidents, and delayed revenue
- Parallel-track plan keeping 70-80% capacity on features, 20-30% on paydown
- Quarterly execution plan with owners, milestones, and progress metrics
- A board-ready framing that turns 'cleanup time' into a defensible investment
Five categories of debt, not one
Technical debt triage starts with a taxonomy most teams skip. Code debt is the visible kind: coupling, duplication, low test coverage, outdated patterns. Infrastructure debt is the quiet one: stale deploy pipeline, missing observability, cloud architecture that made sense in 2021. Data debt compounds silently: schema decay, missing indexes, inconsistent models that make every new feature a negotiation with the database. Process debt is underrated: no code review norms, ad hoc deployment, no incident postmortems. People debt is the most expensive and least discussed: knowledge silos, tenure gaps, no hiring ladder.
Most teams diagnose only code debt because it shows up in PRs. Process and people debt tend to cost more over a 12-month horizon. I audit all five categories in the first two weeks and let the business-impact scoring — not engineering opinion — reveal where compounding is actually happening.
Full debt audit across five categories: code, infra, data, process, people
Business-impact scoring: cost, not criticism
The scoring step is what separates a triage from a grievance list. For each debt item I estimate monthly business cost across four dimensions: engineer hours lost per month, incidents caused, features delayed or blocked, and revenue or compliance risk. High-cost items get priority regardless of how technically easy they are to fix. Low-cost items get deferred regardless of how much the team dislikes them.
The estimates don't need to be exact. Within 30% is enough to force honest ordering. The more important outcome is the framing shift. Boards understand 'this specific bug pattern costs roughly 40 engineer hours a month' far better than 'we need to address technical debt accumulation.' When debt is expressed as a monthly business cost, the conversation changes from 'engineering wants cleanup time' to 'here's what we're paying to carry this.'
The 80/20 principle holds reliably: roughly 80% of the real cost comes from 20% of the backlog. Finding that 20% is the primary output of the audit.
3s → 300ms: API response time.
Parallel-track execution: features don't stop
Debt sprints fail for a predictable reason: the business sees features stop shipping and pushes back. Parallel-track solves this by treating debt paydown as a permanent allocation, not a campaign. I structure it as 70-80% of engineering capacity on product features and 20-30% dedicated to debt work, tracked separately in every sprint report.
Debt work follows the business-impact priority list, not the team's aesthetic preferences. Quarterly reviews show both streams: features shipped and debt paid down, with a resulting velocity trend. When both lines are visible in the same report, stakeholders stop treating debt work as lost capacity and start treating it as infrastructure investment.
Teams without parallel-track tend to oscillate between pure-feature sprints and emergency 'we have to fix this now' sprints. The oscillation produces worse velocity than a steady allocation. I set up the cadence in the first month and hand full ownership to engineering leadership after two to three months.
What the Cuez engagement looked like in practice
Cuez is a SaaS platform for broadcast and live events. When I joined the engineering team, the core API was running at three seconds per call. The team knew it was slow. What they didn't know was which components were responsible and whether the fix was targeted optimization or a structural rebuild.
Parallel-track approach: feature work kept shipping while targeted profiling identified the specific bottlenecks. No debt sprint, no feature freeze. The core API came down from three seconds to 300ms — 10x faster — with roughly a 40% reduction in infrastructure cost. The triage thinking scales to different severity levels: from 'fix the three hot spots eating velocity' to 'rebuild with a dual-run migration.' The method is the same. The scope of the fix is what changes.
Security and compliance debt: the category that jumps the queue
Every scoring framework has an override: security and compliance debt moves to P0 regardless of its business-impact score on velocity alone. An exposed authentication flow or a missing audit trail can surface during a Series A due diligence review or a SOC 2 audit preparation. Those situations compress timelines in ways that make velocity problems look minor.
I flag security and compliance items separately in the audit output and give them their own resolution track. They don't compete with velocity-driven debt for the 20-30% parallel-track allocation. They get addressed on their own timeline, often before the broader paydown plan starts.
This matters most for scaleups approaching their first major fundraise or enterprise sales cycle. Investors and enterprise procurement teams have become more systematic about technical due diligence. A clean audit trail on security debt is worth having before anyone asks for it.
The 'monster' problem: P0 or P3?
Every codebase has one area nobody wants to touch. It's complex, load-bearing, poorly understood, and has accumulated years of tribal knowledge. Teams often treat it as P0 by default because it's intimidating, not because it's costing that much.
Business-impact scoring forces an honest assessment. Sometimes the monster is genuinely P0 — it causes incidents, blocks features, and generates a measurable monthly cost. In that case, the execution plan tackles it deliberately with extra review, testing coverage, and rollback planning. Sometimes it scores P3 in business terms, despite being the most emotionally charged item in every retro. In that case, it stays untouched. Engineering opinion deferred to business scoring makes the call defensible to leadership and takes the personality out of the decision.
I've seen both outcomes. The value isn't in which call gets made. It's in having a framework that makes the call visible and revisable as the business changes.
Recent proof
A comparable engagement, delivered and documented.
Rescued a slow API that was blocking user growth
Cuez is a live broadcast production tool used by TV teams on air across Europe. I inherited a backend API averaging 3 seconds per response and cut it to 300ms, while reducing infrastructure costs by 40% and leaving the system stable under real production load.
Read the case studyKeep reading
Frequently asked questions
The questions prospects ask before they book.
I triangulate three data sources: where engineers say they lose hours each month, which systems caused incidents in the past two quarters, and which features took significantly longer than estimated. That combination surfaces real cost centers rather than theoretical complaints. Exact numbers don't matter much — within 30% is enough to force honest ordering. The items that show up in all three sources are almost always the high-priority ones.
Yes, that's the core of the parallel-track method. I allocate 70-80% of capacity to feature work and 20-30% to debt paydown, tracked separately. Both streams appear in the quarterly review, so stakeholders see feature shipping and debt progress side by side. Debt sprints fail because they make the trade-off invisible until features stop. A steady allocation makes it legible from the start.
Frame it as a monthly business cost, not an engineering preference. 'This authentication service generates roughly three incidents a quarter and costs an estimated 20 engineer hours a month to work around' lands differently than 'we have legacy code.' Business-impact scoring produces the numbers needed to make that case. Most boards will approve a remediation budget when the carrying cost is expressed in time and revenue terms.
The initial audit and scoring typically takes two to three weeks: one week of interviews, incident review, and codebase survey; one week of scoring and prioritization; and a final week to build the parallel-track execution plan. The audit deliverable is a scored backlog, a priority matrix, and a 90-day paydown plan. Ongoing execution support continues through the retainer.
Team input feeds the scoring, and disagreement is usually productive — different tenure levels surface different cost centers that senior engineers have normalized. The final priority list is explicit and business-grounded, so the team can disagree with a specific call while accepting the framework. I make the scoring assumptions visible so they can be challenged with data, not just opinion.
Three metrics tracked quarterly: velocity trend (features shipped per sprint over rolling six months), incident rate (P0/P1 incidents per month), and net debt movement (items resolved vs new debt accrued). Most successful engagements show a measurable velocity improvement within two quarters. Engineer satisfaction scores are worth tracking qualitatively alongside the hard metrics.
Security and compliance items get flagged separately and moved to their own resolution track. They don't compete with velocity-driven debt for the parallel-track allocation. A missing audit trail or exposed authentication flow gets addressed before the broader paydown plan starts, not scored against velocity items. This matters especially for teams approaching a fundraise or first enterprise sales cycle.