Your technical debt, quantified in time and money.
“Technical debt” is one of those terms everyone uses and nobody defines. The result is debates that do not resolve — engineering claims one thing, finance suspects another, and the board has no way to evaluate either.
The Assessment quantifies your technical debt in two numbers leadership can act on: the time it would take to repay and the cost. With the working that shows how the numbers were arrived at.
That is what this engagement is.
€15,000. Three to four weeks. Delivered in writing, with a board-ready summary.
Fixed fee. No implementation work. No commissions. No product recommendations influenced by suppliers.
Why clients commission an assessment
A Technical Debt Assessment is usually triggered by a specific moment. Most often, one of these:
- Engineering velocity is dropping and leadership wants to know why, in numbers.
- Budget pressure requires a credible cost-of-not-investing number for the board paper.
- A new investor or board member is asking pointed questions about technical state.
- A major project keeps slipping and the cause is contested between engineering and the rest of the business.
- Recruitment is suffering — strong candidates leave the process after seeing the codebase or the platform.
- A vendor or platform is approaching end-of-life and remediation cost is unknown.
- Scaling costs are outpacing revenue growth and the underlying cause is not understood.
- Insurance, audit, or refinancing requires documented technology risk evidence with quantified figures.
If one of these is the position you are in, the Assessment is built for it.
Who this is for
Owners, MDs, CEOs, and CFOs needing a defensible number for the board paper, the investor conversation, or the budget cycle.
Newly-appointed CTOs and engineering leaders inheriting an unknown level of debt and needing to brief their board.
Boards and investors needing evidence rather than opinion before committing to further investment or a transaction.
Operating partners preparing 100-day plans where technical debt is one of the variables that needs naming.
Who this is not for
Pre-revenue businesses or those without a meaningful production codebase.
Owners wanting remediation. We quantify; we do not repay. Remediation is a separate engagement.
Buyers wanting a full code review or static analysis. The Assessment quantifies; code review is a different engagement.
Engineering teams wanting code quality coaching or mentoring. See Mentoring instead.
What you receive
The Assessment tells you, in two numbers: how much technical debt you carry and what it would cost to address. Plus the working that shows how the numbers were arrived at. Five artefacts, delivered together.
A technical debt inventory. Every material debt item, categorised by system, by type, by age, and by business impact. Each item evidenced, not asserted.
Quantified estimates. Time to repay (in engineering effort) and cost (in euros and resource). Each estimate sourced, methodised, and defensible against challenge.
A priority ranking. What to repay first, second, third — and what to leave. Each ranking named against the risk or opportunity it addresses.
A twelve-month remediation roadmap. Sequenced across the next year, costed in engineering effort and external resource. Calibrated to your existing budget and team capacity.
A board-ready summary and presentation. A short, board-readable document — the two numbers, the implications, the recommendation. Plus a one-hour session to walk through it with whoever needs to hear it.
Typical outcomes
Most Assessments result in one of four conclusions.
The debt is manageable. Folded into normal investment. No material concern; the board has the evidence to confirm rather than worry.
Specific debt items require attention. Particular systems or platforms carry disproportionate debt. The roadmap names them and the cost to address.
A significant programme of remediation is needed. Multiple debt items across the estate warrant sequenced investment over the next year or longer.
Critical debt: repay before scaling or selling. Specific items should be addressed before any significant growth investment, transaction, or scaling event.
The Assessment tells you which of these your business is in, with the numbers to back it up.
How the Assessment runs
Three to four weeks, in four phases.
Week one — inventory. Codebase, infrastructure, vendor lifecycle data, incident records, recruitment data. Everything that informs debt estimation, in one place.
Week two — interviews. Engineering, operations, recent hires (who can see what longer-tenured staff have stopped seeing), recent leavers where reachable.
Week three — quantification and prioritisation. Time and cost estimates calibrated. Priority ranking established. Each estimate sourced and defensible.
Week four — board-paper preparation and presentation. The board-ready summary written. The presentation session, scheduled around your board cycle if needed.
Everything is written before it is said. Nothing reaches the board that has not been verified first.
What this is not
Code refactoring or implementation. We quantify; we do not repay.
Engineering coaching or team building. See Mentoring instead.
Architecture redesign. For that, see the Architecture Review.
Regulatory attestation or audit. The Assessment can inform one, but does not substitute for one.
Technical debt is not an engineering problem. It is a balance-sheet item.
The purpose of the Assessment is not to make the debt go away. It is to give leadership the two numbers that translate engineering reality into business decisions: how much debt is on the books and what it costs to repay — so investment, hiring, and exit decisions are made on figures rather than feel.
Proof
References available on request. Anonymised excerpts from prior reviews available on request.
What happens next
Start a ConversationThirty minutes. We confirm fit, scope, and timing. You decide whether to proceed. No proposal is sent unless you ask for one.
Start with the Technology Control Assessment — €4,950A scored framework reading in five working days, with architectural and engineering posture surfaced within the broader assessment. The right starting point if you want to see where technical debt sits in context before committing to a focused Assessment.
For an architectural deep-dive into the systems that carry the debt, see Architecture Review.