The questions to ask before you commission a website cover scope, process, design, technology, speed, security, ownership and maintenance; the 12 questions below help you compare quotes properly and avoid surprises. Next to each question, we describe what a good answer looks like.
The most expensive problem in a website project is a misunderstood expectation. A question skipped at the quote stage often returns mid-project as extra work, a delay or a constraint that is hard to undo. Think of this list as a checklist you can use with every team you talk to about website development.
Why should you ask these questions at the quote stage?
The quote stage is when change is cheapest. Changing scope once design has started takes effort; changing the underlying platform once development is done often means rebuilding the site.
The questions also show how a team works: one that gives concrete, written and honest answers will communicate that way throughout the project. The written version of those answers later becomes the basis for the contract and the acceptance criteria.
The questions test you as well. To answer many of them, you first need clarity on your own goal, content and decision process, which gives the project a firmer start.
Which 12 questions should you ask before commissioning a website?
The questions follow a project's flow: team and process, then design, content and technology, then ownership and life after launch.
- Have you built a similar project, and can I see a live example? Ask for live sites, not screenshots, then open them on your phone and test the speed yourself. The same industry is not required; similar complexity is. Also ask whether the team handled design, development or both.
- How will the process work, and what will I approve at each stage? A good answer lays out the stages (discovery, design, development, testing, launch), the deliverables of each and the approvals expected from you. Ask who your main contact will be and how you will follow progress. A short weekly check-in or a shared project board keeps progress visible.
- What exactly does the quote include, and what does it leave out? The page and template list, number of languages, admin panel features and integrations should be in writing. Stating what is out of scope just as clearly prevents "that was not included" arguments later.
- Will the design be specific to our brand, and how many revision rounds are there? Clarify whether a ready-made theme will be adapted or an original design created. Ask whether mobile design is handled separately, how revisions are limited and how the design gets approved before development starts.
- Who will prepare the content, and how will existing content be moved? Split responsibility for copy, images and translation from the start. If you already have a site, make sure old pages will redirect to their new URLs; otherwise you can lose years of search visibility.
- Which technology will you build the site on, and why? The answer should not stop at a product name; it should explain why the choice fits your needs. A widely used, regularly updated platform that another team could take over if needed protects you in the long run. If any component needs a paid license, find out who covers it.
- What will I be able to update myself in the admin panel? Ask for a demo of the panel. See whether adding a page, changing an image, editing the menu or managing languages needs technical help. Ask whether user roles with different permissions can be defined. A clear panel in your team's own language decides whether people actually use it.
- How fast will the site be, and how will you measure it? A good team defines speed as measurable targets, not a feeling. Google's Core Web Vitals and mobile test results can be the shared language of that conversation. Ask how the targets will be tested before launch.
- What groundwork will you lay for search engines and AI answer engines? Find out whether a meaningful heading structure, meta tags, a sitemap, structured data, clean URLs and analytics setup are in scope. Every marketing effort after launch builds on it. If you have an existing site, ask whether there is a migration plan that protects your visibility.
- What will you do for security and data protection compliance? HTTPS, up-to-date software components, forms protected against spam and bots, regular backups, a protected admin login and cookie consent under rules such as KVKK and GDPR are the baseline. For the wider picture, see our cybersecurity checklist.
- Who will own the source code, the domain and the accounts? The domain, hosting, analytics and search console accounts should be opened in your company's name. Whether you will have access to the source code and design files, and what gets handed over if the partnership ends, should be written into the contract. Ask whether technical documentation is delivered too, so the site can change hands smoothly.
- How will maintenance and support work after launch? Ask who handles updates, how backups are checked, whom you contact through which channel when something breaks and what the response times are. The line between bug fixes under warranty and new requests should be defined too. A team that can suggest how the site will stay current over the years is a good sign.
How can you tell a good answer from a weak one?
How an answer is given tells you as much as what it says. Watch for these signals:
- Concreteness: Good answers include examples, steps and a list of deliverables. Phrases like "everything included" say very little.
- In writing: Everything said in a meeting should make it into the quote or the contract.
- Trade-offs explained: Every option has a cost. A team that says so openly will not surprise you later.
- Questions back to you: A quote prepared without asking about your goal, audience and internal processes is most likely a standard package.
- Consistency: If different people on the team give different answers to the same question, communication problems during the project are likely.
- Clear limits: A team that openly says what is out of scope manages expectations well.
What should you prepare before the meeting?
Questions go both ways. Bring the following to the meeting and both the answers and the quote will be sharper:
- The site's goal in one sentence and how you will measure success
- Your target audience and why they come to the site
- A draft sitemap and the number of languages
- A list of the content you have and what is missing
- The integrations you need, such as CRM, booking, payments or ERP
- A few sites you like and a few you do not
- Who makes the decision and your target launch date
- Your budget frame and the order of your priorities
We explain how these choices show up in the budget in our article on the 8 factors that shape the cost of a corporate website.
Which terms should you see in the contract?
The answers you get in meetings only protect you once they are in writing. At a minimum, the contract should spell out:
- Scope and deliverables: the page and template list, admin panel features, integrations and number of languages
- Timeline and approvals: when each stage is delivered and how long you have to approve it
- Acceptance criteria: the conditions under which the work counts as complete
- Ownership: who owns the source code, design files and accounts
- Warranty and maintenance: the warranty period, maintenance scope and response times
- Personal data: each party's responsibilities for data collected through the site
A good team does not just answer your questions; it asks you the right ones.
Frequently asked questions
How many teams should I talk to before choosing?
Enough to compare, but few enough that you can review each quote carefully. Sending everyone the same written list makes the answers easy to compare.
Does it make sense to pick the lowest quote?
Only if the scope is exactly the same. A low quote sometimes comes from leaving out items such as content, panel flexibility, redirects or maintenance, and they return later as extra cost.
How long does it take to build a website?
The timeline depends on scope, design approach, the number of languages and when content will be ready. A reliable schedule can only be given stage by stage once scope is clear, so be careful with firm dates offered before that.
How do I judge the answers if I am not technical?
Ask for answers in plain language; a good team can explain a technical decision in terms of business outcomes. Where you are unsure, try the live examples and the panel demo yourself.
Should I ask the questions in writing or in a meeting?
Do both. Send the list in writing first so the answers are comparable, then use a meeting to talk through anything unclear and ask for written confirmation of important commitments made there.
Where to start?
Copy these 12 questions into a document, send them to every team you talk to and ask for written answers. Then compare the answers for scope, clarity and ownership; the right choice usually becomes obvious.
If you would like to ask us these questions too, get in touch.