Technical debt is the future cost of a shortcut you take today. When you fix something the quick way instead of the right way, you borrow time: the shortcut gets you moving now, and you repay the loan later, with interest, in the hours and money it takes to work around the shortcut every time you touch it. The term comes from software, but the idea has nothing to do with code. At a commercial real estate firm running on spreadsheets, macros, and a stack of half-connected tools, technical debt is the reason the cheap fix you approved last year keeps quietly costing you this year.
Most writing about technical debt is aimed at software engineers with a codebase and a development team. You have neither. You are a principal, a managing broker, or an operations director at a firm of four to twenty people, and the closest thing you have to code is a workbook full of formulas, a couple of Zapier automations, and a script someone set up once and then left. That does not make you immune to technical debt. It makes you more exposed to it, because there is no one whose job is to keep the plumbing sound. The definition below is the one that holds up at your size, where the debt is invisible until the day it stops a deal.
What Technical Debt Actually Means
Technical debt is what you owe later for a shortcut you take now. The programmer Ward Cunningham coined the phrase in 1992 to explain to non-technical managers why a team would spend time reworking software that already seemed to function. Shipping a rough first version, he argued, is like taking out a loan: it gets you to market faster, but you pay interest on it — in slower future work — until you go back and clean it up.
The metaphor travels well beyond software because the mechanism is universal. Any time you solve a problem the fast, cheap way instead of the sound way, you create a small ongoing tax on everything that touches that solution afterward. The task technically works. It just costs a little more, every single time, than it would have if you had built it properly.
That is the part people miss. Technical debt is not a bug and it is not a mistake. The quick fix usually does the job it was asked to do. The debt is the hidden recurring cost of having done it quickly — and, like real debt, it is easy to ignore right up until the interest payments start to hurt.
Why the Quick Fix Feels Free
The quick fix feels free because the person who takes the shortcut is rarely the person who pays for it. You save two hours today by hard-coding a workaround; the cost lands three months from now, spread across everyone who has to remember the workaround exists. The savings are immediate and visible. The interest is delayed and diffuse. That asymmetry is exactly why technical debt accumulates so quietly.
For a small firm, the interest is paid in two currencies. The first is time: the minutes lost every week re-doing a step that a proper setup would have handled, the afternoon lost when the one fragile automation breaks and someone has to reverse-engineer it. The second is fragility: the closing that slips because the rent-roll macro choked on a new format, the number that silently went wrong because a spreadsheet reference drifted and nobody noticed until an investor did.
Neither cost shows up on an invoice, which is why quick fixes escape scrutiny. If a shortcut sent you a monthly bill, you would evaluate it like any other expense. Because it bills you in scattered hours and occasional crises instead, it hides — and it compounds while it hides.
What Technical Debt Looks Like at a Small CRE Firm
At a firm with no engineers, technical debt does not live in a codebase. It lives in the tools you already use every day. It looks like this:
- A spreadsheet nobody can fully explain. The underwriting model works, but it has grown a tangle of nested formulas and hidden tabs over five years, one person understands maybe 70% of it, and everyone is a little afraid to change a cell.
- An automation held together with tape. A Zapier or Make chain moves data from a form to your CRM to a spreadsheet. It saves real time — until a field name changes upstream and the whole chain fails silently for a week before anyone notices deals stopped syncing.
- The one-off script. Someone technical set up a small tool once to rename files or pull data. It still runs. Nobody remembers how it works, and when it eventually breaks, the person who built it is long gone.
- The inbox as a database. Deal status, approvals, and key documents live in an email thread instead of a system, so the “record” of what happened is whatever a busy broker can reconstruct from a search.
- A CRM full of improvised fields. Half the team logs deals one way, the other half another, custom fields have piled up with no shared definition, and the reports you pull from it are quietly unreliable.
None of these were mistakes when they started. Each was a sensible shortcut that solved a real problem fast. They became technical debt the moment other work started depending on them and no one owned keeping them sound. This is also why a firm’s tool stack tends to sprawl in ways that are hard to see from the inside — the debt hides inside tools you think of as assets.
Two Kinds of Debt: Prudent and Reckless
Not all technical debt is bad, and treating it as if it were leads small firms to over-engineer things that never needed it. Martin Fowler, a widely cited voice on software design, drew a useful line between debt taken on deliberately and debt acquired by accident — and between debt that is prudent and debt that is reckless. Simplified for a firm without engineers, it comes down to two questions: did you know you were borrowing, and did you have a plan to repay?
Prudent debt is a conscious loan. You decide, on purpose, to build the rough version now because speed matters more than polish today — a spreadsheet to test whether a new reporting format is even useful, a taped-together automation to prove an idea before you invest in it properly. You know it is temporary, you know what “repaying” it looks like, and you circle back when the idea proves out. This is good debt. Lean firms move fast precisely because they are willing to take it on.
Reckless debt is an accident with no plan. The shortcut gets taken without anyone deciding it was a shortcut, it quietly becomes permanent, other things start to depend on it, and there is no owner and no repayment plan. This is the debt that compounds. The difference between the two is almost never the shortcut itself — it is whether you took it on with your eyes open. A prudent quick fix is a tool. A reckless one is a liability you have not priced yet.
How the Interest Compounds
Technical debt gets expensive because the interest compounds, and it compounds in a specific, predictable way: each quick fix makes the next problem harder to solve. A workaround gets built on top of another workaround, and soon the tangle is load-bearing — you cannot replace any one piece without three other things breaking, so you patch instead of fixing, which adds more debt.
Three forces drive the compounding. Dependency: once your reporting spreadsheet feeds your investor updates, which feed your CRM, you can no longer clean up the spreadsheet without touching everything downstream. Key-person risk: the fix lives in one person’s head, so the debt is really a bet that they never leave, never forget, and never take a two-week vacation during a closing. Drift: the outside world changes — a bank changes a statement format, a vendor changes a form, a portal changes an export — and every brittle shortcut that assumed the old format quietly breaks.
The enterprise version of this problem is large enough to have been measured. McKinsey, studying how companies account for technical debt, reported that CIOs estimate it at roughly 20 to 40 percent of the value of their entire technology estate, and that some organizations spend 10 to 20 percent of the technology budget meant for new projects just servicing the debt they already carry. Your firm has no such balance sheet, but the ratio is instructive: at some point, a firm that never repays its shortcuts spends more time feeding the workarounds than doing the work the workarounds were supposed to speed up.
When a Quick Fix Is the Right Call
A quick fix is the right call when speed genuinely matters more than durability and you take the shortcut on purpose. Testing whether an idea is worth pursuing is the clearest case: before you commission a custom build, a rough spreadsheet or a manual, taped-together process is exactly how you learn whether the thing is even useful. Spending real money to build the durable version of an idea you have not validated is its own kind of waste.
The test is not “is this a shortcut?” — almost everything useful starts as one. The test is three questions. First, do you know this is temporary? Second, do you know what repaying it looks like — replacing it, or rebuilding it properly? Third, is someone responsible for circling back when the moment comes? If you can answer all three, the quick fix is prudent debt, and taking it on is a sign of good judgment, not bad. If you cannot, you are not choosing a shortcut. You are drifting into one.
This is the same discipline behind testing an automation on a small scale before committing to it. Proving an idea cheaply first, then building the durable version only once it earns the investment, is the entire logic of running a real proof of concept and pilot before you move something into production — a sequence designed to keep temporary shortcuts from silently becoming permanent load-bearing infrastructure.
How to Keep Technical Debt From Owning You
You do not eliminate technical debt — every working firm carries some, and a firm with zero is a firm moving too slowly. You manage it. For a small CRE firm without an IT department, managing it comes down to a handful of habits that cost almost nothing and prevent the expensive version.
- Name it out loud. When you approve a quick fix, say so: “This is the temporary version — we ship it now and revisit in Q2.” A shortcut you named is prudent debt. A shortcut you never acknowledged is the reckless kind.
- Give every load-bearing tool an owner. If a spreadsheet, automation, or script is something the firm depends on, one named person is responsible for it working — and for it being documented well enough that someone else could take over. Undocumented critical tools are key-person risk wearing a disguise.
- Write down what the fix assumes. One paragraph: what this does, what it depends on, and what breaks it. This is the difference between a fifteen-minute fix and a lost afternoon when it fails.
- Repay before you rebuild on top. When you are about to build something new on top of a known shortcut, that is the moment to repay the debt first — not after the tower is three stories tall.
- Know when to stop patching and buy. Sometimes the honest answer is that the pile of workarounds should be replaced by a tool built for the job. Whether the right move is an off-the-shelf platform or a scoped custom build is exactly the decision covered in the buy-versus-build playbook.
That last point matters more than it looks. A great deal of small-firm technical debt is accidental integration debt — the brittle connections between tools that were never designed to talk to each other. Understanding what a clean connection actually involves, laid out in plain terms in our guide to what a software integration really is, is often what separates a durable setup from a taped-together one that becomes next year’s debt.
Quick Fix vs Durable Build, Side by Side
The choice is rarely between “cheap” and “expensive.” It is between paying now and paying later, and the durable option is only worth it when the task is here to stay.
| Quick fix (prudent debt) | Durable build | |
|---|---|---|
| Upfront cost | Low — hours, not thousands | Higher — a real investment |
| Best for | Testing an idea, one-off needs, low volume | Proven, repeated, high-volume work |
| Ongoing cost | Interest: time lost to fragility and workarounds | Maintenance, but predictable |
| Key-person risk | High if undocumented and unowned | Lower — built to be handed off |
| When it goes wrong | Silent failures, broken closings, drift | Contained, because someone owns it |
| Right call when | Speed matters and you have a repayment plan | The task has earned a permanent solution |
Read across the bottom row and the rule is clear: a quick fix is the right tool for an unproven or occasional task, and the wrong tool for the work your firm does every week. The mistake is not taking the shortcut. It is leaving a shortcut in place long after the task outgrew it. For the bigger picture of how lean firms decide where to invest and where to improvise, the small-firm AI manifesto lays out how disciplined choices about tooling let a small shop out-operate much larger ones.
Frequently Asked Questions
What is technical debt in simple terms?
Technical debt is the future cost of taking a shortcut instead of doing something the sound way. You save time or money now, and you pay it back later — with interest — in the extra effort it takes to work around the shortcut every time you touch it. The task still works; the debt is the hidden recurring cost of having done it quickly. The term comes from software, but it applies to any tool or process, including the spreadsheets and automations a real estate firm runs on.
Is technical debt always bad?
No. Deliberate, well-managed technical debt is often smart, especially for a lean firm that needs to move fast. Building a rough spreadsheet to test whether an idea is useful, before you invest in a proper version, is prudent debt — a conscious loan you plan to repay. Debt only becomes a problem when it is accidental and unmanaged: taken on without anyone noticing, left in place with no owner, and built on top of until it cannot be removed. The danger is not the shortcut. It is the shortcut nobody decided to take.
How does technical debt apply to a firm with no software developers?
The “code” at a small CRE firm is your spreadsheets, macros, automations, one-off scripts, and CRM setup. Technical debt lives there. An undocumented underwriting model only one person understands, a Zapier chain that breaks when a field changes, an inbox used as a deal database — each is a shortcut that other work now depends on. You have technical debt for the same reason a software company does: you solved problems fast, and no one owns keeping those solutions sound.
Why do quick fixes get expensive over time?
Because the interest compounds. Each shortcut makes the next problem harder to solve: workarounds get stacked on workarounds until the tangle is load-bearing and cannot be changed without breaking things downstream. Three forces drive it — dependency (other tools start relying on the fix), key-person risk (the fix lives in one head), and drift (the outside world changes and brittle shortcuts break). A fix that saved two hours can end up costing a lost afternoon every month, plus the occasional broken closing.
What is the difference between prudent and reckless technical debt?
Prudent debt is a shortcut you take on purpose, knowing it is temporary and having a plan to repay it. Reckless debt is a shortcut taken by accident that quietly becomes permanent, with no owner and no repayment plan. The shortcut itself is often identical — the difference is whether you took it with your eyes open. A prudent quick fix is a tool that buys you speed. A reckless one is a liability you have not priced yet, and it is the kind that compounds into real cost.
How do I know when to fix something properly instead of patching it again?
Repay the debt when the task has proven it is permanent, when the fix keeps breaking, or when you are about to build something new on top of it. If a workaround has failed more than once, if it is load-bearing for real work, or if only one person can keep it running, it has outgrown its shortcut. The clearest trigger is the moment before you extend it: fixing the foundation is far cheaper before you stack another workaround on top than after.
Does buying off-the-shelf software avoid technical debt?
It reduces one kind and can create another. A well-chosen off-the-shelf tool removes the debt of maintaining your own brittle workarounds, because the vendor owns keeping it working. But connecting several tools together, or bending one to do a job it was not built for, creates integration debt of its own. The goal is not zero debt — it is choosing the tools and connections that keep the debt small, documented, and owned rather than sprawling and invisible.
How is technical debt connected to AI automation projects?
AI makes it cheap to build automations quickly, which makes it easier than ever to accumulate technical debt without noticing. A prompt or a no-code automation that reads leases or drafts emails is a real shortcut — prudent if you treat it as a tested, owned tool, and reckless if it becomes an undocumented dependency nobody can fix. The same discipline that governs any quick fix applies: know it is a loan, know how you would repay it, and give it an owner before it becomes load-bearing.
Can technical debt ever be fully paid off?
No, and trying to reach zero is usually a mistake. Every firm that ships work carries some technical debt, and a firm with none is almost certainly moving too slowly or over-building things that did not need it. The goal is a manageable balance: take on debt deliberately when speed matters, keep it documented and owned, and repay the pieces that have started to compound. Managed debt is a normal cost of operating. Ignored debt is what gets expensive.
Where to Start
The practical first step is not to hunt down every shortcut in your firm — it is to know which ones are quietly costing you the most, and which of your workflows would actually pay for a durable solution instead of another patch. That inventory is where the money is: a ranked read on where your current setup is fragile, where a proven off-the-shelf tool already solves the problem, and where a scoped build would earn its cost. That is exactly what a free AI-readiness assessment produces — a working session that maps your firm’s tools and workflows, flags the technical debt worth repaying, and returns a plan with real cost ranges. Book a free AI-readiness assessment if you want that map before your next quick fix becomes next year’s expensive problem.
Dirk Jan van Veen, PhD
