How to read a web design proposal: 10 questions to ask.
When reading a web design proposal, the place to look is not the total amount but what the amount covers: who will own the source code and the domain, whether speed and accessibility criteria are written down, and exactly what you will receive on handover day. If the answers to these questions are not written in the proposal, they should be asked before signing.
Proposals are usually summarized in two pages: a scope paragraph, an amount, a timeline. What really matters is often not in those two pages, because when it is not written down it binds no one. The ten questions below are for finding the places where a proposal stays silent. All of them can be asked without technical knowledge, and the answers can be requested in writing.
We write our corporate web design proposals so that they contain the answers to these questions; but the questions apply no matter whom you ask. To understand which items make up the amount, you can first look at the guide what determines a website’s price.
1. Who gets the source code and content at handover?
It is not enough for the proposal to say “the site will be delivered”; it has to say what is delivered. All of the code, the text and image files, setup notes sufficient to rebuild the site and, if any, the measurement tools. If the answer is “the site itself stays with us, you get a right of use”, that is a subscription model; it is legitimate, but it should be chosen knowingly.
2. Whose name will the domain be registered in?
If a new domain is to be purchased, the registrant should be your company. The provider can take on technical management; if ownership stays with someone else, the domain becomes the hardest asset to recover once the relationship ends. The same question applies to the site’s email addresses: whoever holds the domain effectively holds the mailboxes on that domain as well.
3. Whose name will the hosting and service accounts be opened in?
Hosting, an email delivery service, a form service, maps or analytics: every external account the site depends on is a line item. If the accounts are opened in the provider’s name, the proposal should state how each account will be transferred at handover.
4. Is the speed criterion written down with a number and a measurement method?
“Fast and optimized” is not a criterion. A criterion is a number, a tool and a condition. We saw on our own site why the condition matters: the same page scored 87 in Lighthouse’s default settings and 98 in a real Chrome configuration — the reason for the gap was that the tool switched off a browser feature. That is why in our contract it is not the lab score but the value measured on real users that is binding: Largest Contentful Paint (LCP) below 0.8 seconds, layout shift 0. The worst real-user LCP measured on 23 September 2026 was 420 milliseconds.
5. At what level, and how, will accessibility be tested?
The proposal should state a level (WCAG 2.2 A or AA) and a testing method. An automated tool alone is not enough; keyboard navigation, a screen reader and a contrast check are needed too — the limits are covered in the guide the limits of automated testing. On this site every release passes an automated accessibility audit and a suite of 1462 tests before going live; how it was set up is described in the article don’t say “done” without measuring.
6. How many templates, how many languages and which pages are in scope?
The scope should be written as a list of pages: which page templates will be designed, how many languages it will be published in, which forms and integrations will be set up. Work that is not on the list comes back as extra work after handover. On a multilingual site, how the language versions will be linked to one another is also part of the scope, not just the translation.
The scope list should also have an “out of scope” line. A proposal that states clearly which work is not included — for example translation, photography, external system integration, content entry after launch — prevents most of the disputes that would otherwise arise after handover.
7. Who prepares the texts, images and translation?
If the proposal does not make clear who will prepare the content, it often gets written hastily and thinly as launch day approaches. Ask for a separate “who” line for text, photos, icons, translation and their approval workflow. If the content is to come from you, the timeline should also state the content delivery date, and how the launch date will shift if the content is late.
8. Is there a redirect plan for the old site’s addresses?
If the new site replaces an old one, the list of old addresses should be compiled and each one permanently redirected to its new counterpart. At handover, ask for the tested version of this list — and make sure the test looks at the destination address. Our own check once looked only at the status code and counted a redirect that went to the wrong place as “passed”; since that day the destination of every line is tested as well.
9. What is promised for search visibility?
Google’s own guide is clear: no one can guarantee a number one ranking in Google. If the proposal contains a ranking guarantee, a promise to “get you onto the first page” or a claim of a special relationship with Google, that is a warning sign. What should be written down is not the result but the work to be done: titles and descriptions, structured data, a sitemap, Search Console setup, migration of old addresses.
10. What happens on handover day and afterwards?
The handover should include an acceptance test: the criteria from the fourth and fifth questions are measured on handover day and the report is given to you. Lines are needed for afterwards too: the time to fix bugs, software updates, domain and certificate renewal, backups and how content changes will be made.
The acceptance test is not a formality; it is the only proof that the handover was made against your criteria. There are a few things you can look at yourself on the test address: open the site on your phone and fill in the form, navigate using only the Tab key, open a few old addresses and see where they land. These three checks are your own observation alongside the measurement report.
How do you put two proposals side by side?
Write the answers to the ten questions in a separate column for each proposal. The empty cells show where the difference between the two proposals comes from; more often than not the difference is not in the amount but in these cells. Asking the provider about the empty cells is also a polite and appropriate request: a good proposal already knows the answers to these questions, it may simply not have written them down.
Which sentences in a proposal call for attention?
- “Ranking guarantee” or “first page promise” → no provider can guarantee this.
- “Source code is not delivered” → the site cannot be handed over to another team.
- “The domain is registered in our company’s name” → you do not own it.
- “Fast, mobile-friendly, SEO-friendly” but no numbers → there is no acceptance criterion.
- “Content is supplied by the client” but no content in the timeline → risk of empty pages on launch day.
If one of these sentences appears in a proposal, it does not mean the proposal is bad; it means there is a question to be asked. The wider framework of the ten questions is in the guide what to watch for when having a website built; what the legal pages should contain is in the guide what a website must have.
Anything not written in the proposal becomes a matter for negotiation after handover.
If you want to see these answers on your own site, corporate web design delivers design, code and technical SEO from one hand, on a measurable budget.