The quote for a new website is an honest number. It simply answers a different question from the one you are actually asking. Anyone who wants to know what a website costs rarely means the build alone; they mean the next five years. And within those five years, the build is the smaller number. A website is not an object you buy once, it is a small operation: it runs on other people's software that picks up vulnerabilities weekly, on a foundation with an expiry date, and it says things that will no longer be true in two years. This piece works through the website costs that no quote can contain, with prices you can look up yourself.
Why can a quote not include the running side?
Because a quote prices an outcome, not a behaviour. Everything in it ends on a given day: concept, structure, design, build, first content, handover. That is a project, and projects finish. On the same day something else begins that never finishes, and it runs on three separate clocks.
The first clock is the technology. It runs in hours and days, because every piece of software underneath your site is maintained by strangers and their mistakes become your problem. The second clock is the content. It runs in months: prices change, people leave, services are added, and at some point the home page describes a business that no longer exists in that form. The third clock is the foundation, meaning the programming language and the system beneath it. It runs in years, but without room for negotiation.
A quote covering all three clocks would not be a quote any more, it would be a five-year contract. That is precisely why the running side usually gets discussed only when it announces itself: as a maintenance agreement, as an invoice after an incident, or as a quote for a new website because the old one "stopped working". Knowing the three clocks in advance changes how you negotiate.
How quickly does the technology underneath your site age?
Faster than any maintenance rhythm small businesses typically agree to. For the most widely used system there are solid figures: 40.7 per cent of all websites worldwide run on WordPress, and among sites with an identifiable content management system the share is 58.9 per cent (W3Techs, retrieved 28 August 2026). In 2025 the WordPress ecosystem produced 11,334 newly discovered vulnerabilities, 42 per cent more than the year before. Of those, 1,966 or 17 per cent were rated severe enough to be usable in automated mass-scale attacks (Patchstack, State of WordPress Security in 2026).
The distribution is the actual news. 91 per cent of the vulnerabilities sat in plugins, 9 per cent in themes, and six were reported in the WordPress core itself. Six. The programme everyone talks about is not the risk. The risk is the twelve extensions somebody installed three years ago to make the contact form look nicer.
Then there is the third clock, the quiet one nobody hears. PHP, the language WordPress and most content management systems run on, has fixed end dates: version 8.2 receives security fixes only until 31 December 2026, 8.3 until the end of 2027, 8.4 until the end of 2028 (php.net, Supported Versions). When your host moves on and an old plugin cannot cope with the new version, that is no longer a maintenance job, it is a small project. This is the moment technical debt falls due.
What does running it cost each year before anyone works an hour?
Surprisingly little, as long as you only count the invoices. A .at domain costs 68 euros in the first year and 34 euros in every following year directly from the registry, both net of VAT (nic.at, prices). A hosting package sufficient for a small business site sits at 7 euros a month including VAT with an Austrian provider, on a twelve-month term; the promotional prices currently advertised explicitly apply to the first billing period only (world4you, hosting packages). A consent banner is free from one common provider for up to 50 subpages and one domain, with the smallest paid tier at 7 euros a month (Cookiebot, pricing). The encryption certificate is included with any serious host.
The interesting line is the fourth one, the one that never appears on an invoice: the hours. Doing the maintenance yourself does not make it free. One hour actually worked costs an Austrian business in professional, scientific and technical services 54.90 euros in labour costs (our own Eurostat query, dataset lc_lci_lev, year 2025). One hour of maintenance a month is not a generous assumption for a small site. It is still the largest item on the bill.
One item can be avoided entirely, and by a decision made while building rather than by a subscription: embed no third-party services and you need no consent tool for them. How expensive the opposite route can become is shown by the best known case on the subject. On 20 January 2022 the Munich Regional Court I awarded a website visitor 100 euros in damages because a site loaded fonts directly from a Google server and transmitted his IP address in the process (case 3 O 17493/20). Whether the wave of warning letters that followed will hold up is open: the Federal Court of Justice has referred the question to the European Court of Justice (case VI ZR 258/24). So the legal position is contested; the work is not - serving fonts locally costs half an hour, once.
Who is responsible when it has to be quick?
This is the question most maintenance arrangements fail on, and it has little to do with money. For vulnerabilities that were actually attacked, the Patchstack report gives a weighted median of five hours to the first attempt. Five hours. Against that pace, a maintenance agreement with a monthly patching slot is not a measure, it is a reassurance.
The second figure is more uncomfortable still: for 46 per cent of vulnerabilities no vendor patch existed at the time of disclosure. Almost half the cases therefore cannot be solved by updating at all. What helps in those cases is a decision: switch the extension off for now, replace it, or carry the risk knowingly. That decision needs somebody who is allowed to make it.
In practice that means three things: there is a person with access and a mandate, there is a restored backup rather than merely a created one, and there is a list of what is actually installed on the site. The third sounds trivial and is missing most often. If you do not know which extensions are running, you cannot tell whether a vulnerability notice applies to you.
When is replacing cheaper than maintaining?
When maintenance no longer fails on the content but on the foundation. Four signals point that way, and all four are checkable. First: your host announces a new PHP version and nobody can say whether the site will still start afterwards. Second: an extension carrying essential functions is no longer maintained by its vendor and has no successor. Third: every content change needs an agency, because nobody inside the business can change anything without breaking the layout. Fourth: the site no longer meets a new requirement, accessibility for instance, and retrofitting costs more than rebuilding.
The reverse also holds. A dated appearance is not a reason. Slow loading usually is not either, because it can almost always be fixed in three places. And "we have had it four years now" is no reason at all. The honest question is not how old the site is, but how many hours a year it costs and whether those hours go into maintenance or into repairs. Write both down over twelve months and the decision rests on a number instead of a feeling. How to build that calculation across the whole lifespan is in the glossary entry on total cost of ownership.
Three levers for the next two weeks
1. Write the inventory before you request the next quote. Where the site runs, who owns the domain, which system, which version, which extensions, when the contract ends, who has access. One sheet of paper. That list later decides whether a security notice concerns you or not.
2. Put a number behind each of the three clocks. Technology: how often it is updated and by whom. Content: what has to be rewritten this year. Foundation: which PHP version runs and how long it still receives security fixes. Three lines, and the running costs stop being a feeling.
3. Test a restore, not a backup. Almost every host takes backups. Almost nobody has ever checked whether the site can be brought back from one within an hour. The test costs a morning and is the only item on this list that decides between annoyance and standstill when it matters.
If you have a quote for a new website in front of you right now, we are happy to work through the five years behind it with you. The question afterwards is usually no longer "new or not", but "who looks after it". 🧾