Commissioning a business website: what to check before you sign.

The digital brochure: the mistake that gets signed most.

Web design proposals are almost always judged on the only thing you can see before paying: the mockups. That's understandable, and it's the root of the problem, because what makes a website work doesn't show up in a mockup.

The result has very recognisable symptoms. The company that has had three websites in five years, all still half alive. The form that has been broken on mobile for months without anyone noticing. The website that cost twelve thousand euros and nobody can say what it returned, because it was never measurable.

In every one of those cases the same thing was commissioned: a pretty website. And pretty is the only thing that costs nothing to promise. The expensive part, what separates a website that works from a brochure, sits in three things that don't show up in the presentation and share one uncomfortable property: they can't be added later.

The three things you can't add later.

Speed. A website that takes six seconds to load on mobile loses the visit before it has shown the design. And speed is not a final optimisation: it's the consequence of first-week decisions, of the stack chosen, of how images are handled and how many scripts each page loads. The good news is that it's entirely demandable: PageSpeed above 90 on mobile and Core Web Vitals in green, checkable yourself with a free public tool. Get it in writing.

Technical SEO. The structure, the schema, the sitemap, the hreflang if you work in more than one language: either they come as standard, designed with the website, or they arrive at the end as a patch. If the proposal treats SEO as an extra with its own line in the budget, you already know where it sits on the priority list. A website without technical SEO is not a cheaper website: it's a brochure with no printing press.

Measurement. Analytics and tag manager set up from day one, forms with anti-spam connected to your CRM, and an agreed definition of what counts as a contact. Without this, six months from now you'll be having the same conversation about the new website that you had about the old one: "it seems to be going well". Seems is not data, and without measurement there is no return to defend.

The six questions that filter a proposal.

Take them to your next meeting. They work on me too.

1. How fast will it be on mobile, and how do we check? The good answer has a number and a public tool. The bad one is "it will be very fast".

2. What technical SEO comes as standard? Schema, sitemap, hreflang if there are languages. The important words are "as standard": if it's separate, it comes later, and later is too late.

3. How will we know if it works? Which event counts as a contact, where each lead lands and who looks at it. If the proposal doesn't talk about measurement, it's promising a website you'll never be able to hold to account.

4. How many design iterations are included, and who decides? Two or three well-directed iterations beat twenty-five rounds of opinions. A process with no limit on revisions is a deadline with no limit on months.

5. Who owns all of this when we're done? Domain in your name, hosting you can move, documented code another developer could maintain. If touching your own website means going back to whoever built it, you haven't bought a website: you've rented a dependency.

6. What happens on launch day? Migration, redirects for every old URL, and monitoring. A new website that launches new URLs without redirecting the old ones throws away everything the previous one had ranking.

And a note on timelines, because they filter too: a corporate website of eight to twelve pages takes four to six weeks from kickoff, not six months. If someone promises much faster, check what they removed from the list above to get there.

If you already have a website, measure before commissioning.

The answer to "I need a new website" is sometimes no. If what fails is one or two specific things, fixing them costs a fraction of the project and saves you the months of transition.

You don't need opinions to find out: you measure. There's a free 14-point website audit that analyses your site with real data, speed and SEO included, and a guide to auditing it by hand in an hour if you'd rather do it yourself. With that diagnosis in front of you, the conversation with any provider changes: you're no longer buying blind, you're comparing against a list of specific failures.

Commission results, not decoration.

This is how I approach web design: websites that work, not just decorate, with technical SEO and measurement as standard, and with the condition that your team can maintain them when I'm done.

The pretty website and the website that works are not incompatible, and the good ones are both. But only one of the two can be demanded by contract. It's the one almost nobody asks for.

Frequently asked questions.

WordPress, Webflow or Astro for my company website?

It depends on the case. If you have a team that will maintain content and you need a blog, a well-built WordPress is a good option. For corporate websites that rarely change, a static stack like Astro or Hugo is usually better: faster, cheaper to maintain and more secure. Be wary of anyone who gives the same answer for every case: the tool gets chosen after understanding the problem, not before.

How long does a business website really take?

A corporate website of 8 to 12 pages takes 4 to 6 weeks from kickoff, not 6 months. A campaign landing page, 7 to 10 days. If you need it faster than that, you probably don't need a new website: you need to fix the one you have.

Will I be able to maintain the website without the provider?

It should be a condition of the project, not an extra: a CMS your team can use without panic, clear documentation and code another developer could maintain. No lock-in. Ask what would happen if you switched providers tomorrow: a calm, specific answer is a good sign, and discomfort is also an answer.

Should I rebuild my website or fix the one I have?

Measure before deciding. Run your site through the 14-point audit and see where it fails: speed, SEO, forms, measurement. If one or two specific things fail, fix them and save yourself the whole project. If the foundations fail, rebuilding is cheaper than patching.