Cheap websites do not fail at launch. That is the whole problem: at launch they look like the expensive ones, which is why the approach keeps selling. They fail on a schedule, and the schedule is consistent enough that we can usually guess the age of a site from the symptoms described in the first phone call.
That call tends to arrive around month fourteen.
Months 0 to 3: it looks fine
The site is live and nothing appears wrong. What is missing is invisible: backups nobody configured, analytics nobody connected, a staging copy that does not exist, and a content system where changing a headline means opening the same page builder that only one person understands.
The first symptom is small and easy to dismiss — you ask for a two-word text change and it takes three days, because the change has to go through the person who built it. Nobody escalates over a headline, so the arrangement holds.
Months 3 to 6: the first conflict
Updates start arriving — the platform, the theme, a dozen plugins. One of them breaks something. Somebody spends an afternoon fixing it, and then quietly makes a decision that determines everything that follows: we will stop updating.
From this moment the site is a fixed object in a moving world. Meanwhile speed drifts downward as more scripts, banners and tracking arrive, each of them individually reasonable.
Months 6 to 12: silent failures
This is the expensive phase, and almost nobody notices they are in it. Security patches are being skipped by policy now. Forms start failing silently — the customer sees a success message, you never receive the enquiry. Spam arrives through the contact form, so somebody adds a plugin to stop it, and that plugin blocks a share of real submissions too.
Nothing here shows up as an outage. It shows up as a quarter that felt slower than it should have, and there is no report that explains why, because nobody installed the reporting.
Months 12 to 24: the breaking change
Something external changes and stops being optional: a runtime version reaches end of life, a payment provider deprecates the interface, a browser stops accepting an old integration, the hosting company migrates. The site now has to be updated — and it cannot be, because every customisation was made in place, on the live installation, with no record of what was changed or why.
This is also the point where the original developer is typically unavailable. Not out of malice: they moved on, changed careers, got a job. Whoever picks it up now has to reverse-engineer the work before touching it, and that reading time is billed to you.
Month 24 and beyond: rescue costs more than the build did
By now the honest options are a full rebuild or an expensive stabilisation with a limited lifespan. The original saving has been spent several times: in the delays, the lost enquiries, the emergency invoices, and the two years of work that produced an asset nobody can maintain.
None of this happens because the person who built it lacked skill. It happens because of what the price could not include. Roughly a third of a healthy project is invisible work — deciding what to build, testing it, and handing it over properly — and that third is exactly what disappears when the number gets small. We broke the budget down in detail elsewhere.
Why the timeline is so consistent
The same story arrives with different sites because three things are missing in every version of it, and each one removes a way out.
There is no history: changes were made directly on the live site, so nothing can be compared to a working state and nothing can be undone. There is no separate place to try things, so every fix is performed in front of customers and the safest available decision becomes “do not touch it”. And there is no owner: nobody is responsible for the site between requests, which means the only events that trigger work are failures.
Those three absences are what make an ordinary maintenance task into a project two years later. They are also cheap to fix at the start, which is the frustrating part.
What a little more money buys, if you have it
If the budget is tight but not fixed, three additions change the timeline more than any amount of extra design work.
A place to test changes before customers see them. A repository with history, so the site can be rolled back and read by whoever comes next. And a small, named maintenance arrangement — updates applied on a schedule, backups verified, someone who answers. Ask for those three by name in the quote and accept fewer pages in exchange; the trade is strongly in your favour.
Five signs you can spot before you buy
- No exclusions list in the quote. A proposal that never says what is not included has not been costed. It has been priced to win.
- No staging environment. If changes go straight to the live site, then every future update is a gamble taken in public.
- No repository. Ask where the code will live and who can access it. “On the server” means there is no history, and no history means no safe way back.
- Content locked into a builder. Ask to be shown, before signing, exactly how you will change a heading and add a page. If the answer involves calling them, you have bought a subscription without the paperwork.
- No named plan for after launch. Not a promise of support — a named arrangement: who applies updates, how often, and what it costs. Silence here is the single strongest predictor of the timeline above.
Two more worth asking about, both cheap to fix at the start and painful later: whether the accounts will be in your name, and whether anyone will ever restore a backup to prove it works. We wrote out the full ownership list for the first one.
If you are already at month fourteen
The order matters more than the enthusiasm. Get backups working and prove one restore, because everything else is risk until that is true. Then get an audit that separates what is broken, what is merely inconvenient and what is fine. Only then decide between repair and rebuild — and expect the answer to be less dramatic than it feels, because most of the time it is repair.
What you should refuse is the emergency rebuild sold in the middle of the panic. A site that is currently earning money deserves a decision made with numbers, not one made on the day the payment integration stopped working.
When cheap is the right answer
We are not arguing that everyone should spend more. Cheap is correct in three situations, and we say so regularly.
The first is validation: you do not know whether anyone wants this, and the site exists to find out. Spending properly before you have an answer is the more expensive mistake. The second is a short, known lifespan — a campaign, an event, a seasonal page that will be deleted. The third is a genuinely simple need honestly met by a good template, where the money saved goes into photography, content and reaching people.
All three have the same condition attached: the accounts must be in your name and the content must be exportable. A cheap site you own is a reasonable business decision. A cheap site somebody else owns is a debt with an unknown interest rate.