A discovery lab by schwungreclame.nl NL
Schwung.ai · insight

Choose your web system on function, not on price

Most organisations choose their website on price and reach for a template. The better question is how dependent on it you are and what it has to carry. From AI one-pager to Umbraco: a trade-off on function and purpose, not on budget.

"What does a website cost?" It is the first question almost everyone asks, and it is the wrong one. Because the answer that follows sounds tempting: just grab a template, or have an AI builder put one together in an afternoon. Done in no time, a few tenners a month. For the freelancer with a one-pager that is a perfectly fine choice. But the moment a company brings in its customers, its applicants or its revenue through the site, "fast and cheap" is an answer to a question that does not matter. The question that counts is a different one: how much will your organisation lean on this thing, and what does it have to carry?


Price is the wrong first question

Choosing a web system feels like a purchase, and with a purchase you compare prices. But you are not buying a product with a fixed price. You are choosing a foundation that your most important channel will rest on for years to come. Optimizely put it sharply in 2026: the choice is not about features, but about how content moves through your organisation. Who publishes, how often, with what approval, linked to which systems, with what data requirements. Start at budget and type ("WordPress or custom, and what may it cost?") and you have already lost the real question before you begin.

Function and purpose therefore come before price. Not because money does not matter, but because the price is a consequence of what you need, not the other way around. A system that is too heavy for a light site is just as wrong a choice as a template for a site that carries half a company. The art is to first work out where you sit.


Your dependence determines the system

The difference between a light and a heavy choice runs along a single line: how dependent you are on what the site does. That dependence is not a matter of taste or ambition, but of what breaks when the site lets you down.

Low dependence

The site is a business card

A freelancer or a small brand with a one-pager or a brochure site. No customer data, no integrations, a handful of pages. If the site is down for a day, that is annoying, not expensive. A template or an AI builder here is not a compromise, but simply sensible.

High dependence

The site is a channel

A company that draws its leads, applicants or revenue from the website. The site processes data, hangs off a CRM or a recruitment system, and is managed by a team. Here an hour of downtime or a data breach costs real money, and the foundation determines whether you keep control.

Nobody deliberately chooses the heavy end. It creeps in. A brand starts with one page, gains a second language, then an application form with personal data, then forty editors in four countries. By the time someone asks what platform this should actually be, the site already carries half a company, on a foundation that was once chosen for that one product page. The dependence grew; the choice did not grow with it.


The playing field falls into three zones

The market is not a choice between two options. It splits into three zones, and each zone goes with a kind of dependence. Worth knowing where the gravity sits: WordPress runs nearly six in ten sites with a known CMS, so every choice is in practice a choice for or against WordPress. That market share says something about the barrier to entry, not about the fit for your brand.

Zone 1 · fast

AI builders and templates

Lovable, Wix, Squarespace, a WordPress theme. Online in an afternoon, a few tenners a month. Good for a campaign, an experiment or a simple company site. Dangerous the moment customer data comes in: the code and the hosting are not yours, and the liability is.

Zone 2 · design

No-code and tidy WordPress

Webflow, Framer, or a WordPress with minimal plug-ins. Strong brand style, decent load time, manageable by a small team. The honest standard for a brand site without a heavy backend. It breaks the moment you get deep integrations, strict data requirements or a large editorial team.

Zone 3 · infrastructure

Umbraco, Drupal, custom

A foundation you own, on a stack that grows with you. For the site that processes data, links to core systems, is managed by a team and has to last for years. Here you are no longer buying a website, but a business system with a brand face.

Most organisations sit in zone 2 and should stay there. The tipping point to zone 3 is not a matter of prestige. It comes into view the moment the site starts carrying promises it may no longer break: a promise to a regulator, to a customer about their data, to forty colleagues about their work. Count those promises, and you know which zone you are in.


Count what your site has to carry

Instead of starting with a feature list, you start with a short inventory. Five questions lay bare the weight of your site. The more often you answer "yes, and it is growing", the further you shift towards zone 3.

  1. Integrations. Does the site hang off a CRM, a recruitment system, a payment provider? One integration is a setting. Five that have to be correct in real time are an architecture.
  2. Data. Do you process loose contact details, or sensitive personal data? The more sensitive, the more security has to be a foundation rather than a tickbox added afterwards.
  3. Access. Two administrators, or forty editors across eight departments? At scale, "who may do what" is not a detail, but half the system.
  4. Rules. The GDPR and the accessibility law were once the work of the lawyer afterwards. Now they determine the platform choice up front.
  5. Ownership. In three years' time, can you take your content and your customer data to another system? Or are you building a house without a door?

The four heavy dimensions, integration, governance, data and accessibility, each deserve their own look. Because this is exactly where a system that is too light breaks, and exactly where a sales pitch goes quiet.


An integration is not a plug-in

The easiest promise of a light platform is "we'll just link that up with a plug-in". But a plug-in is not an integration, it is a foreign supplier you put into your foundation. You inherit its update rhythm, its security and its survival. In the WordPress ecosystem more than 11,000 new vulnerabilities were found in 2025, of which 91 per cent sat in plug-ins and themes, not in the core. And time works against you: the most heavily attacked flaws are exploited at a median of around five hours after disclosure, faster than an average agency runs its updates.

It can get worse than a forgotten update. In September 2025 a bought-up portfolio of twenty plug-ins, together good for more than 200,000 active sites, was fitted with a hidden backdoor that only activated months later. That is the difference between setting, integration and architecture. A sign-up module that passes encrypted applications through to an ATS, or a form that sends data to a core system and has to do so flawlessly every time, is no longer a page. That is software, and software you do not control yourself is a dependence you cannot oversee.


Governance is a gate, not a guideline

A second thing a light platform does not solve for you: quality drops the moment more people get their hands on it, unless the system holds that back. Every editor who adds a block, every "quick" published change, shifts the site a little away from where it started. That is not a discipline problem you solve with a manual. 81 per cent of companies struggle with content that is not on-brand, while consistent brand presentation can deliver up to 33 per cent more revenue. Brand control is therefore a revenue matter, not a matter of taste.

The difference lies in whether the system has a gate. On a platform with one role, everyone can do everything, and one compromised account causes maximum damage. A foundation with real authorisation separates writing from publishing: an editor may create and save, but not put live, and the rights run down to the level of an individual field. On top of that it keeps a record, per page, of who changed what and when. That is not just tidy, it is what the GDPR (articles 5 and 32) and the upcoming Cybersecurity Act ask of you: being able to demonstrate who touched personal data and when.


EU hosting is a toggle with an asterisk

The moment your site processes personal data, where that data sits becomes a board-level question. And here lies the silent pitfall of the light platforms: "hosted in the EU" is, with many AI builders, a toggle you have to flip yourself, sometimes behind a more expensive subscription, and with some the choice is locked in irreversibly after launch. Worse still, an EU data centre run by an American provider does not close the gap. The legal director of Microsoft France admitted under oath in June 2025 that he could not guarantee against US access to data stored in Europe. Under the American CLOUD Act that holds regardless of where the servers physically stand.

The AI builder sharpens that. AI writes at lightning speed, but in a test of more than a hundred language models the generated code chose an insecure option in 45 per cent of cases, and that error margin does not fall with smarter models. It did not stay theoretical: one app built on such a platform leaked nearly 19,000 records through code with reversed login logic, after which the supplier placed the responsibility with the user. With the EU Cyber Resilience Act (obligations from late 2027) and NIS2, which in the Netherlands becomes the Cybersecurity Act, the liability for digital products is shifting towards the provider, with personal responsibility for directors. "Who builds and hosts your site" has thereby gone from a cost item to a risk decision.


Accessibility belongs in the code

Since 28 June 2025, web accessibility has been enforceable European law. The European Accessibility Act points, via the standard EN 301 549, to WCAG levels A and AA as a legal requirement for, among others, web shops, banking, telecom and transport services. In the Netherlands, five sectoral regulators (RDI, ACM, AFM, ILT and CvdM) enforce it with fines of up to around 900,000 euros. Which regulator depends on the sector: a web shop falls under the ACM, a bank under the AFM.

The cheap shortcut, a widget that promises to make your site accessible in 48 hours, is technically and legally bankrupt. The American regulator fined the best-known overlay vendor a million dollars for precisely that false promise. Automated tools catch at most sixty per cent of the requirements; the rest remains human work. In fact, a layer you stick over poor base code makes it measurably worse. Accessibility is not a repair after the fact, but a property of clean, semantic code. It is in the foundation, or it is not there at all.


AI reaches as far as your authorisation

The newest reason to take ownership seriously is AI. The question is not whether AI may help out in your system, but within which limits. OWASP names "excessive agency" as a core risk of AI applications, with exactly one remedy: let the AI act only within the rights of the user. That is only possible on a foundation that knows about rights at all.

That is where the difference lies. On a rented, stacked platform, AI is a layer you do not place yourself and do not control. On a foundation you own, you clamp AI down on your own terms. Umbraco shows that concretely: its integration for AI assistants gives access to more than 315 functions, but only through a user whose rights you set. The AI can do exactly as much as those rights allow, not a byte more. And well-modelled content delivers a bonus: the cleaner your brand is structured, the more reliably an AI search engine later cites it. Structure is not a technical luxury, but findability.


What it costs, and what it costs twice

Only here does price come into view, and as a consequence, not as a reason. A light platform costs almost nothing until it has to behave like software. After that the laws of software apply. An honest rule of thumb:

€0-50/moan AI builder or template: fine for a light site, a recurring subscription with no end
€15-40ka serious custom site on its own foundation: you pay up front in design and build
15-25%of the build cost goes every year to maintaining a serious system

An open foundation such as Umbraco runs on a free core; your hosting starts at around 45 euros a month on a European data centre, or you host it entirely yourself. But a "free CMS" is not a "free website": the value lies in design, build and management, not in a licence. The most expensive item of all only arrives when the foundation does not grow with you. Whoever built on something that was not chosen to carry typically sits back at the table after three to five years for a full rebuild. Spending that amount a second time, because the first foundation could not keep up, is the real bill of the cheap start.


Why we build on Umbraco

For the heavy side of that spectrum, we at Schwung deliberately build on Umbraco, and not on whatever happens to be ready fastest at that moment. Not because it sounds more impressive, but because it secures exactly the things that a rented platform structurally does not secure.

Yours

Open source on .NET

Umbraco is under the free MIT licence and runs on Microsoft .NET, the stack many organisations already manage. The code belongs to the client, not to us and not to a platform. No licence fee, no subscription that holds the site hostage, no vendor lock-in.

Clear back-end

Building within the brand

Editors assemble pages from pre-designed blocks within a bounded grid. Freedom to publish themselves, without the brand style watering down. With role separation, rights per field and an audit trail that records who changed what.

Grows with you

Expanding without paying extra

Serving headless to an app or a second brand is in the free core. Integrations run through your own code in the foundation, not through a plug-in on top of it. Hosting on a European data centre, and AI that works within your own rights model.

That Umbraco can handle the heaviest requirements is not an assumption. The Council of the European Union chose it, after comparative trials against other systems, to carry all of its content in 24 official languages, maintained by some 800 translators. Closer to home, the NVM, Papendal and the National Ombudsman run on it, and the Netherlands sits in the global top five of Umbraco countries. That last point is also the answer to the honest worry about a less well-known system: if one agency falls away, the brand can turn to dozens of other Umbraco partners. No lock-in, not even on the supplier.

And perhaps most important of all: with us, the brand strategist and the .NET developer sit in the same team. One determines the position and the design, the other makes it technically real, without the handover between an agency that conceives and a party that builds. It is precisely in that handover that, in practice, most quality is lost. That we build on Umbraco is a consequence of that, not the starting point.


Sometimes light is the right answer

Finally, because otherwise this would be a sales pitch: a heavy foundation is not needed for most sites. A brochure site or campaign page without customer data, portal or deep integrations runs excellently on Webflow or a tidy WordPress. A landing page via an AI builder? Go for it. An expensive system guarantees nothing in itself; the quality lies in how something is built and managed, not in the weight of the backend. Whoever chooses Umbraco without real requirements buys complexity they do not use, and makes, on the heavy side, exactly the mistake the template buyer makes on the light side.

The art, then, is not to choose the heaviest, and not the cheapest either. It is to let go of the type of site and the price for a moment, and to count what it really has to carry. At the start, do not ask "WordPress or Umbraco, and what does it cost", but: which promises is this site going to carry, how dependent are we on it, and does the system carry that in its foundation or do I stick it on by hand later? Then the system follows naturally from the purpose, and not from the budget.

You choose a website not on what it costs, but on what it has to carry.

Further reading

Sources