How Can You Tell If Technical Debt Is Putting Your Business at Risk?

An Australian coaching platform came to us with software that was already live and already in daily use. Coaches were onboarding clients. Clients were sitting assessments. Reports were meant to come out the other end.

Some of them didn’t. Answers weren’t always saving the way they should have. Reports didn’t reliably trigger when an assessment was finished. The access controls deciding which coach could see which client’s data needed shoring up, which is not something you want to discover in a system holding psychological diagnostic results.

None of it was sabotage. The code had been inherited, written by someone else under pressure, and nobody had been given the room to go back and tidy it. The business didn’t have a staffing problem. It had a balance sheet problem living inside its software, and it couldn’t stop trading while that problem got fixed.

That last part is what most founders underestimate. You don’t get to pause.

‍Some Debt Is Fine. Say So Out Loud.

Every codebase carries debt, and a fair chunk of it was borrowed on purpose. Hard-coding your pricing tiers so you can test demand next month is a reasonable trade. You’re borrowing against future engineering capacity, which is no stranger than borrowing against future revenue.

Trouble starts when nobody wrote down what was borrowed.

So, the question isn’t whether your code is clean. Nobody’s code is clean. The question is whether your software has started answering business questions on your behalf.

Signal 1 — Your Estimates Have Gone Weird

Ask for something tiny. Change the wording on a confirmation email.

If you get a pause, a “let me check something,” then a two-week number; the email is not the issue. The issue is that the email template sits inside a file that also handles refunds, and nobody is sure what else is in there.

Keep a note for one month. What you asked for, what you were quoted, what it took. Teams with manageable debt land inside their estimates most of the time. Teams fighting their codebase miss in a specific pattern: small jobs balloon while large jobs come in roughly right, because the large ones were padded out of fear.

That pattern is the tell. Not the size of the numbers. The shape of the misses.

Signal 2 — One Part of the Product Keeps Breaking

Bugs are fine. Clusters are not.

Export your last six months of incidents and sort them by the area of the product they hit. An even spread means normal wear. A third of them landing in one module means that module is trying to tell you something, and every fix so far has been applied near the problem rather than at it.

Uptime Institute’s analysis puts configuration and change management failures behind 62% of major IT and software-related outages, and in its survey work more than half of respondents said their most recent significant outage cost over US$100,000 (Uptime Institute Annual Outage Analysis).

For an SME, the damage rarely arrives as one memorable number. It arrives as a support queue that needs another hire, a churned account nobody can name, and a sales team that has quietly learned to steer demos away from certain screens.

On the coaching platform, the cluster sat in the assessment and reporting flow. Our first move wasn’t to fix anything. It was a full audit of the codebase, architecture and hosting, so the high-impact bugs could be ranked before anyone touched a line. Stabilise the critical paths, harden the reporting logic, and then enhance. In that order, with the platform live throughout.

Signal 3 — Nobody Can Tell You What Your Software Is Made Of

Ask your technical lead one question: which third-party libraries are we running, which versions, and when was each last updated?

A day to answer is fine. A week means you’re carrying an exposure you can’t size.

Application security vulnerabilities almost never arrive through exotic attacks on bespoke code. They arrive through known holes in components half the internet uses, left unpatched because updating them felt riskier than leaving them alone.

Verizon’s 2025 report, drawn from more than 22,000 incidents, found exploitation of vulnerabilities as an initial access route grew 34% in a year and now accounts for 20% of breaches. Only around 54% of edge and VPN vulnerabilities were fully remediated, with a median of 32 days to patch (Verizon DBIR).

Australian businesses wear an extra consequence. Under the Notifiable Data Breaches scheme, an eligible breach means notifying affected individuals and the regulator. The OAIC logged 532 notifications between January and June 2025, with malicious or criminal attacks behind 59% of them (OAIC Notifiable Data Breaches publications).

Weigh that against the cost of a quarterly dependency update. It isn’t close.

Worth reading alongside this: our piece on the hidden risk of letting AI write your startup’s codebase, since generated code has a habit of dragging in dependencies nobody chose on purpose.

Signal 4 — Do This Bit of Arithmetic

Take your last four quarters of engineering cost. Split it into two piles: money that produced something a customer can see, and money that kept the lights on.

In a healthy product, the second pile stays flat or shrinks, because the team keeps getting better at the system. Three consecutive quarters of it growing means you’re paying more each quarter to stand still.

Check the cloud bill while you’re in there. If hosting is climbing faster than active users, somebody is solving inefficient queries with bigger servers. That works. Briefly. It is also one of the most expensive ways ever invented to postpone a refactor.

Signal 5 — Listen to Your Own Planning Meetings

“Let’s not touch that this quarter.”

“We’ll do the simple version for now.”

“That’s a phase two thing.”

Said once, that’s discipline. Said every quarter about the same three areas, it means the code has pulled up a chair at your strategy table and started voting.

One question settles it. If a competitor shipped this feature next month, could you respond inside six weeks? When the honest answer is no, and the blocker is the codebase rather than money or headcount, you’ve stopped choosing your roadmap. Our breakdown of how poor architecture creates long-term business risks covers where that road ends.

Score Your Own Risk in Ten Minutes

Be honest. Nobody’s grading this.

0 to 4: Manageable. Hold a repayment allowance in each sprint and move on.
5 to 9: Material risk. Get an independent assessment before your next raise or major release.
10 and up: Your software is constraining the business right now. This is a commercial issue wearing a technical costume.  

‍

‍

What a Proper Code Quality Assessment Covers

Automated scanners are useful and limited. They’ll flag style issues and known vulnerable packages. They will not tell you that your pricing logic is duplicated across four files, or that one person is the only human alive who understands your reconciliation job.

A review worth reading looks at five things:

Architecture and coupling. Can one area change without triggering a full regression cycle?

Dependency and security posture. Full inventory, versions, known vulnerabilities, licence obligations. This is the section that saves you during due diligence.

Tests where they count. Not a coverage percentage. Whether the paths that move money or hold customer data are covered at all.

Operational readiness. Logging, monitoring, alerting, backup, restore. Can you tell within minutes that something broke, and get back?

Knowledge concentration. Which parts of your business depend on one person staying employed and reachable.

The 12-Point Technical Debt Risk Checklist

Tick what’s true today. Four or more, book the review.

☐  A change you’d call small routinely takes more than a week
☐  The same area has broken more than three times in six months
☐  Nobody can produce a current library and version list within a day
☐  Core frameworks are two or more major versions behind
☐  Releases regularly need a same-week hotfix
☐  Critical flows have no automated tests
☐  One developer is the only person who understands a revenue-critical area
☐  Cloud costs are rising faster than active users
☐  A new developer needs more than a month to ship anything meaningful
☐ Your team has asked you not to touch a particular module
☐ Maintenance work eats more than half the engineering budget
☐ You’ve declined or delayed a customer request because of the codebase

Your Next 30 Days

Week one, measure. Run the table with your technical lead. Pull the incident list and the dependency inventory. Fix nothing yet.

Week two, price it. Translate the top three problems out of engineering and into English. Not “the order service is tightly coupled.” Try “changes to checkout cost us three weeks each, which killed two releases last quarter.”

Week three, allocate. Teams that stay ahead of this reserve 15 to 20% of every sprint for repayment and defend it like a loan repayment, because that’s what it is. Sequence by business impact. The admin screen nobody opens can wait. Checkout cannot.

Week four, get an outside read. If you’re planning new work on top of shaky ground, it’s worth building the next release on a foundation designed to carry the weight instead of extending what’s already there. An outside team can also work on a system that can’t be taken offline, which is how most rescues run: audit first, stabilise the paths that matter, enhance once the ground is solid. When deadlines keep slipping and the code feels too fragile to touch, bringing in a team that specialises in turning stalled builds around costs a fraction of what a rebuild will cost you twelve months from now.

Where This Leaves You

Nobody gets a prize for immaculate code. The businesses that stay ahead of this know their number, revisit it quarterly, and pay it down deliberately rather than waiting for the quarter where it pays itself down by force.

Our breakdown of the seven ways technical debt drains a development budget puts dollar figures against each signal above if you want to take the case further.

Measure it while it’s still a decision and not an incident.

‍

‍