What a web design company does

What the phrase covers, and what it hides

"Web design company", "web development company" and "digital agency" are used interchangeably by almost everyone who searches for one, and the suppliers answering those searches do very different things. The phrase covers a one-person freelancer assembling a template on a Sunday, a studio of three or four people building from scratch, and a hundred-person agency where the people at the pitch are not the people who build.

None of those is the wrong answer. They are priced differently, they fail differently, and they suit different jobs. What matters is knowing which one you are talking to, because the sales conversation sounds nearly identical in all three cases.

The single most useful question you can ask a supplier is which of the people in the room will write the code. If the answer is nobody, that is not disqualifying, but it changes what the rest of the conversation is worth.

The work, in the order it actually happens

Design is the visible part and the smallest part. A build that goes well spends most of its time on decisions made before anything is drawn, and on making the result durable afterwards. Roughly, in order:

1. Working out what the site is for. Not the pages, the outcome. A site that has to book appointments and a site that has to make a case for a large purchase look nothing alike, and confusing the two is the most expensive mistake available.
2. Deciding the content model. What kinds of things exist (a service, a case study, a location, an event), what fields each one has, and how they relate. This is the decision that determines whether the site can grow later or has to be rebuilt.
3. Structure and navigation, which is where most search visibility is won or lost. A page nothing links to is a page nobody finds, whatever is written on it.
4. Design, in the sense of type, spacing, colour and the specific screens. Real content in the design, not placeholder text, because layouts that only work with tidy copy do not survive contact with the actual copy.
5. Build. The part everyone pictures, and typically a third of the effort at most.
6. The content system, so somebody who is not a developer can change the site without breaking it or filing a ticket.
7. Performance, accessibility and the technical search work, which are cheap while the site is being built and expensive to add afterwards.
8. Handover: accounts, code, domain, and enough documentation that the next person can pick it up.

Steps two and six are the ones most often skipped, because neither is visible in a pitch. They are also the two that decide whether you are still happy with the site in three years or paying somebody to rebuild it.

What the work is really for

We have a measured answer to this rather than an opinion. Our Pune business survey looked at 9,779 businesses and fetched every website on record. 983 of them had a site at all. Here is the state of those 983:

Only 49.1% were working and current. About 49.2% were live but dated, failing to load correctly, or a parked domain with nothing behind it. These are not businesses that never commissioned a website. Every one of them paid somebody, once.

That is the actual job. Getting a site launched is not difficult and has not been difficult for a decade. Getting one that still works, still loads, and can still be edited by the client three years after the invoice is paid is the part suppliers differ on, and it is almost never what the sales conversation is about.

The platform mix in that survey is worth knowing too: of the 273 sites where we could identify a platform, 83.2% were WordPress. A large share of the dated and broken sites are WordPress installs that stopped being updated. The platform is not the problem. Nobody being responsible for it is.

Rebuild or template, and how to tell which you are buying

Both are legitimate. A template is the right call for a business that needs to exist online this month and has no unusual requirements. A ground-up build earns its cost when the site has to do something specific, when the brand has to be distinctive, or when the content will grow in ways a template's fixed structure cannot follow.

The problem is being sold the second and given the first. These questions separate them, and none of them are hostile:

• What is this built on, and can I see another site you have built on the same thing? Two sites that look identical under the styling is your answer.
• If I want a new kind of page next year, one that does not exist today, what happens? A rebuild is a real answer. A shrug is not.
• What can I change myself without calling you, and what needs a developer?
• What is the plan for updates after launch, and what does it cost to do nothing?
• Who owns the code, the domain and the hosting account when we are finished, and whose name is on the registration?
• What happens if we stop working together in a year? A supplier who has thought about this answers immediately.

The last two matter more than they sound. A site you cannot take with you is a rental, whatever the invoice called it, and the moment you discover this is always the worst possible moment.

What you should be handed at the end

A finished engagement should leave you holding everything needed to keep the site running without the people who built it. That means the domain registered in your name, the hosting and analytics accounts in your name with you as owner rather than a collaborator, the source code, and access to the content system with a real administrator account.

It should also leave you with enough written down that somebody else could take over. Not a manual nobody reads, but the specific things that are not obvious: where things are deployed, what breaks if a particular key expires, and which decisions were deliberate.

We publish the full checklist we work to, so it can be used against us as easily as by us.

Where suppliers genuinely differ

There is no ranking here. Each column is a real cost and each is worth paying in some situations. What goes wrong is paying for one shape and receiving another, which is why the questions above are about mechanics rather than about promises.

What this does not cover

• The condition figures describe businesses recorded in OpenStreetMap in one district of one city. Coverage varies by area and by sector, a business that is not mapped is not in the survey at all, and we would not claim the shares hold anywhere else without measuring it there.
• Classifying a site as dated or broken is a judgement made by an automated fetch and inspection. It catches sites that fail to load or that use clearly superseded technology. It does not catch a site that loads perfectly and is simply bad, which is a real category we cannot measure.
• The ordering of the work is how we run an engagement. It is not an industry standard and there is no body that defines one. A supplier working on larger projects, or through a procurement process, would order it differently and would be right to.
• This page contains no prices. That is a decision rather than an oversight, and it applies to our rates and to anybody else's.
• The comparison of freelancer, studio and agency is a description of structural trade-offs, not a measured study of outcomes. Good and bad examples of all three exist and we have not counted them.

Sources

• Pune business survey, 9,779 records sourced from OpenStreetMap across the Pune district. Every website on record was fetched and inspected, then classified by condition. The condition figures on this page are the share of the businesses that had a website at all, recomputed from the source at publication time rather than typed. Run: scripts/pune-aggregates.mjs, 2026-08-30 14:14 UTC.
• What Scene project brief and handover structure. The ordering of the work and the handover list are the stages and deliverables we actually issue, defined in lib/documents/defs/engagement.ts and published in full at /resources/what-you-get-at-handover. Run: documents/transactional/project-brief, version 2026.1.
• OpenStreetMap copyright and licence, OpenStreetMap Foundation. Retrieved 23 August 2026.

Revisions

• 31 August 2026 First published.

This page is revised in place rather than replaced, so its address does not change.