12 questions to ask a web development company before you sign

The twelve questions below separate a web development company you can trust from one you will regret. For each, there is what a good answer sounds like and what a bad one sounds like, because the questions are easy to ask and the answers are where the information is. Ask all twelve on a call before you sign anything, and write the answers down; several of them belong in the contract afterwards.

They are ordered roughly by how often a bad answer leads to a bad project.

Who owns what, and who will actually do the work?

Who owns the domain, the hosting account and the code?

Good: "You do. The domain is registered in your name, the hosting account is yours and we have access, and the code lives in a repository you own. If you leave, you take everything."

Bad: "We handle all of that for you so you don't have to worry." Or any hesitation. Some studios register domains in their own name and treat them as a bargaining chip when a client wants to leave. We have taken over sites where the client could not get their own domain back without a lawyer.

This belongs in the contract in writing. The post on what a website contract should include has the clauses.

Who will actually do the work, and can I speak to them?

Good: Names, roles, and a short call with the designer or lead developer before signing. They can describe a recent project in detail.

Bad: "Our team" with no names, or a sales person who answers technical questions by promising to check. Many agencies outsource the build; that is not wrong in itself, but you should know, and you should know who you will deal with when something breaks.

Can you show me three live sites like mine, and what happened to them after launch?

Good: Three URLs you can click, with a sentence each on what the client needed, what was built and how it performed. Honest about one that did not go to plan.

Bad: Screenshots of homepages, mockups that were never built, or a portfolio of sites that have since been replaced by someone else's work. Check the sites yourself. Run them through a speed test, open them on a phone, and look at the footer for a "built by" credit that matches.

A studio offering website design and development should be able to show you the kind of site you are asking for. If every example is a different kind of project, you may be the first.

What exactly am I paying for, and when?

What is included in the price, and what is not?

Good: A written breakdown by phase and feature, with the exclusions listed: copywriting, photography, stock licences, paid plugins, third-party subscriptions, domain and hosting. "Content is yours to write; we can quote for a writer if you want."

Bad: One number. Or "everything is included" without a list. Compare the breakdown against your brief line by line. The post on why web design quotes vary explains the items that cheaper quotes tend to drop, and the website cost guide gives ranges for each line.

How do you handle changes to the scope?

Good: "Small changes inside the agreed scope are part of the process. Anything outside it is a written change request with a price and a timeline impact, and nothing starts until you approve it."

Bad: "We're flexible, just let us know." Flexibility without process turns into an invoice you did not expect, or a studio that quietly cuts quality elsewhere to absorb the cost.

What are the payment milestones, and what do I get at each one?

Good: A deposit of 25 to 50 percent, a payment at design approval, and the balance at launch, with a definition of each milestone. "Launch means the site is live on your domain, all pages approved, forms tested, and analytics set up."

Bad: 100 percent upfront. Or milestones tied to calendar dates rather than deliverables, which means you pay even when the work is late. Our post on fixed price versus hourly covers how milestones work under each pricing model.

How will the site be built, edited and found?

What platform will you build on, and why that one for us?

Good: A recommendation tied to your situation. "WordPress, because your team will publish weekly and wants to edit everything. We would suggest a static Next.js build if the site changed twice a year." Or the reverse, with reasons.

Bad: The same platform for every client regardless of need, with no reasons beyond "it's what we use". A studio that only builds on one platform is fine if that platform fits you; the test is whether they can say when it does not.

How will my team edit the site after launch?

Good: A demonstration of the editor on a real site, a list of what you can change without a developer (text, images, pages, posts, team, projects), and a handover session included in the price.

Bad: "Just send us the changes." That is a maintenance contract disguised as a feature, and it makes every typo a billable ticket. There are sites where it is the right arrangement, but it should be a choice you make.

What happens to our search rankings and old URLs?

Good: "We export every URL from your current site, map each to its new equivalent, set up 301 redirects, and check Search Console after launch for crawl errors." For a new site with no predecessor: "We set up metadata, structured data, a sitemap and Search Console as part of the build."

Bad: A blank look, or "SEO is a separate package." Redirects are part of a rebuild, not an add-on. Google's own documentation on site moves sets out what a redesign that changes URLs needs, and a studio should know it. Anyone who guarantees rankings is to be avoided.

What performance and accessibility standard will the site meet?

Good: A specific target. "Pass Core Web Vitals on mobile at launch, and we check on real pages, not just the homepage. We follow WCAG 2.2 AA for contrast, keyboard use and labels."

Bad: "It'll be fast" or "it'll be responsive". Those are not standards. Ask to see a recent site they built in a speed test, on a phone, over mobile data.

What happens after launch, and what could go wrong?

What happens after launch, and what does it cost?

Good: A short warranty period for bugs, typically 30 to 90 days, included. Then an optional care plan with a published scope: updates, backups, monitoring, a number of hours for changes, and a monthly price. "Or you can take the site elsewhere; here is the handover documentation."

Bad: No warranty, or a care plan that is mandatory, or a care plan with no written scope. See how much website maintenance costs for what the ranges should look like.

What could go wrong on this project, from your side?

Good: A real answer. "The risk on your project is the CRM integration; we have not used that API and have budgeted time to test it. And the timeline depends on your copy arriving by week three."

Bad: "Nothing, we've done this hundreds of times." Every project has a risk, and a studio that cannot name yours has not thought about it yet.

How to use the answers

Score each studio out of twelve. Most good studios will answer ten or eleven well and be honest about the one they are weaker on. A studio with four or five bad answers is not a bargain at any price.

Then put the good answers in the contract: ownership, milestones, change requests, warranty period and the performance standard. A verbal answer on a sales call is worth nothing in month four. If you want a figure to check their quote against before the call, the website cost calculator gives a range from your page count and features.