What you really pay for a website in Switzerland

Two proposals land in the same email inbox. One quotes CHF 500, the other CHF 35,000. Identical brief, identical company, identical three-page requirements list.

The first appears too good to be true, while the second feels like someone added an extra zero by mistake. Neither proposal explains where those numbers come from, yet you have to decide between them.

I have been building websites for Swiss businesses for fifteen years, almost always solo. This is the question I get asked most frequently—usually cautiously, by someone who suspects they are about to overpay without being able to prove why. The reality fits in one sentence: what you pay for has almost nothing to do with what you see on screen.

Why pricing per page makes no sense

Ask for a quote and you will often receive a table: homepage, about, services, contact, each multiplied by a standard unit price. It looks tidy, it feels reassuring, and it was borrowed from the printing industry, where a physical sheet was a genuine unit of cost.

A page is not a unit of work

A single custom page with an interactive configurator, a booking flow, and dynamic pricing logic takes me weeks to engineer. Twenty static pages of text and imagery can take three days. Page count tells you nothing about what must be architected, developed, tested, and maintained.

When an agency bills per page, they are either building the exact same boilerplate regardless of client needs, or hoping you will not ask what sits underneath. The question that matters is different: what is the most technically demanding part of this site, and who is actually building it?

The coordination tax between you and the work

In a structured traditional agency, a portion of your budget finances technical execution, and the rest finances the bureaucracy surrounding it: project managers, account executives, creative directors, and eventually a junior contractor at the end of the chain who writes code.

That organization exists for a reason; large teams require coordination. But somebody pays for that machinery, and on an SME project, that somebody is you. I spent years working inside that model in Berlin: a decision that takes me ten minutes today required a week of meetings, and the resulting website was no better for it.

This is not an argument against agencies; they remain the right choice when an enterprise build exceeds what one person can manage. It is an argument against paying for that structure without knowing you are funding it.

1. You pay for an engineered system, not a theme

A purchased commercial template with your logo dropped on top does not justify a five-figure invoice. What justifies a real budget is software built specifically for your operations that did not exist before.

Where the budget should actually go

Off-the-shelf themes are built to cover every conceivable use case, from a neighbourhood bakery to an international law firm. Consequently, they bundle carousels, third-party plugins, and legacy scripts you will never use, all of which load in your visitor's browser. That means slower pages, degraded Core Web Vitals, and an added vulnerability when a plugin abandons maintenance.

What you should be paying for is the inverse: bespoke components designed for your workflow, clean code you or your next developer can easily maintain, and a fast site because nothing redundant is loaded. Most of my engineering time on a build is not spent adding features, but stripping out everything that cannot justify its presence.

2. Technical SEO is not an optional line item

If a proposal lists "SEO optimization" as an optional add-on you can uncheck to meet your target budget, read the rest of the contract with extreme caution. Performance and accessibility are not features you polish at the end; they are how the system is engineered from day one.

It lives in the build, or it does not exist

Crucial architectural elements can only be executed during initial development:

• A semantic heading hierarchy determined by document structure rather than visual styling
• Clean Schema.org markup in JSON-LD so search engines and AI assistants understand your business entities
• Correct hreflang tags connecting your English, French, and German localized routes

That last requirement matters more in Switzerland than almost anywhere else, because a Swiss website is frequently three sites in one. Misconfiguring localized routing means serving German pages to prospects in Lausanne. I have been hired to rescue exactly that mistake, and fixing it after launch is always more expensive than doing it right on day one.

The same rule governs being cited by ChatGPT, Claude, and Perplexity: AI models evaluate semantic structure before prose. Without clean structure, your site remains invisible to them—and that represents an expanding share of how Swiss clients discover partners today.

3. Count the intermediaries

Every handoff along the chain loses fidelity: sales to designer, designer to developer, developer to the maintenance team. In isolation each handoff seems minor, but combined they compound into project delays, diluted results, and a heavier invoice.

The agility of direct senior access

You explain your business requirements once. The person designing the interface is the person writing production code, ensuring nothing gets compromised between the mockup and how the site performs on a mobile screen. Technical decisions take an afternoon rather than a two-week sprint.

When something needs to be adjusted two weeks post-launch, you message the person who engineered the system directly, without opening a support ticket or negotiating a scope change. There is a trade-off, and it should be stated openly: a solo studio has an absolute ceiling on concurrent projects. For a Swiss SME website, that is rarely a bottleneck. For an enterprise platform across fifty markets, it is.

What remains after launch

The real divide between a cheap website and a well-engineered site emerges in year two. The cheap site works until an unmonitored update breaks the checkout form, or until you decide to add a new language and discover the underlying CMS cannot handle it.

Then you are forced to rebuild from scratch, paying twice. Nobody warned you about that second invoice, because it was never listed in the initial estimate: it accumulated silently, line of code after line of code.

Technical debt is the cost missing from every quote

A properly engineered site can be modified, expanded, and handed over to another developer without an emergency rescue operation. You own the code outright, the architecture accepts additional languages, and you can migrate whenever you choose without being locked into someone's proprietary retainer.

That is the order in which I build, and it dictates the price long before design begins: architecture and constraints first, execution speed second. An honest web development budget funds that foundational engineering. Skip it, and you have not saved money; you have merely deferred the expense by twenty-four months.

What to ask before signing

Ask who actually writes the production code, ask what happens if you decide to leave, and ask to inspect their proudest recent site on a mobile phone over a cellular connection. The answers will reveal far more than the number at the bottom of the quote, and they cost nothing to obtain.

👉 Send me your project brief, and I will give you a transparent technical scope, including the parts you do not need. Get in touch