Technical debt on a website never sends you an invoice - it arrives quietly, in every change that costs more than the one before it. At first, adding a page takes a day. A year later the same job takes three, because someone has to work around the parts nobody is allowed to touch. Then comes the moment when a developer tells you something “cannot be done here any more” - and that sentence is the bill for every postponed decision at once. That is what technical debt on a website looks like from the owner’s desk: not a fault, but a rising price on every move that follows.
I am writing this from the angle that gets discussed least: the owner of a company whose site was built a few years ago, still works more or less, and every conversation about it ends with “let’s leave it for now”. You are not a developer and you have no obligation to know what sits underneath. You do have a right to know what it costs you to leave it alone.
Below I break down three things: how to recognise that your site already carries debt, how that debt turns into real money, and how to decide between repairing and rebuilding. No scare stories, and none of the technical detail you do not need for this decision.
Technical debt on a website - how to spot it
In plain words: it is every shortcut, postponed update and temporary fix that once let somebody finish faster, and now sits in the code charging interest on every change that follows. It is not an outage. An outage is visible. Debt only becomes visible the moment you want something from the site.
The signals I see most often on older company sites:
- Every change needs a “let me look first” quote. On a healthy site, adding a page or a form field can be priced from a description. If you hear every time that somebody has to check whether it will break something else, that is interest.
- Nobody wants to touch one particular thing. The theme, an old form, the accounting integration. There is a sacred cow everybody works around, because nobody remembers how it works.
- The dashboard has been showing red update counters for months and nobody clicks, because the last click broke something. Fear of updating is a symptom in itself.
- The person who built it is gone. The agency closed, the freelancer stopped replying, the in-house IT person changed jobs. The knowledge of what not to touch, and why, left with them.
- There is no backup, no staging and no documentation. Every change goes straight to the live site, because there is nowhere to try it first.
- It is slow and nothing is being done about it, because fixing the speed would mean entering exactly those places nobody wants to enter.
One or two of these is normal wear. Four or more is a site that has stopped being a tool and become something you tiptoe around.
What helps: try a simple test. Write down three things you would like to change on the site this quarter and ask for a price on each one separately. If all three come back with “depends what is in there”, you have your answer about debt without commissioning any audit.
What postponing costs - four separate bills
This is where people ask for a figure, and I have to be honest: there is no single number, because every site’s debt is made of different things. There are, however, four bills that always come due, and it helps to recognise which of them you are paying.
Bill one: security. When a plugin author publishes a fix for a vulnerability, the existence of that vulnerability becomes public. From that moment bots scan the web for sites still running the old version - not because anyone is targeting your company, but because you are on a list of addresses. A site left unpatched for years sits on several such lists at once. The cost is irregular: nothing for a long time, then suddenly a restore from backup, a clean-up, and explaining to customers why Google warns people about your domain. What has to be patched urgently and what can wait, I covered in the post on the cost of WordPress updates.
Bill two: speed. Old sites are slow for no single reason, but from accumulation: images uploaded at full size, plugins added over years and never removed, a theme loading everything on every page, hosting chosen for a site half the current size. You pay in visitors who leave before the page appears, and in rankings, because speed is one of the signals search engines read. That bill runs daily and nobody ever issues it.
Bill three: the price of every change. This one hurts most and shows least. Debt does not raise the price of one job - it raises the price of everything you will ever do next. Work that takes a day on a clean site takes three on a heavily indebted one: one to find out what must not be touched, one to work around it, and one to check that the workaround broke nothing. The longer you postpone, the bigger the multiplier on every invoice. That is why we talk about debt and interest rather than about something being broken.
Bill four: the options you no longer have. This one rarely enters the conversation and is often the most expensive. You want to add payments, a booking system, a warehouse integration, or to do something serious about search visibility - and you are told it cannot be done on this version. Not “it will be expensive”, simply not possible. A business idea dies at the quoting stage, and you never count it as a cost of the website, because you never paid anything.
What helps: instead of hunting for the size of the debt, count something else - how much money went through the site last year. Enquiries from the form, calls from the contact page, sales. If the answer is serious, then an indebted site is a risk to something that genuinely works for your business. If the answer is “nothing”, you have a different problem than technical debt, and it is worth knowing that before spending a zloty. How that calculation adds up, I wrote out in the post on website maintenance cost.
Repair or rebuild
When this question reaches me by email, the expected answer is almost always “rebuild from scratch”, because a clean start is easier to picture than digging through what already stands. A rebuild is, however, the most expensive and riskiest route, and it is not always the necessary one.
Repairing and tidying in place is enough when the foundation is still supported: the site runs on a current, maintained platform, it can be updated normally, and the problems are countable and can be named. Then you do it in order: backup and staging, updates, removing plugins nobody uses, tidying the theme, fixing the speed. The site keeps working the whole time, and you pay for a closed scope rather than for surprises. I described that scenario in more depth in the post on redesign without rebuilding from scratch - the mechanism is the same for a company website.
Migrating an old site onto a new foundation makes sense in different circumstances, and that is when it is worth stopping the repairs:
- The platform is no longer maintained, or you are on a version that gets no security fixes and cannot be raised without rewriting the theme.
- The site is a stack of temporary fixes where every repair uncovers the next one, and the cost of tidying approaches the cost of building it once, properly.
- You need something from the site that the current version cannot carry: selling, a client panel, a serious integration.
- There is no documentation and nobody who knows the code, and it has been modified so heavily that mapping it costs more than building new.
The decision looks simple on paper, but it needs one thing that usually has not been done: an honest review of what is actually there. Not an opinion that “it is old, so rebuild”, but an inventory - which versions, which plugins are abandoned, what was hand-edited in the theme, and what genuinely brings traffic and enquiries. I run that review at the start of any work on speeding up and repairing an existing site, because without it a quote is guesswork and the scope swells halfway through. For larger commerce platforms I laid out the same calculation in the post on platform migration pricing.
There is a third route worth knowing about, because it saves the most money: tidy up enough now to make the site safe and reasonably fast, and plan the rebuild for the moment you are changing your offer anyway or entering a new market. The debt gets paid down partly and deliberately, instead of growing further or swallowing a budget in the least convenient quarter.
How this works in practice with me
When somebody writes to me saying “the site is a few years old and we are afraid to touch it”, I start with a review. I check versions, abandoned plugins, theme modifications, speed, backups, and whether the site brings in any enquiries at all today. Out of that comes one of three recommendations: tidy in place, rebuild, or tidy now and rebuild at the next change in the business. You get it in writing together with scope and price, so you can compare it with another offer or postpone it - but postpone it knowingly, aware of what you are deferring.
One thing I say plainly to everyone: not every old site needs intervention. A brochure site that has stood for years, that nobody changes, for a company that does not live off the internet, can keep standing - it just needs backups and updates watched. Debt hurts where the site still has work to do for the business. If it is only there to stand, let it stand.
Summary
Technical debt is not a fault, it is a growing multiplier on every change that follows. You recognise it when nobody wants to touch something, updates have waited for months, and every quote starts with “let me look first”. Postponing is paid in four bills: security, speed, the price of every change, and the ideas that die on the sentence “not on this version”. Repair in place is enough while the foundation is supported; migration makes sense when the platform gets no fixes, or when repairs have come close in price to building it once, properly. The decision rests on a review of what is there, not on the impression that it is old.
If you do not know where on that scale your site sits, send me the link. I will do a review and tell you plainly what needs attention now, what can wait, and whether tidying up or migrating works out cheaper in your case.
Frequently asked questions
Is technical debt the same as “the site looks dated”? No, and the distinction matters, because it decides the budget. Appearance is a layer you can replace without touching the foundations. Technical debt sits underneath: in versions, modifications and temporary fixes. A site can be attractive and indebted, or plain and technically healthy - two separate matters and two separate quotes.
What does a review like that cost? I do the review from a link, because without it I cannot price the work honestly, and a quote pulled out of the air serves nobody. Only after the review do you get a written quote for a closed scope. If the review shows the site needs no intervention right now, I will say so.
The site works and brings enquiries - why touch it? If it genuinely works and is secure, do not touch it. Just keep backups and critical updates in hand, especially the ones described as security fixes. The problem appears the moment you want something new from the site - and that is when the debt shows up as the price of that one change, usually higher than you expect.
Does migration mean losing search rankings? It does not have to, but an unprepared migration can flatten them. What decides is moving the addresses and redirecting old ones to new, keeping the content that brings traffic, and checking indexing after the move. That is work to plan before the migration, not after. If somebody proposes a move without any conversation about addresses and redirects, that is a risk not worth taking.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Let’s talk about your project.