How to build a website — four decisions, the layout, and what really stretches a project

There are hundreds of guides on how to build a website and most describe the same thing: pick a name, buy hosting, install a system, add content. That is not untrue — it is a list of activities rather than an answer to the question a company is actually asking. The question is: what do I have to settle so I do not pay twice for the same thing.

This text is written from the agency's side of the table, so it also carries things guides usually leave out: how long it really takes, what eats that time, and which part of the work sits with you.

Four decisions taken before the first screen

A website project is settled in four answers, and each of them is cheaper before the work starts than during it.

Why this site exists. Not "so the company is online", but: what has to happen for it to count as successful. An enquiry? A phone call? A booking? A specification download? That answer decides the home page layout, the number of forms and whether you need a blog at all. A site with no named goal always comes out as a catalogue of everything the company does — and does none of it well.

Who it speaks to. You write differently for somebody who knows the industry and is comparing three suppliers than for somebody meeting the problem for the first time. That settles vocabulary, the length of the copy, and whether the site needs an educational section or, on the contrary, works better with as little explaining as possible.

Who will change it. A question that looks technical and is organisational, and it rules out more options than any other. If the content changes once a quarter and one person does it, almost anything will do. If it changes weekly, three people from different departments do it, and a mistake in the price list costs real money — a narrow group of solutions remains, and it is that group which sets the budget. We cover the technical side separately, in the text on choosing a platform.

What happens if the decision turns out wrong. Every choice of technology is simultaneously a choice of how costly it is to leave. Some solutions hand your content back as one file; others hand back nothing beyond bare text. That line appears in no proposal and is settled on the day the contract is signed.

It is worth seeing how those answers turn into specifics, because this is not a theoretical exercise. If the goal is an enquiry, the form sits on every service page rather than only under "Contact" — and it has as many fields as you genuinely need for a first reply, usually three. If the goal is a phone call, the number goes into the header and has to be tappable on a phone, while the form moves into the background. If the goal is a booking, the entire home page leads to the calendar and everything else is on the way there, not beside it.

The same logic applies to the audience answer. A site written for somebody comparing three suppliers needs the specifics that settle it — scope, dates, references — because that person already knows what they want. A site written for somebody meeting the problem for the first time has to name the problem before it sells the solution. Mixing the two modes produces copy that is too shallow for one group and incomprehensible to the other.

Only after those four answers does a conversation about how the site should look make sense. Before them, every mockup is guesswork.

What has to be on it — and how we know

Here the generalities end. What follows recurs in our company implementations regularly enough that we treat it as the starting point, with departures requiring a justification.

One headline instead of a slider. A slider on the home page is still a standard request and it is an expensive one. The mechanism is simple: the largest element visible on arrival is often a slider image, and the browser does not know in advance which of three or five slides it will show — so it downloads more than it needs, and the moment the visitor sees content arrives later. The second cost is editorial: a slider is a promise that you will say five things at once, and in practice it means you say none of them, because nobody waits for the third slide.

We have our own figure for this, though it has to be read with a caveat. Our services page — one static headline, one call to action — measures 0.99–1.02 s LCP. Our home page, heavier and richer in elements, measures 1.67–1.72 s. That is the median of five runs each, taken with our own measurement procedure rather than a single reading from a free tool. The caveat travels with the number: below half a second of difference we do not make decisions on LCP alone, because run-to-run spread is of that order. Here the difference is around seven hundred milliseconds, so it is real — but it measures two of our pages, not the market, and we do not pretend otherwise.

For the record: 2.5 seconds is the line below which Google treats this metric as good — both of our pages sit inside it with room to spare. The difference between them is therefore not a difference between "good" and "bad" but between two versions of good, and that is exactly how it should be read. The threshold is defined in the Core Web Vitals documentation.

How to check this yourself, without taking anyone's word for it: open the site in a browser, turn on developer tools, throttle the connection to a mobile profile and reload. What matters is the moment the largest element visible without scrolling appears — usually the header image. If it is waiting on three images of which you will show one, you already know where the time went.

Contact visible without hunting. Phone number and address in the header, not only on the "Contact" page. In service businesses this is the most-used element of the entire site, and it is often the hardest to find.

Proof the company exists and did this work. Photographs of your own projects, not stock. The company name in the footer together with its registration details and address. The scope of services spelled out, instead of the phrase "comprehensive solutions". This is the part that cannot be bought along with the site, and the most common reason implementations stall.

One path to action, not five. If the home page carries four equal buttons, the visitor picks none of them. Choose the one action that should happen most often and make it the most visible; the rest can be a link in the text.

A form shorter than you would like. Every additional field is another reason to give up. A first contact needs as much information as it takes to call back — usually a name, a channel and one sentence about the matter. The rest you settle in conversation. Fields for company name, tax number, "how did you hear about us" and budget, added just in case, cost you enquiries and rarely change what you do with the first reply.

A form that actually arrives. This sounds trivial and it is the most commonly skipped test at handover. Sending a message and seeing a "thank you" proves nothing — the proof is a message in an inbox somebody reads daily. Forms can quietly land in a spam folder or at a former employee's address for months before anyone notices, because no enquiries looks exactly like no interest.

Pages that have to exist regardless of industry: the home page, services split into separate pages rather than one list, an "About us" with faces and names, contact with a form and registration details, and a privacy policy. Everything beyond that depends on the answer to the first of the four questions.

How it gets built: from brief to handover

The order we work in, and what sits on your side at each stage.

Brief and agreement. A conversation about goal, audience and scope, ending in a document both sides sign off on. It is the only moment when changes are free. We set out what belongs in it in a separate text on the brief.

Wireframe. Layout without colours and without photographs — blocks and their order. Ugly on purpose, because an ugly wireframe produces a conversation about structure while a pretty one produces a conversation about the shade of a button. We describe what it is and why it exists alongside wireframes.

Visual design. Only now colours, typography and photographs. At this stage you approve the appearance, not the content — the content was in the brief.

Build. Coding, entering content, configuring the system. On your side: delivering the final materials and access credentials.

Stages get compressed — usually the first two, because they show no progress. The result is predictable: a skipped brief means the decisions get taken during the build, at the most expensive possible moment; a skipped wireframe means the first conversation about layout is a conversation about a finished visual design, on which reordering blocks means redrawing. Both stages together take less time than the single round of corrections they cause when they are missing.

Testing and handover. Checking on phones, walking the path to purchase, testing the forms — meaning whether the message actually arrives, not whether the form displays a confirmation. We describe how to test a site so the result means something in the text on testing.

How long it really takes — and what eats that time

A typical company website takes us two to eight weeks. The spread is wide because it does not depend mainly on the number of pages.

Three things stretch projects most often, and all three sit on the client's side. We do not write this as a complaint — we write it because being aware of those three items shortens a project more than any optimisation on our side.

Copy and photographs that never arrive. The most common cause of a stall. The site is ready, waiting on service descriptions and team photographs, and those need somebody's decision and somebody's afternoon. A project can stall on this for longer than the entire build took. There is one remedy and it has to be agreed at the start: either the material is ready before work begins, or preparing it is a separate line in the scope.

An approval that circulates. A wireframe sent to the client comes back with comments after ten days, because three people had to respond to it and two were on holiday. Every such loop is a week. It helps to appoint one decision-maker and agree a response date before sending — not because it rushes anyone, but because it names the expectation.

Access to systems we do not have. Keys to the CRM, logins to the booking system, access to the domain panel, an account with the newsletter tool. Each of them tends to sit with a different person or with a previous supplier who is hard to reach. This is the item worth starting on the day the contract is signed, not in the week of launch.

A project where those three things are prepared lands in the lower half of the range. A project where they are not can run past the top of it — and that usually has nothing to do with technology.

It works the other way too, and that is worth saying, because conversations about deadlines usually end in a list of risks. Projects that come down to two weeks generally share three features: the material was ready before the start, decisions were taken by one person, and the scope did not grow along the way. None of those three depends on the agency — which is exactly why we describe them here rather than in a proposal.

Doing it yourself or commissioning it — and what that really changes

Some companies reach a question at this point that guides rarely put plainly: should we not just do it ourselves. It is a sensible question and the answer is not automatically no.

One thing settles it, and it is not the budget. Building it yourself does not save money — it converts money into your time and your attention. If that time exists, the arithmetic works. If it does not, the project does not cost less; it takes longer and more often ends halfway.

Three questions settle it:

How many hours can you realistically give this in a month? Not how many you would like — how many are actually left after what you already do. Below ten hours a month, a self-built company site usually does not reach the end, because you come back to it every second week and each time have to remember where you left off.

What happens when something stops working? The form stops sending, the certificate expires, the site starts loading more slowly. Commissioned, that is somebody's phone call. Self-built, that is your evening, usually at the worst possible moment.

Is this site meant to be a sales argument? If a client judges your company by it — and in services they usually do — then the difference between "works" and "convinces" is what you are paying for. If the site is mainly an address where you can be found, that difference matters less.

If the answers point to doing it yourself, you have three routes and each has its own text: a subscription website builder if speed matters and a subscription does not bother you; static HTML if there are a handful of pages and the content does not change; or a content management system if you intend to develop the site.

What happens on launch day

Launching a site is not a button press. It is a change in a global network of addresses, and it takes time.

Repointing the domain. In the domain panel you change the records so they point at the server hosting the new site. The change is not instant: every record carries a TTL, which is — literally, per the domain name system specification — "the time interval that the resource record may be cached before the source of the information should again be consulted" (RFC 1035, section 3.2.1). Until that interval elapses, part of the internet still sees the old site and part already sees the new one — and that is not a fault, it is how the network works. In practice it means anything from a quarter of an hour to most of a day, depending on the TTL that was set beforehand.

The practical conclusion: if you have a deadline, lower the TTL a few days before the move. Then on switch day the world forgets the old answer faster.

URLs from the old site. If the previous site was in search results, its addresses carry value that is easy to throw away. Each one needs a redirect to its new equivalent — not to the home page, because redirecting everything to the home page is read by a search engine as content removal. The list of old addresses is pulled before the switch, not after.

The certificate. The site has to answer over HTTPS before you invite anybody to it. We settle which certificate is enough and when you have to pay more in a separate text.

The first hours. Check the site from a mobile network, not only from the office — sometimes that is the only way to see what somebody outside sees. Send a message through the form and confirm it reached an inbox somebody reads. If the old site had addresses in search results, make sure they lead to new equivalents rather than into nothing.

The first week. Turn on analytics before you promote anything — otherwise the first days, usually the most interesting, are lost for good. Submit the site to the search engine's webmaster tool and check after a few days whether the addresses are visible there; the site not appearing in results after a week can be normal, but it not appearing in the submission tool is not. And write down somewhere what the starting state looks like: how many pages, what load time, how many enquiries a month. In six months that will be the only reference point you have.

What this text does not settle

Four questions come back regularly in this conversation and each is covered better where it belongs.

What it costs. The most frequently asked question in this whole family, and we deliberately do not answer it here with a single number, because the arithmetic has two parts — the build and what starts accruing monthly after launch. The full breakdown is in the cost section, and how to read a proposal is in the text on quotes.

Whether it can be done for free. It can, by three routes, and each ends somewhere specific. We describe them separately, including the moment free stops being enough.

Whether plain HTML is enough. A sensible question at genuinely small requirements, and it has its own text, with the boundary past which doing it yourself stops paying off.

Where to start if the site already exists. That is a different conversation from building from scratch and it runs through strategy rather than through this text.

Where these numbers come from

• LCP of 0.99–1.02 s for the services page and 1.67–1.72 s for the home page — our own measurement of both our pages, the median of five runs, procedure in docs/perf-measurement-sop.md, results from 18 August 2026. The caveat comes from our own documentation: below 500 ms of difference we do not decide on LCP alone, because that is the spread of the measurement.
• Delivery in two to eight weeks — our projects, not a market benchmark. The range is wide because it depends on the three things listed above rather than on technical scope.
• The three most common causes of delay — an observation from our implementations, presented as an observation and not as a statistic. We have not measured it numerically and we give no percentages.
• DNS propagation and TTL — how the domain name system works; the duration depends on the TTL set before the change and is not something a hosting provider can shorten after the fact. The definition of the TTL field comes from the primary source: P. Mockapetris, "Domain Names — Implementation and Specification", RFC 1035, November 1987, section 3.2.1.
• The 2.5 s threshold for Largest Contentful Paint — not our number but Google's definition: "Largest Contentful Paint (LCP)", web.dev, updated 4 September 2025. A good value is 2.5 s or less, a poor one above 4.0 s, measured at the 75th percentile of page loads. We cite it so our two measurements can be related to something — not to suggest that either of our pages is slow.