How to Choose a Web Development Company in the UK: 9 Questions

Most website projects that go wrong do so for reasons visible at the proposal stage — unclear ownership, no defined scope, no plan for content, no support after launch. These nine questions surface those before money changes hands.

1. What do I own when this is finished?

The domain, the hosting account, the source code, the analytics property and full CMS access. All in your name, all handed over without a negotiation.

If any answer is "we manage that for you", ask what happens when you leave. The reply tells you whether you are buying a website or renting one.

2. Is the design custom or a theme?

Neither is wrong. Being unclear about it is. A configured theme should cost meaningfully less than a bespoke design, and if you are paying bespoke prices for a theme you should know that now rather than when you recognise the layout on a competitor's site.

3. Who writes the content?

The most common cause of a six-week project taking six months. If content is yours to provide, get that in writing along with a deadline, because design cannot finish without it. If it is theirs, confirm it is written by a person who will ask you questions, not generated and pasted.

4. What performance are you building to?

Ask for a target — a Lighthouse score or Core Web Vitals thresholds — and ask to see it met on the finished build, on mobile.

Speed is not a nice-to-have in the UK market. It affects rankings, and more importantly it affects whether someone on a phone waits for your page at all.

5. How will I edit it afterwards?

Ask for a demo of adding a page and changing a section, in the actual CMS, before you sign off. Some builds look wonderful and are effectively read-only for anyone who is not a developer, which converts every small change into an invoice.

6. What tracking will be set up?

Analytics installed, conversions defined and tested, and — if enquiries come by phone or WhatsApp — those clicks tracked too. Without this you launch blind and have no way to judge whether the site works.

7. What happens after launch?

Clarify the warranty period for bugs, what counts as a bug versus new work, the response time, and whether updates and backups are included. A studio that disappears at launch leaves you with a WordPress install quietly going out of date.

8. Can I speak to two recent clients?

Not testimonials on a page — actual conversations. Ask those clients two things: did it launch on time, and what happened when something broke afterwards. The second question is the useful one.

9. Who is actually doing the work?

Names and roles, and whether any of it is subcontracted. Subcontracting is not automatically bad, but you are entitled to know whether the team that pitched is the team that builds — and if work goes offshore, whether you were told.

We are a remote team working with UK clients from Pakistan, and we say so on the first page rather than the fifteenth. Our UK page sets out what that means in practice: calls in your morning, invoices in GBP, and no pretence of a London office.

What should the contract itself say?

Beyond the nine questions, four clauses do most of the protecting.

• Payment tied to milestones, not dates. Paying for progress rather than time passing keeps incentives pointing the same way.
• IP transfer on final payment, stated explicitly, covering code, designs and content.
• A defined scope with a change process. Changes are normal; unpriced changes are how projects overrun.
• An exit clause. What happens, and what you receive, if either side stops. A supplier confident in their work will not resist this.

How do you spot trouble early once work starts?

Three signals, in order of seriousness.

Demos stop. If you are not seeing working software regularly, you are being told about progress rather than shown it.

Questions slow down. A team building your site well asks things — about your customers, your process, your edge cases. Silence usually means assumptions are being made.

The date moves without a reason. Dates slip on every project; what matters is whether you are told why and what changed. A slip explained on the day it happens is professional. One discovered in week eleven is not.

Raise these at the time. Almost every project that ends badly had a fixable moment two months earlier that nobody mentioned.

What do the answers tell you?

A good supplier answers all nine quickly, because they have been asked before and their process already covers them. Hesitation on ownership, vagueness on content, or silence on support are the three that predict trouble most reliably.

Price matters, but it is the fifth or sixth most useful thing to compare. A cheap build you cannot edit, cannot measure and do not own is the most expensive outcome available. If you want to see how we answer these nine, the web development page is where our process is written down.