Web design and web development: what you are actually paying for

Almost every website quotation I am asked to read in Kuwait contains the same line: website design and development, followed by one number. Two kinds of work, two risks, two ways of going wrong, priced as though they were one thing.

That line is why quotes for the same brief differ by a factor of ten. It is not that one supplier is greedy and another cheap; they are quoting for different halves of the job, and nothing says which half. The distinction is not vocabulary. It decides who you hire, what can safely wait, and which parts of the estimate are a guess.

Design is a set of decisions, not a set of pictures

The common understanding is that design is how the site looks: colours, fonts, a header, a hero image. That is the last five per cent, and the least consequential of it.

Design is the decision about what each page is for, what a visitor must be able to do on it, what order the information arrives in, and what is left out. Someone lands on your services page from a phone, halfway through comparing you against two competitors: what must they see first, and what can wait? No amount of code answers that.

The Nielsen Norman Group’s definition of user experience refuses to stop at the interface for this reason: a beautiful screen over a system that cannot answer the question is still a bad experience. The UK’s guidance on service team roles makes the same separation, and hires a designer before a developer — because until the decisions exist there is nothing worth building.

What you pay for on the design side, in the order it happens:

• What the site is for. Which enquiries you want, from whom, and what a visitor must be convinced of first. If nobody has that conversation, everything after is decoration.
• Structure. What pages exist, what each is responsible for, how someone moves between them. This decides whether search engines and assistants can make sense of the site at all.
• The words. Real copy, not placeholder text. A layout drawn around invented text collapses when the real sentences arrive, which is why “we will add the content later” is the most expensive sentence in the project.
• Screens. Each page at three widths, the states when a form is wrong or a list empty, and a system so the twentieth page still looks like the first.

Development is what happens when those decisions meet a machine

Development makes those decisions real, and splits into a visible half and an invisible one. Buyers price the visible half and are surprised by the other.

The visible half looks like the design: pages rendered in a browser, responsive, right fonts, menu working. On a straightforward site that is a small share of the effort. The invisible half is everything a visitor never sees and every buyer eventually pays for:

• How content is stored and edited. Whether your team can add a case study next year without calling anybody — a site you own against one you rent from whoever built it.
• Forms, and what happens after submit. Where the enquiry is stored, who is notified, whether it survives a mail failure, what stops the spam.
• Anything that talks to something else. A gateway, a booking system, an accounting package, a CRM. Every integration is a separate project wearing the costume of a feature.
• Performance. Not an opinion, a measurement. Google’s Core Web Vitals set thresholds: largest contentful paint within 2.5 seconds, interaction to next paint under 200 milliseconds, layout shift at or under 0.1, at the 75th percentile of real visits.
• Accessibility. Also not an opinion. WCAG 2.2 became a W3C Recommendation in December 2024, at levels A, AA and AAA. Retrofitting costs several times what building to it costs.
• Security and updates. Somebody applies them. If the contract does not say who, nobody does.

The clearest illustration lives inside WordPress. Its theme handbook is explicit that themes control presentation, plugins control behaviour, and functionality must never live in the theme — because if it does, changing how the site looks destroys what it does. That is the boundary in your quotation, drawn in code.

Which half is expensive depends entirely on what you are building

There is no general answer to that question. There is a clear answer per project, and it falls into three shapes.

A site that explains a business. Twenty pages, a contact form, no transactions. Almost all the difficulty is design, and most of that is the words; the build is well-trodden. A supplier quoting a large build figure here is either building something you did not ask for or has misread the brief.

A site that takes money or bookings. The balance inverts the moment a transaction is involved. Payments, stock, refunds, failure states, receipts, and the checks a bank imposes before you go live — none of it visible in a mockup. On a Kuwaiti store the gateway decides the timeline, and it is a requirements problem before a code problem: what KNET actually requires before your store can take a payment.

An application with accounts and roles. Anywhere users log in and see different things. Design still matters, but rules dominate the cost: who may see what, what happens to data, what the system does when two people edit one record. Quoting this as a website is how projects double.

Before reading a price, decide which of the three you are commissioning. If the quotation’s shape does not match, the supplier is answering a different question.

Why the quote hides the split, and what should replace it

Suppliers merge the two because one figure is easier to sell and harder to argue with; a split invites the buyer to delete a line, usually the one that would have saved them later. But an undivided price hides the two things you most need to know. Whether the estimate is a guess — design on a defined brief is fairly predictable, integration is not, and merging them merges your certainty with their uncertainty. And what happens when something changes, because if the price is one number, every change is a negotiation over the whole number.

What I would want instead, and it need not be complicated:

1. Discovery and structure — what the site is for, what pages exist, what each must do.
2. Content — who writes it, in which languages, by when. Named, with a date, or it will not happen.
3. Design — how many layouts, at how many widths, with how many rounds of revision included.
4. Build — by capability, with every integration itemised rather than folded into a total.
5. After launch — updates, backups, monitoring, and who is called when it breaks at nine at night.

A supplier who will not produce that has not planned the work — the same test applied to the whole document in how to read a website proposal in Kuwait.

The seam between them is where projects actually fail

In thirty years the failure I have watched most often is neither bad design nor bad code. It is the gap between them, and it has a shape.

A design is approved as a set of images. Nobody asks what happens when the client name is four words instead of two, the list is empty, the price is missing, or the page reads right to left. The developer meets each of those alone, at speed, and answers by whatever is quickest. Those improvised answers are what the site becomes.

In a bilingual market that is not an edge case. An Arabic interface is not an English one with the text swapped: the layout mirrors, dates and numbers behave differently, line lengths change, and a design drawn only in English has never met the language half your visitors read. Nor is a form translated by translating its labels — the errors, the confirmation and the notification email are development, decided at the seam.

Two habits close the gap and neither costs much. Build the hardest page first rather than the prettiest, and review the real thing in a browser, on a phone, with real content, before sign-off.

What to ask before you sign

Five questions that sort suppliers faster than a portfolio does.

1. Which line is design, which is development, and what does each contain? Hesitation here is the answer.
2. Who writes the content, and in which languages? If the answer is “you do”, the timeline is fictional.
3. What can I change myself after launch, and what needs you? The gap between the two is what you pay for every year.
4. Which parts of this estimate are least certain, and why? An honest supplier names the integration. One who says everything is certain has never built one.
5. What happens in month thirteen? Updates, patches and small changes are why companies rebuild every three years instead of maintaining what they have, and why somebody has to own the decision — the argument in the technology decisions a Kuwaiti company keeps deferring.

You are not buying pages. You are buying decisions, an implementation of them, and somebody’s continued attention. A quotation naming all three is a plan; one naming none is a number, and a number is not something you can hold anyone to. That distinction is most of what I do when brought in on website design and build, and the same question underlies WordPress design and development: not what the site looks like, but which decisions have been made, and by whom.

Frequently asked questions

Can I hire a designer and a developer separately?

Yes, and on larger projects it is often better. The condition is that somebody owns the seam. If the designer hands over images and leaves, the developer decides your empty states, error messages and Arabic layout alone. Either the designer stays through build, or one person is accountable for the finished thing.

Why do quotes for the same brief differ so much?

Usually because they are not for the same work. One assumes a ready-made template with your logo on it, another original structure, original copy and two integrations. Make each supplier itemise design, content, build and aftercare separately and the difference is usually obvious.

We already have a design from another agency. Is that enough to start building?

Only if it includes the states, not just the screens. Ask what the page looks like with no results, with an error, with a very long name, and in Arabic. If those are missing, the remaining decisions get made during development, at the speed of a deadline.

Does a template mean we can skip the design cost?

It removes the drawing, not the deciding. You still choose what the site is for, what each page must do and what the words say, and a template constrains those choices rather than making them. Templates suit the first shape of project and rarely survive contact with a transaction.

Which half should we spend more on?

Whichever half carries the risk. If the site explains a business, the money belongs in structure and words. If it takes payments or logins, it belongs in the build, and an elegant design over a fragile transaction is the worse outcome. The mistake is spending evenly out of fairness rather than deliberately out of judgement.