Key Takeaways
- A web development engagement has eight parts: discovery, design, build, content, integrations, testing, launch and aftercare. Quotes routinely include four of them and imply the rest.
- The single question that makes quotes comparable: which of those eight are included, and who does the ones that are not?
- What you should own at the end: the code in your repository, the hosting in your account, the domain in your name, and the content in a portable format. If not, leaving later is a rebuild.
- The clearest quality signal is not a portfolio. It is whether a supplier will show you work in progress every week and tell you what went wrong.
Web development services covers everything from a five-page brochure site to an application with a login. Because the label is so wide, two quotes at the same price frequently describe entirely different work — one including content, testing and a year of aftercare, the other including a build and an invoice. This is a buying guide: the eight parts of the job, how to compare offers honestly, and what has to be in writing before you commit.
The Eight Parts of the Job
| Part | What it involves | Commonly missing from quotes? |
|---|---|---|
| 1. Discovery | What the site must do, for whom, what success looks like, and the structure that follows | Often, and it is the part that decides everything else |
| 2. Design | Layout, hierarchy, responsive behaviour, and the states people forget — empty, loading, error | Sometimes only the desktop homepage is designed |
| 3. Build | The front end, the back end, the CMS, the deployment pipeline | Rarely missing; this is what people think they are buying |
| 4. Content | Writing and migrating the actual words and images | Very often. The most common reason launches slip |
| 5. Integrations | Forms, CRM, payments, accounting, ERP, couriers, analytics | Frequently listed as “standard integrations” without naming any |
| 6. Testing | Real devices, keyboard and screen-reader use, forms, performance under a throttled connection | Often assumed rather than specified |
| 7. Launch | Redirects, DNS, sitemap, analytics, monitoring, and a rollback plan | The redirect map is the piece that gets skipped — see redesign without losing SEO |
| 8. Aftercare | Bug fixes, security patching, backups, and someone to call | Usually a separate retainer — see what maintenance includes |
Where Projects Actually Go Wrong
- Content. The build finishes and the site waits three months for the words. Decide early who writes them, and put a date on it.
- Approval by committee. Every extra approver adds a round of revisions. Name one decision-maker in writing.
- Discovering an integration late. “It also needs to talk to our stock system” in week six is a new project. Every integration should be proven against the real API during discovery, not assumed.
- Design that was drawn, not specified. A beautiful desktop homepage with no mobile layout, no error state and no empty state means the developer designs the rest, at speed, without being briefed.
- Scope creep dressed as feedback. “Small tweak” requests that are new features. Agree in advance what counts as a change and what it costs.
Four of those five are on the client side of the line, which is worth knowing before blaming a supplier. The fixes are all administrative and all free: a content owner, one approver, integrations proven early, a signed-off design that covers every state.
What You Should Own at the End
This is the part that decides whether you have a supplier or a landlord, and it is easiest to settle before any money changes hands.
- The code, in your repository. Your GitHub, GitLab or equivalent, with the full history — not a zip file emailed at the end.
- The hosting, in your account. Your name on the account, your card, your access. A supplier can be granted access; they should not be the owner.
- The domain, in your name. This one catches people out and it is the most painful to unwind.
- The content, in a portable format. A database export or a documented CMS, so it can move.
- Documentation of the decisions, not just the code. Why the structure is what it is, what the integrations do, what the deployment process is.
- Analytics and Search Console in your own account, with the supplier as a user.
None of that is unreasonable and a good supplier will offer it unprompted. Reluctance on any of the six is the most useful signal you will get.
Questions That Expose a Weak Supplier
- “Show me the current state of a live project.” Not a portfolio — work in progress. Suppliers who work on a weekly staging URL will show you immediately; those who reveal everything at the end will not.
- “What went wrong on your last project, and what did you do?” Every project has a problem. “Nothing” means either inexperience or a poor memory.
- “Who exactly will do the work?” Names and roles, and whether they are the people in the meeting.
- “What have you talked a client out of?” Anyone who has never argued against a feature is taking orders, not advising.
- “How will you test it?” Listen for real devices, keyboard and screen-reader use, and a throttled connection. “We test on all browsers” is not an answer.
- “What is your Core Web Vitals target, and how will you prove it?” A supplier without a number is not designing for speed.
- “What happens in month nine?” If the answer is a support queue, the build team leaves at launch.
How we answer those is on the UK web development page, and the call ends with a straight recommendation — including the times it is that your current site is fine and the money belongs elsewhere.
Frequently Asked Questions
What do web development services include?
Eight parts: discovery, design, build, content, integrations, testing, launch and aftercare. Quotes commonly include the build and the design and imply the rest, which is why two quotes at the same price can describe very different work. Ask each supplier which of the eight are in their figure and who does the others.
How do I compare web development quotes?
Make them describe the same scope. Send every supplier the same list of the eight parts and ask them to mark what is included, then ask specifically about named integrations, who writes the content, what testing means in practice, and whether the redirect map and aftercare are in or out.
What should I own after a web development project?
The code in your own repository with its full history, the hosting in an account in your name, the domain in your name, the content in a portable format, documentation of the decisions rather than only the code, and analytics and Search Console in your own accounts with the supplier added as a user.
Why do website projects run late?
Most often content — the build finishes and waits for the words. Then approval by committee, an integration discovered in week six, a design that was drawn rather than specified so the mobile and error states were never briefed, and scope creep arriving as feedback. Four of those five are fixable by the client for free, before the project starts.
How do I know a web development company is any good?
Ask to see a live project’s current work in progress rather than a finished portfolio, ask what went wrong on the last one and what they did, ask who specifically will do the work, and ask what they have talked a client out of. A supplier who works on a weekly staging URL can answer the first immediately.
Not sure which of these you actually need?
Book a free strategy call. We look at what you have and tell you which of these jobs would move the needle for you — and which you can safely ignore this year.
Book a Free Strategy Call