What is technical debt and why it is costing your business money

Every Monday morning, the office manager at a 25-person distribution company opens two windows side by side. Last week’s orders from the online store are on the left, and QuickBooks is on the right. The next three hours go to retyping one into the other. The connector that used to move orders across on its own stopped working after an update two years ago, and somebody said they’d look into it. Nobody did. By now nobody thinks of it as an IT problem. It’s just what Monday mornings are for.

Down the hall, a computer under the reception desk has a sticky note on it that says DO NOT TURN OFF. It runs a nightly export that nobody fully understands. Five people share one login to the shipping carrier’s website. And the server in the back closet runs a version of Windows that’s about to stop getting security updates. None of this shows up on an invoice. It shows up in payroll, in the occasional lost afternoon, and in risk that nobody has put a number on. That’s technical debt, and most small businesses carry more of it than they realize.

This is written for owners, finance leads, and operations managers at businesses of roughly 10 to 150 people. It covers what technical debt looks like when you don’t write software, how it builds up without anyone choosing it, how to put a rough dollar figure on it, and how to pay it down a piece at a time instead of betting on one big replacement project. It’s part of a series on technology planning that also covers the IT roadmap, the hardware refresh cycle, and the quarterly technology review.

Short answer

Technical debt is the ongoing cost of technology shortcuts and fixes that got put off. A business saves time or money by doing something the quick way, and then pays for it a little at a time for as long as the quick way stays in place. In a small business it’s rarely about code. It’s computers and servers past their service life, software that no longer gets security updates, workarounds that were meant to be temporary, and systems that only work together because someone copies data between them by hand. Nobody is assigned to track it, so it grows unnoticed. To put a number on it, compare what each item costs you every year with what it would cost to fix once. Anything with an end of support date goes first, because the date decides for you. After that, fix the items that pay for themselves within a year and fold the rest into changes you’re already making. Most small businesses can work through their debt over a year or two without one large replacement project.

Technical debt at a glance

Question	Short version
What is it?	The ongoing cost of shortcuts, put-off upgrades, and temporary fixes that stayed.
Is it only about software code?	No. In a small business it’s mostly old hardware, unsupported software, workarounds, and manual steps between systems.
Is all technical debt bad?	No. A shortcut taken on purpose, written down, with a date to revisit it, can be a sound business decision. The expensive kind is the debt nobody chose and nobody tracks.
Why doesn’t anyone notice it?	It’s paid in small amounts of staff time and risk, so it never gets its own line in the budget.
How do you measure it?	Estimate what each item costs per year to live with, and what it would cost once to fix.
What gets fixed first?	Anything with an end of support date, then anything that pays for itself within about a year.
Do you need a big replacement project?	Usually not. Most of it can be paid down in small pieces alongside changes you’ve already planned.
Who should own it?	One named person, usually whoever owns IT planning: a virtual CIO, an IT manager, or an operations lead.

What technical debt means for a small business

Ward Cunningham, a software developer, came up with the comparison in 1992. He was explaining to the managers of a financial software product why code that already worked still needed reworking as the team learned more. Shipping the first version was like borrowing money. You got the product sooner, and you paid interest until you went back and brought the code up to date with what you now knew. The comparison caught on because it makes sense to people who have never written a line of code.

Most small businesses don’t write software, but they carry the same kind of debt. It usually falls into five groups.

Aging infrastructure

Computers, servers, firewalls, switches, and wireless access points that have outlived their service life. They still work, mostly. They’re slower, they fail more often, and they’re often out of warranty, so each failure turns into an unplanned purchase. A hardware refresh cycle takes care of most of this group, and it’s the easiest kind of debt to plan around because every device has a purchase date.

Unsupported software

An operating system, application, or database that its maker no longer updates. The software keeps running, which is why it’s easy to miss, but any security flaw found after its end of support date stays open for good. A lot of common business software has crossed that line in the last year, or is about to:

Software	End of support
Windows 10	October 14, 2025, with paid extended security updates available to businesses until October 2028
Office 2016 and Office 2019 (the one-time purchase versions)	October 14, 2025
Exchange Server 2016 and 2019 (email servers kept in the office)	October 14, 2025
SQL Server 2016	July 14, 2026
Windows Server 2016	January 12, 2027
QuickBooks Desktop	Intuit ends support and connected services like payroll and bank feeds for each version on a published date, roughly three years after it comes out. The 2023 version lost them on May 31, 2026.

SQL Server is the one most owners don’t know they have. It’s the database underneath a lot of practice management, inventory, and accounting systems, and a vendor often installed it on the office server years ago without anyone thinking about it again. If one of your main business applications runs on a server in the office, ask the vendor which database it uses and which version.

The other common version of this problem is being stuck behind. The vendor supports version 12, you’re on version 9, and the upgrade means a new server first, and the new server got pushed to next year.

Workarounds that became permanent

The computer that can’t be restarted. The spreadsheet whose only job is making two systems agree. The shared login, because adding another user cost money the month it came up. The vendor account tied to a former employee’s personal email address. The scanner that only works with one old computer, so that computer stays. On the day it was made, every one of these was a sensible fix. The trouble is that nobody wrote down that it was temporary, so nobody came back to it.

Systems held together by people

Two systems that should talk to each other and don’t, so a person does the talking. Orders retyped from the web store into accounting. A weekly export from the scheduling system, cleaned up in Excel and emailed to payroll. A spreadsheet macro that calculates commissions, written by an employee who left in 2021, which breaks whenever someone moves a column. These cost staff time every week and let a steady trickle of errors through. When the person who does the work is out sick, the work simply waits.

Knowledge that lives in one person’s head

How the network is set up, which vendor account uses which password, why the backup runs at 2 a.m. instead of midnight. If it isn’t written down anywhere, it’s debt, and the bill arrives the week that person leaves. Technology due diligence treats this as key person risk, because buyers have learned how expensive it is to rebuild an environment nobody documented.

What isn’t technical debt

Old isn’t the same thing as debt. A switch that’s six years old, still getting firmware updates, and doing its job is good value, not a problem. Neither is a simple setup you chose on purpose because the business doesn’t need anything more. Debt is the gap between how something works and how it should work, plus whatever that gap costs you. If it doesn’t cost you anything, there’s nothing to pay down.

Principal and interest

Take the loan comparison literally. It turns a vague list of IT annoyances into something you can make decisions about.

The principal is what it would cost to fix the thing properly, once. Replacing the server, setting up the integration, documenting the network, buying the extra user accounts. It includes the staff time to make the change, not just the invoice.

The interest is what it costs you every year you don’t. It comes in three forms:

• Time. Hours spent on the workaround, on fixing its mistakes, and on waiting for the slow machine. This is the steady monthly payment, and it’s usually the biggest one.
• Disruption. Outages and failures the fragile thing causes. These come in lumps: nothing for months, then a lost day.
• Risk. The chance that something goes badly wrong because of it, like a breach through a system that no longer gets patched, or a claim your insurer questions. You don’t pay this one every month. You pay it all at once, if it happens.

Some debt also has a due date. When software reaches end of support, or a server’s warranty runs out and can’t be extended, the decision gets made on a date you didn’t pick. It works like a loan with a balloon payment. Ignore the date and you still make the payment, just as an emergency.

And like a business loan, some technical debt is worth carrying. Opening a second location quickly with a simple setup, knowing you’ll redo it properly in six months, is a fair trade as long as someone writes it down and comes back to it. The expensive debt is more like a credit card statement nobody has opened in a year.

How technical debt builds up without anyone deciding to take it on

Nobody sits down and decides to run the business on a computer that can’t be turned off. Debt shows up through ordinary, reasonable decisions, one at a time.

The quick fix that worked. Something broke on a busy day. Someone found a way around it, the work got done, and the fix held up well enough that there was never a reason to come back. Most permanent workarounds started on some forgettable Tuesday afternoon.

The business outgrew the setup. What works for eight people often breaks slowly at thirty. One shared login, a storage box in the closet, the consumer router from the first office. They were all right when they went in. Nobody decided to keep them as the business grew, and nobody decided to replace them either. Signs your small business has outgrown DIY IT covers how that usually plays out.

The person who built it left. The macro, the script, the integration someone set up over a weekend. It still runs. Nobody knows quite how, so nobody wants to touch it.

Upgrades got put off while the vendor moved on. An upgrade is a project, and projects compete with everything else for money and attention. Skipping one version is often fine. Skip three and you’re on a version the vendor doesn’t support, the easy upgrade path has closed, and the next step is a migration, sometimes onto a server you don’t have yet. The quarterly review treats a third deferral in a row as the point for a harder conversation: either the thing isn’t needed, or it is and keeps getting avoided.

Nobody owns the list. Day-to-day IT support fixes what’s broken today. A problem that comes back every month gets closed every month, and stepping back to notice the pattern isn’t anyone’s job.

It stays out of sight for the same reason it builds up. The interest is paid in small amounts by people who’ve stopped noticing it, so it never appears on the profit and loss statement as anything you could point to. You see it as overtime at month end, a slow week after an outage, and an IT budget that always runs a bit over without anyone being able to say exactly why.

Signs you’re carrying more than you think

Most owners can go through this list in a few minutes. Every yes is a piece of debt.

• There’s a computer, or a server, that nobody is allowed to turn off or restart.
• Someone retypes data from one system into another every day or every week.
• There’s a spreadsheet whose only job is to make two systems agree.
• Some task simply waits when one particular person is on vacation.
• More than one person signs in with the same username and password.
• You’re running software the vendor no longer updates, or you aren’t sure whether you are.
• An upgrade has been planned for “next quarter” for more than a year.
• The same IT problem comes back every few weeks.
• When you ask why something is done a certain way, the answer starts with “because the old system”.
• New hires need more than a day or two before they can do real work, because their setup is done by hand.
• You’ve answered a question on a cyber insurance application with more hope than certainty.

How to work out what technical debt is costing you

You won’t get a precise number, and you don’t need one. You need a figure good enough to rank the items against each other and against everything else the money could go to. An afternoon gets you most of the way there.

Step 1: Make the list

Ask each team one question: what do you do every week that feels like it shouldn’t be necessary? The people running the workarounds know exactly where they are, and they’ll usually tell you, as long as the question doesn’t sound like blame. Then ask your IT provider, or whoever handles IT, for three things: every device and application that’s past or near its end of support date, the problems that keep coming back as tickets, and anything that depends on a single person or a single machine. If you’ve already built an inventory for a hardware refresh or an IT roadmap, start from that.

Step 2: Put a price on the time

For each item, estimate how many hours it takes per week or per month, across everyone involved. Count the person who checks the work and the person who fixes the mistakes, not only the person doing the retyping. Multiply by a loaded hourly cost, meaning wages plus payroll taxes and benefits. A common rule of thumb is 1.25 to 1.4 times the hourly wage.

Three hours a week of retyping, at a $34 hourly wage that loads to about $45, comes to about $6,500 a year over 48 working weeks. That’s one workaround, done by one person.

Step 3: Put a price on the disruptions

Look back over the last year. How often did this thing break, how long was it down, and how many people stopped working or had to work around it? Your IT provider’s ticket history is the easiest place to find this, and the numbers from your quarterly reviews are even better if you keep them. A four-hour outage that stops 20 people costs 80 hours of work, about $3,600 at the same loaded rate, before you count delayed orders or annoyed customers.

Step 4: Rate the risk

Risk is the hardest part to put in dollars, and forcing a number on it usually makes the whole estimate less believable. Rate each item instead. How likely is it to cause a serious problem in the next year, and how bad would that problem be? An unsupported server holding customer records is high on both. An old printer that still gets updates is low on both. For a sense of how bad the worst case can get, what a data breach costs a small business walks through the numbers. Unsupported systems are also the kind of thing cyber insurance applications ask about, and a wrong answer there can turn into a problem when you file a claim.

Step 5: Estimate the principal

What would it cost to fix properly, once? Include the quote, the first year of any new subscription, and the time your own people will spend on the change: testing it, learning it, and the week where everyone gets used to the new way. Ask whoever would do the work. A rough range is fine.

Step 6: Compare the two

Divide the principal by the yearly interest from time and disruption. That gives you the payback period. An item that costs $3,000 to fix and $7,500 a year to live with pays for itself in under five months. An item that costs $40,000 to fix and $2,000 a year to live with may never pay back on time savings, and it’s only worth fixing if the risk or a due date says so.

A worked example

Here’s how that plays out for the distribution company from the start of this article. It has 25 people, one office and a small warehouse, and a loaded labor cost of about $45 an hour, or $55 for the finance lead. These are the five items from their first list:

Item	Yearly interest (time and disruption)	Risk	Principal (one time)	Payback	Due date
Retyping web store orders into accounting	$8,640	Low	$2,100	About 3 months	None
Commission spreadsheet macro	$5,280	Medium	$4,000	About 9 months	None
The DO NOT TURN OFF computer	$3,240	High	$1,200	About 4 months	Already past
Shared login to the carrier website	Close to zero	Medium	About $150 of staff time	Doesn’t apply, it’s fixed for the risk	None
The server in the back closet	$7,200	High	$22,000	About 3 years	Already past for SQL Server 2016, January 12, 2027 for Windows Server 2016

Where the numbers come from:

• The retyping takes three hours a week, plus about an hour fixing errors and chasing orders that shipped wrong: 4 hours times 48 weeks times $45. The fix is a supported integration between the store and the accounting system, about $1,500 to set up and $50 a month.
• The commission macro costs the finance lead a day a month to run and repair: 12 days, 8 hours, $55. Its risk is paying people the wrong amount. The fix is rebuilding it as a proper report in the accounting system, with help from its vendor.
• The DO NOT TURN OFF computer runs Windows 10 with no extended updates, so it hasn’t had a security update since October 2025. It failed twice last year, and both times six people in the warehouse worked from paper for most of a day. The fix is moving the export job to a supported, managed machine and writing down how it works.
• The shared login costs almost no time, but nobody can tell who booked which shipment, and two former employees still know the password. The carrier allows individual users at no charge, so the fix is an afternoon of someone’s time to set up five accounts and change the old password.
• The server runs Windows Server 2016, and its inventory database runs on SQL Server 2016, which lost support in July 2026. Twice last year it was unusable for about four hours, with 20 people affected. The fix is moving the files to SharePoint and the inventory system to its vendor’s hosted version.

Together that’s about $24,000 a year in staff time and lost days, before counting any of the risk. None of it shows up on an IT invoice, which is why nobody had ever added it up. Fixing all five comes to roughly $29,500, and $22,000 of that is the server.

The plan that came out of it:

1. This quarter: the carrier logins, the store integration, and moving the export off the Windows 10 machine. That’s about $3,450 in total, and it stops nearly $12,000 a year of interest.
2. Next quarter: the commission report, so it’s in place before year-end commissions get calculated.
3. Starting now, despite the payback: the server. Its database is already unsupported, and support for Windows Server 2016 ends January 12, 2027. On time savings alone it would wait, but the dates decide. A move like this often takes six months or more, so it will run past January. Microsoft does sell extended security updates for Windows Server 2016, but only for servers on certain volume or subscription licenses, not the license most small business servers came with, and the SQL Server underneath needs its own. The first job is finding out whether this one qualifies, because that decides how much risk the business carries until the move is done. The first quarter’s quick wins free up some of the staff time the project needs.

Payback set the order for most of the list, and the due dates overrode it for the server.

How to pay it down without a big replacement project

When the list is long, it’s tempting to replace everything at once: a new system, a new server, a clean start. Sometimes that’s the right call, and the next section covers when. Most of the time, it’s the riskiest way to pay down debt. A big project costs the most, disrupts the whole business at the same moment, and when it runs late, the shortcuts taken to finish on time become the next round of debt.

Start with anything that has a date

End of support dates go on the IT roadmap first, each with its date and a decision due well ahead of it. Servers and the core business applications need the longest lead time, often six months or more.

Then the quick wins

High interest, low principal: anything that pays for itself within about a year. Do a few every quarter. They free up staff time right away, and they make the case for the bigger items, because leadership has seen fixing debt pay off.

Fold the rest into changes you’re already making

Most debt can be paid off at a moment when you’re touching that system anyway. When a computer comes up in the refresh cycle, retire the job that only runs on it. When a software contract comes up for renewal, ask whether the vendor now offers the integration you’ve been working around, and use the answer in the negotiation. Managing software licenses and renewals covers that calendar. When you hire, fix whatever part of the setup is still done by hand.

Give it a steady budget line

Debt paid out of whatever’s left at the end of the year doesn’t get paid, because there’s never anything left. A fixed amount every quarter does get paid, even a modest one. Give it its own named line under the run portion of the annual IT budget, so it’s visible when cuts are being discussed instead of disappearing into contingency.

Keep a debt register

This is a short list, kept where both your IT provider and your leadership can see it, with one row per item:

Field	What goes in it
Item	What it is, in plain words
Kind	Infrastructure, unsupported software, workaround, manual connection between systems, or undocumented knowledge
Owner	The person responsible for deciding what happens to it
Yearly interest	Your estimate from the steps above
Principal	The one-time cost to fix it
Due date	End of support, warranty end, or contract date, if there is one
Decision	Fix, carry, or retire, and when it gets looked at again

Go through it at every quarterly review. Once it exists, that takes about ten minutes, and it keeps the list from growing again while nobody’s looking.

Write down new debt when you take it on

You’ll keep taking shortcuts, and some of them will be the right call. What changes is whether they go on the register the day they’re taken, with a reason and a date to revisit.

Retire it instead of fixing it, when you can

Some debt disappears once you stop doing the thing. The weekly report pieced together from two systems may turn out to have no reader. The old application kept around just in case may only be needed for its history, which a read-only export can cover. Before you price a fix, ask whether anyone would notice if it simply stopped.

Leave the cheap debt alone

Some items cost almost nothing to carry: a workaround that takes five minutes a month, or an old but supported device in a job where it can’t do much harm. Mark them carry, give them a review date, and spend the money where the interest is.

When a bigger project is the right call

Sometimes the debt is the core system itself. The practice management, inventory, or accounting software the business runs on is fifteen years old, its maker stopped developing it, half the workarounds in the office exist because of it, and it won’t run on a supported version of Windows. No amount of chipping away fixes that.

Signs you’re there:

• The vendor no longer supports or develops the product, or no longer exists.
• It stands in the way of basic security, like multifactor sign-in or a supported operating system.
• The workarounds around it cost more each year than a modern replacement would.
• Every new requirement, from a second location to a new customer contract, starts with “the system can’t do that”.

Even then, the replacement doesn’t have to happen all at once. Run the new system next to the old one for a while, move one function or one department at a time, and keep the old system read-only for history instead of migrating every record. Moving line-of-business applications to the cloud and choosing between lift and shift, re-platform, and re-architect cover the options. And before you sign anything, list every workaround the old system forced on you, so the new one doesn’t get the same ones rebuilt on top of it.

Who should own it

IT support sees the symptoms of technical debt every day, and fixing and closing tickets is exactly what support is supposed to do. Paying down debt is a different job: keeping the list, putting numbers on it, bringing it to leadership, and making sure the fixes happen in a sensible order. It needs one named owner.

In a business with a virtual CIO, it’s part of that role. With an internal IT manager, it’s theirs. Without either, it usually lands with the operations manager or the owner, with the IT provider supplying the technical side. Whoever owns it, the debt belongs in the same conversation as the roadmap and the budget, because it competes for the same money. When the risk side has to be explained to people who don’t work in IT, presenting an IT security report to non-technical leadership covers how to frame it.

Technical debt in Tampa Bay businesses

Sequentur is headquartered in Clearwater, Florida, with a team in Tampa, so for clients around Tampa Bay the first debt review happens on site. We walk the office, open the server closet, and sit with the people who run the workarounds, because that’s where most of the list comes from. Our IT help desk in Tampa sees the other half of it: the tickets that come back every few weeks, which are often the first sign that something is being worked around instead of fixed.

Hurricane season finds the debt that only works in the building. The season runs from June 1 to November 30. When the office is closed for a few days, by an evacuation order, a long power outage, or flooded roads, every workaround that depends on someone being physically there stops working too. The computer that runs the nightly export. The server in the closet. The fax machine for orders that never moved to email. The phone system that only forwards calls if someone at the front desk presses a button. For each item on your list, ask whether it would still work if nobody could get into the office for a week. The ones that wouldn’t belong near the top, and spring is the time to fix them, not August. What happens to your data if your office floods covers the data side of that week.

Florida law expects reasonable protection. The Florida Information Protection Act (Florida Statutes 501.171) requires any business that holds personal information in electronic form to take reasonable measures to protect and secure it. Personal information there means things like Social Security, driver’s license, or financial account numbers, or medical and health insurance details, tied to a person’s name. It also covers a username or email address together with its password. A system holding that kind of data on software that hasn’t had a security update in years could be hard to defend as reasonable after a breach. The same law requires you to tell the people affected as quickly as practical, and no later than 30 days after you determine a breach happened, and to notify the Florida Department of Legal Affairs if 500 or more Floridians are affected. An old, undocumented system makes that deadline harder to meet, because working out what was taken takes longer. If unsupported software on your list holds customer records, move it up. This is general information rather than legal advice, so check with your attorney on how the law applies to your business.

Common mistakes

1. Treating it as an IT problem. Most of the interest is paid by people outside IT, in hours they’ve stopped noticing. If only IT costs get counted, the biggest items never make the list.
2. Calling everything old “debt”. Age on its own isn’t the problem. If something is supported, does its job, and costs nothing extra, leave it alone.
3. Fixing the workaround instead of the reason for it. Automating the retyping with another homemade script just builds a newer workaround. Fix the connection between the two systems.
4. Waiting on end of support because “it still works”. Software past its end of support still runs. It just stops getting fixed.
5. Rebuilding the old workarounds on a new system. List what the old system forced you to do before you set up the new one, or the debt moves over with the data.
6. Leaving out the people who run the workarounds. They know where the debt is, and their day is the one that changes when it’s fixed. Ask them early, and make clear the workaround is the system’s fault, not theirs.

How this fits the rest of your IT

Technical debt runs through most of the planning in this series. The aging hardware part is what a hardware refresh cycle handles on a schedule. End of support dates and the larger paydown projects go on the IT roadmap as dated items. The steady paydown amount goes in the annual budget, and the register gets reviewed in each quarterly review. A business that keeps adding debt faster than it pays it off is usually one where IT decisions get made one emergency at a time, and aligning IT strategy with business goals covers how to change that.

Virtual CIO services for small business shows how the register, the roadmap, the budget, and the reviews fit into one year of planning, with one person accountable for all of it. If you don’t have an IT provider at all, managed IT services for small business explains what the full relationship covers.

What is next in this series

The next article covers how to choose the right IT partner as your business grows: why what works at 10 people tends to break at 50, what to look for in a partner that can keep up, how to tell when your current support has hit its ceiling, and how to change providers without disruption. A lot of the debt in this article is what a business leaves behind when it outgrows its IT, so the two go together.

How Sequentur can help

If you suspect your business is carrying more technical debt than it should, or you’d like a real number on the workarounds everyone has gotten used to, schedule a call. We’ll help you build the list, price it, and decide what to fix first. Around Tampa Bay, from Clearwater to Tampa, we can do the walk-through in person.