How to Choose a Web Development Company: 10 Questions to Ask Before You Sign

Hiring a web development company is a strange purchase: you're buying something you can't inspect, from people whose portfolios all look impressive, at prices that vary by 10x for reasons nobody explains. The fix isn't becoming a developer — it's asking questions that make quality visible before you sign.

Here are the ten we'd ask if we were hiring, including the answers that should end the meeting.

1. Can I see three live sites you built — and who did the work?

Not screenshots. Live URLs, plus whether the people who built them are the people who'd build yours. Agencies routinely show senior work and staff projects with juniors. Then run those URLs through Google PageSpeed Insights yourself: consistently slow portfolio sites are the most reliable early warning there is.

2. What exactly is included — in writing?

Page count, revision rounds, who writes the copy, who supplies images, what 'SEO included' actually covers, browser and device support, and what happens to change requests after launch. Vague scope is where good budgets go to die. A team confident in its process will hand you this list without being asked.

3. Who owns the code, the content and the accounts?

The answer must be: you, all of it — code repository, domain registrar, hosting account, analytics. A depressing number of small businesses discover at the first disagreement that their agency owns their domain. If ownership isn't in the contract, that's a no.

4. What stack do you build on, and why?

You don't need to judge the answer technically — you need to hear whether they can justify it in business terms. 'Next.js because your traffic is organic-search-driven and it's the strongest SEO and performance platform' is a real answer. 'WordPress because it's what we know' is at least honest. No coherent answer at all is the red flag.

5. How will we communicate, and in whose hours?

Ask for the specifics: who is your point of contact, what tool, what response time, and — if the team isn't local — whether they work US business hours. Offshore pricing with US-hours overlap is one of the best value combinations available in 2026; offshore pricing with a 12-hour reply lag is one of the worst.

6. What does 'done' mean?

Get the acceptance criteria upfront: launched on your domain, passing Core Web Vitals, forms tested and delivering to your inbox, analytics and conversion events firing, SSL live, redirects from the old site in place. Teams that ship define 'done' before they start.

7. What happens after launch?

Sites decay: dependencies need patching, content needs changing, things break in new browsers. Ask what the first 30 days of support includes, what maintenance costs after that, and what an hourly change costs. 'We'll figure it out later' means 'it will be expensive later'.

8. How do you handle SEO — specifically?

'SEO-friendly' is a marketing word. Ask what's actually delivered: metadata and Open Graph on every page, structured data (and which types), a sitemap, Core Web Vitals targets, redirect mapping from your old URLs. If they can't name these, the SEO is a checkbox, and your traffic will show it.

9. What will this cost — and what would make it cost more?

A fixed price is only fixed if scope changes are priced too. Ask what triggers a change order and what the rate is. The best answer is a published, itemized pricing model where you can see what each addition costs before you ask for it.

10. Why shouldn't we hire you?

The most revealing question on the list. Confident teams answer honestly — 'if you need it in two weeks, we're wrong for you' or 'if you want the cheapest possible site, use a builder'. Teams that claim to be perfect for everyone are optimized for signing you, not for shipping.

Red flags that end the conversation

• They'll register the domain 'for you' (in their name).
• No live portfolio URLs, or portfolio sites that are visibly slow or broken.
• SSL, mobile responsiveness or 'basic SEO' priced as paid add-ons.
• Pressure to sign before the scope document exists.
• No answer to 'who owns the code?'