How to Choose a Web Development Company: 12 Questions to Ask
Picking a web development company is hard because most of what matters isn't visible in a portfolio. Every agency shows its best work. What you need to know is how they'll work with you: how decisions get made, what happens when something changes, and whether you'll be left with a site you can actually run.
These are the questions we'd ask if we were in your seat, and what a good answer sounds like.
About the work
1. Can I see live sites similar to mine, and talk to those clients?
Screenshots can be polished. Live sites show you how fast pages load, how they work on a phone and whether they've been kept up. A short call with a past client tells you more than any case study.
2. Who will actually work on my project?
Find out whether the people you're talking to will be the ones designing and building, or whether the work is passed to someone else. Either can work, but you should know who to contact and who's responsible.
3. How do you find out what we need?
A good agency asks a lot of questions before quoting: who your customers are, what they need to do on the site, what's working and not working today. If you get a fixed price after a five-minute call, the quote is a guess.
About process and changes
4. What are the stages, and what do I approve at each one?
Look for clear checkpoints: a plan or sitemap, then designs, then a working site to review, then launch. Each one should be something you can see and sign off before the next begins.
5. How do you handle changes after we've started?
Changes are normal. What matters is how they're handled: whether small tweaks are included, how bigger changes are priced, and how they affect the timeline. Get this in writing.
6. How will we communicate, and how often?
A weekly update and a shared place for questions and files prevents most problems. Long silences followed by a big reveal are a warning sign.
About quality
7. How do you make sure the site is fast and works on phones?
Ask how they test: on which devices and browsers, and whether they measure page speed. A good answer mentions real phones and tools like Lighthouse or Google's Core Web Vitals. If you'd like to know what those measure, see Core Web Vitals explained.
8. What do you do for SEO as part of the build?
At minimum: a unique title and description for each page, sensible headings, a sitemap, fast pages and structured data where it helps. If you have an existing site, ask how they'll redirect old URLs so you don't lose the search traffic you already have.
9. Is the site accessible?
Accessibility means people using screen readers, keyboards or larger text can use your site. It also tends to make the site better for everyone. A good team will talk about contrast, labels and keyboard navigation without being prompted.
About ownership and the long run
10. Will I own the code, domain and accounts?
You should. The domain, hosting, analytics and content accounts should be in your name, and the code in a repository you control. If the agency keeps these, leaving them later becomes difficult.
11. Can I update the content myself?
If the answer is "just email us", every small change costs you time and money. Ask to see the editing screens for a site they've built. We explain how this usually works in what a headless CMS is.
12. What happens after launch?
Sites need updates, backups and the occasional fix. Ask whether there's a support period included, what ongoing support covers and costs, and how quickly they respond when something breaks. Our maintenance checklist shows what's typically involved.
A few red flags
- A price before they understand what you need
- No written scope, or a scope that just says "website"
- They'll own the domain or hosting "to make things easier"
- They can't show live, recent work
- Every answer is "yes", including to things that don't make sense
Making the decision
Price matters, but compare like with like. Our guide to website costs explains how to line up quotes so you can see what each one includes.
We're happy to answer all twelve of these for our own work. If you'd like to ask them, get in touch or read how we approach web development.