A Founder's Guide to Technical Debt

"Technical debt" is the phrase developers use when they want budget and founders hear as vague guilt. That's a shame, because the metaphor was coined precisely to help business people reason about a technical reality — and it works, if you take it seriously as a metaphor. Debt isn't bad. Debt is leverage. Businesses borrow deliberately all the time; what kills them is not knowing how much they owe, to whom, and at what interest rate.

Your website carries technical debt right now. This guide is about seeing it, pricing it, and making repayment decisions the way you'd make any other capital allocation decision — because that's what it is.

The metaphor, taken literally

Technical debt is the gap between how your website is built and how it would be built if you did it properly today. Every shortcut opens the gap; the gap charges interest.

• The principal is the cost of fixing it properly — the redesign, the rebuild, the migration you're deferring.
• The interest is what the shortcut costs you every month you don't fix it: every change takes longer, every update is riskier, every new feature gets built on the wobbly part. Interest compounds, because new work built on top of debt inherits it.
• The credit rating is your team's (or freelancer's, or your own) confidence touching the site. When people fear deploying changes, velocity collapses — that's what a maxed-out credit line feels like.

Two corollaries founders often miss. First, taking on debt is frequently correct. The duct-taped landing page that validated your product before you invested in it was smart borrowing; shipping something imperfect this quarter to win a contract usually beats shipping something perfect next year. The sin isn't borrowing — it's borrowing unknowingly, with no record and no plan. Second, not all debt charges the same interest. Debt in code you never touch charges almost nothing. Debt in the checkout you modify monthly is a payday loan.

What technical debt looks like on an actual small-business website

Forget abstract definitions; here is the field guide. If your site is on WordPress or similar, debt typically wears one of these faces:

• The plugin pile. Thirty-plus plugins, several overlapping (two SEO plugins, three page builders' worth of shortcodes), some abandoned by their developers. Each is a dependency someone chose in a hurry; together they're why the site is slow and updates are frightening.
• The frozen update. PHP two major versions behind, WordPress core pinned because "last time we updated, things broke." This is debt actively compounding: the further behind you fall, the scarier the jump, so you fall further behind. It's also a security exposure, which makes it debt with a balloon payment attached.
• The untouchable customization. "The previous developer changed something in the theme; we don't update the theme anymore." Edits made directly to a theme (instead of a child theme) or hacks inside plugin files are classic debt: they weld your hands to one version forever.
• The person-shaped dependency. Only one freelancer knows how the booking system works, and they've stopped answering emails. Undocumented knowledge is debt where the creditor can vanish.
• Content and structure debt. Four hundred pages with no owner, three generations of URL structures held together by redirect chains, product data duplicated in two systems that drift apart. Not code — still debt, still charging interest in confusion and SEO leakage.
• Infrastructure debt. Hosting chosen years ago for a site one-tenth the size, no staging environment, backups "probably handled by the host," credentials in a text file three laptops ago.

Notice what these have in common: each one made sense at the time. Debt rarely arrives labeled. It accrues as a series of individually reasonable decisions whose sum nobody is tracking.

How to price the interest (the founder's actual job)

You don't need to read code to measure technical debt. You need to measure its symptoms, all of which are business-visible:

1. Time-to-change. How long does a trivially small change — new headline, new team member on the About page, price update — take from request to live? On a healthy site: minutes to hours. If small changes take days and require a specialist, you're paying interest on every edit.
2. Fear index. Ask whoever maintains the site: "What are you afraid to touch?" The answer is a map of your debt, drawn for free. If the answer is "everything before we take a backup and pray," your interest rate is high.
3. Incident pattern. How often does something break after an update? Once a year is normal; monthly means structural problems.
4. Opportunity cost. The most expensive line and the least visible: what have you not done because the website couldn't support it? The campaign not launched, the pricing experiment skipped, the market not entered because "the site can't handle that." When debt starts vetoing strategy, it has stopped being a technical issue.
5. The bus factor. How many people can safely change the site? If the answer is one (or zero), price in the cost of rediscovery when that person leaves.

Write these five answers down twice a year. Trend matters more than level: a site whose time-to-change is slowly growing is a business accumulating drag it will eventually have to shed at the worst possible moment — because debt always comes due during growth, when you need the website to move fast and it can't.

Deciding what to repay: a portfolio approach

You will never repay all of it, and you shouldn't try. Treat debts like a portfolio and triage on two axes: interest rate (how much it costs monthly) and proximity to change (how often you touch that part of the system).

Three rules make the portfolio manageable:

• Security debt jumps the queue. Outdated PHP, abandoned plugins with known vulnerabilities, missing backups — these aren't high-interest loans, they're unhedged tail risk. A breach doesn't charge interest; it forecloses. Fix these before any convenience-motivated refactor, always.
• Bundle repayment with feature work. Pure "cleanup projects" are hard to fund and easy to cancel. The sustainable pattern is a tax: every project that touches an area budgets a little extra to leave that area better — replace the abandoned plugin while redesigning the page it powers, fix the URL structure during the content refresh.
• Prefer deletion to refactoring. The cheapest debt repayment is removing the thing. That plugin serving a feature nobody uses, those 200 zombie pages, the third contact form — much website debt can simply be deleted, and small-business sites are usually richer in deletable debt than anyone expects.

Borrowing well: rules for taking on new debt

Since you'll keep borrowing (correctly), borrow like a CFO rather than a gambler:

1. Say it out loud. "We're doing this the quick way; the proper version would take three weeks we don't have" is a legitimate sentence. Silent shortcuts are how debt becomes invisible.
2. Keep a debt register. A single shared document listing known shortcuts: what was done, why, what proper looks like, what it costs monthly. Ten lines maintained beats a wiki abandoned. This document is also gold for every new developer or agency you ever hire — and it converts the handover from archaeology to onboarding.
3. Prefer reversible shortcuts. A quick page built with standard tools is cheap debt. A quick hack inside core files of your theme is expensive debt. When two shortcuts save similar time, take the one that's easier to undo.
4. Never borrow against foundations. Skimp on a campaign page, never on backups, updates, security, or hosting quality. Foundation debt is the kind with the balloon payment. This is also the honest case for managed hosting: it moves a whole class of foundation debt — patching, backups, performance, security hardening — off your balance sheet entirely, for a known monthly fee. Predictable cost replacing unpredictable liability is exactly the trade a debt-aware founder should like.

The rebuild question

Eventually someone proposes it: "honestly, it'd be faster to rebuild the whole site." Sometimes true. Treat it as the refinancing decision it is:

• Rebuild when the interest payments (slow changes, breakage, fear, blocked strategy) exceed the amortized cost of the rebuild and the current platform is the actual cause — not just unfamiliar to the new developer proposing it. New developers systematically overestimate the badness of old code they didn't write; get a second opinion.
• Refactor incrementally when the debt is concentrated (one bad plugin cluster, one untouchable template) rather than pervasive. Most "we need a rebuild" situations are really "we need to fix these three things" situations wearing a dramatic costume.
• And if you do rebuild: the rebuild will accumulate debt too, starting day one. Carry the register, the repayment tax, and the borrowing rules into the new site, or you'll be having this conversation again in four years with different logos.

Conclusion

Technical debt is not a moral failing or a developer's excuse — it's the ordinary financial structure of every evolving website, yours included. The founder's job isn't to eliminate it; it's to know the balance: measure the interest through time-to-change and the fear index, keep a ten-line register, repay the high-interest debt in the code you touch often, treat security debt as tail risk rather than debt at all, and borrow deliberately with a paper trail. Do that, and technical debt becomes what debt is supposed to be in a business — a tool you use, rather than a thing that quietly happens to you.

Photo: pipop kunachon on Pexels