How to Evaluate a Web Design Proposal: A Checklist for Comparing Quotes

You have three quotes on your desk. One says 4,000, one says 9,500 and one says 18,000. The price alone tells you almost nothing, because the three documents do not describe the same job. In this guide I show you how to read a web design proposal as a buyer, how to line up competing offers item by item, and which questions to ask before you sign. I have written proposals since 2012, and I also review other agencies' offers on behalf of my clients. So I will share the traps I see most often.

How do you evaluate a web design proposal?

Evaluating a web design proposal means comparing offers on scope, ownership, hosting, maintenance, timeline and hidden costs instead of headline price. First you translate every offer into the same list of line items. Then you ask about the gaps. Finally you decide with a weighted scoring table.

In practice, the core idea is simple. Every agency writes in its own language. One studio says "corporate website" and means ten pages. Meanwhile, another uses the same phrase for five pages and a contact form. So your first job is translation. You take each offer out of its own vocabulary and move it into your own table. If you compare prices before you build that table, you compare apples with oranges.

I always suggest the same order to my clients. First, clarify what you will get. Second, clarify who will own it. Only then look at what it costs. As a result, price becomes the end of the decision rather than the start. If you are not sure what the site should achieve, start with my guide on setting website conversion goals. After all, a brief without a goal attracts proposals without a goal.

Why should you write your own brief before asking for quotes?

The biggest reason quotes differ is that you tell each agency a different story. You mention "a simple site" on the phone to one. Then you describe your e-commerce dreams to another in a meeting. As a result, the numbers that come back answer different questions. That is why I recommend a written brief of one or two pages before you request anything.

A useful brief answers these questions:

• What is the one-sentence goal of the site: leads, bookings or online sales?
• How many main pages and which content types (services, products, blog, case studies)?
• How many languages will you publish in?
• Who will write the copy and supply the images?
• Which systems must it connect to (CRM, payments, accounting, booking)?
• Do you have a fixed launch date?
• Do you already have a site with search traffic?

When every agency gets the same brief, every proposal answers the same question. In addition, the way they react tells you something. An agency that asks questions and spots gaps usually takes the job seriously. On the other hand, an agency that sends a package price without reading the brief is selling its standard product, not your project.

Which line items belong in the scope section?

Scope is the heart of any web design proposal. It is also where most surprises hide. The first thing to check is how concrete the "what is included" list is. "Modern, responsive, SEO friendly website" is not a scope. Instead, it is an advertising slogan.

A concrete scope lists at least the following:

1. The number of pages or templates, each one named.
2. The number of design rounds: how many concepts and how many revisions.
3. Who enters the content, and for how many pages.
4. A list of features such as forms, search, filters or multiple languages.
5. Whether a content management system and a training session come with it.
6. The browsers and devices the agency will test on.
7. Launch work, domain setup and migration from the old site.

Pay special attention to revisions. "Unlimited revisions" sounds generous. In practice, it either stretches the timeline or the agency starts saying "that is a new request". A fixed number of revisions, plus a definition of what counts as a revision, works much better. If you want to judge the design process itself, I cover that side in my UI/UX design services checklist. So I will not repeat it here.

How can you tell a theme from custom design in a proposal?

Much of the price gap between quotes comes from this one question. A theme is a template someone else designed, adapted to your colours, logo and content. Custom design means the agency draws your pages from scratch around your content and goals. In other words, both are valid choices. The problem starts when the proposal does not say which one you are buying.

Next, look for specific words. "Theme licence", "template" and "design adaptation" point to a ready-made theme. "Wireframes", "prototype", "design system" and "Figma file handover" point to a custom process. If you are unsure, ask directly: "Which theme will you use, and whose name will the licence be in?"

The hidden side of a theme is update dependency. If the theme developer stops support, plugins break and one day your site cannot take security updates. On the other hand, the hidden side of custom design is time. Good custom work takes weeks longer than a theme. In short, it is normal for the cheap quote to use a theme and the expensive one to be custom. The real problem is a theme sold at a custom price.

Who will own the domain, the code and the content?

This is the most skipped section in any web design proposal, and the most expensive one to get wrong. Over the years, the crisis I have seen most often is a client who parts ways with an agency and cannot even access their own domain. Therefore, read the ownership terms before you read the price.

Your company should be the registrant of the domain. ICANN's page on registrant benefits and responsibilities makes clear that the registrant holds the rights to the name. If the agency registers it under its own name, it technically belongs to them. For example, you can check where your domain currently points with a DNS lookup.

Look for the same clarity on code and design files. You want a sentence like this: "On final payment, we hand over the source code, database, design files and admin access to the client." Some agencies rent out their own platform instead. That is also a legitimate model. However, you should sign knowing you cannot take the site with you when you leave. Also ask who buys stock image licences, and in whose name.

How should you read the hosting line?

In my experience, hosting is also the vaguest part of a quote. "First year of hosting free" sounds attractive. Still, you cannot judge it if it says nothing about year two, server specs or moving out.

Ask for these details. Is it shared hosting or a virtual server? How often do backups run, and where do they live? Who handles the SSL certificate? What is the annual fee from year two? Above all, if you move to another host, how quickly will you get your files and database?

Hosting also affects performance. On web.dev, Google defines the good thresholds for Core Web Vitals as 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS. Consequently, a weak server can push even a well designed site past those limits. So ask for a performance test before handover. I explain how to read one in my guide to the Google Lighthouse performance test.

What should a maintenance and support agreement include?

A website does not end on launch day. Instead, it starts living on that day. The core software, plugins and server software all need regular updates. That is why a proposal that lists maintenance as a separate, explicit item is a mature proposal, not an incomplete one.

In the maintenance section, look for the following:

• How often updates happen, and whether they take a backup first.
• The first response time for incidents, for example within a set number of business hours.
• How many hours of content or small changes each month include.
• Whether security monitoring and malware clean-up are covered.
• Contract length, notice period and data handover on exit.

Some agencies keep the monthly fee low and bill every small task by the hour. So compare the included hours, not only the monthly figure. Also, do not confuse warranty with maintenance. Warranty means the agency fixes its own bugs for free. Maintenance, by contrast, also covers new needs that appear later. A good proposal separates the two.

Where do hidden costs hide in a web design proposal?

Hidden costs rarely come from bad intent. Instead, most of the time they come from assumptions nobody wrote down. The agency thinks you will supply the copy. Meanwhile, you think they will write it. Then the invoice arrives, and both sides feel they are right. For this reason, treat every blank space in the proposal as a question mark.

The extra items I see most often are these:

• Annual renewals for premium plugins and theme licences.
• Stock photos, icon sets and font licences.
• Copywriting and translation.
• Moving content and products from the old site.
• Business email setup.
• Payment, shipping and accounting integrations.
• The hourly rate for out-of-scope changes.

Business email causes confusion surprisingly often. One agency counts it as part of the site, while another never mentions it. For example, my guide to business email on your own domain explains what you actually need. Also confirm whether each price includes VAT. To put all quotes on the same basis, you can use the VAT calculator.

How does the proposal protect your SEO and existing traffic?

If you already have a site, the biggest risk of a new one is not design. Instead, it is losing search traffic. Many proposals say "SEO friendly" and never explain what that means. Yet without a 301 redirect map from old URLs to new ones, rankings you built over years can fade within weeks.

Ask for these tasks in writing. The agency exports the old URL list, builds a redirect map, carries over titles and descriptions, submits a sitemap and checks Search Console. Google's SEO Starter Guide summarises basics such as descriptive URLs and a clear site structure. So you can check the proposal against those basics.

I cover the details in two separate guides. For a redesign, read how to protect SEO during a website redesign. If the domain or platform changes, use the website migration SEO checklist. For the proposal itself, you only need one question answered: is this work in scope, or will it be billed separately?

Which performance and accessibility criteria should the proposal state?

"A fast website" is a promise, not a measurement. That is why you want a measurable acceptance criterion in writing. For example: "The home page and two template pages will score above an agreed mobile Lighthouse performance threshold." A sentence like that ends the debate before handover day.

Accessibility works the same way. The W3C's WCAG 2.2 guidelines define testable success criteria, from colour contrast to keyboard navigation. For companies that sell into Europe, this is no longer just good practice. The European Accessibility Act has applied to certain products and services since 28 June 2025. A proposal that names a target level, such as AA, shows the agency takes the topic seriously.

I explain why speed matters so much in how site speed affects SEO. For the proposal, then, the point is simple. If no criterion is written down, you will not know what you are accepting at handover.

Why should you read the timeline and payment plan together?

Timeline and payment plan are two sides of the same coin. If most of the money is due up front, the agency has less reason to move fast. On the other hand, if everything is due at the end, the agency will rightly want to limit its risk. The healthy model ties payments to concrete deliverables.

For instance, this structure is balanced: a deposit on signing, a second payment on design approval, and the balance on launch. What matters is a written definition of "delivered" for each stage. Which files and screens will you approve at the design stage? Which tests must pass before launch counts as accepted?

Also look at your own duties in the timeline. In practice, most delays do not come from the agency. They come from clients who send content and approvals late. A good proposal therefore includes dates on both sides, such as "client supplies all copy by a set date". A timeline that only lists the agency's promises will cause arguments at the first delay. In other words, ask yourself too: can I meet these dates?

Why does the technical platform in a web design proposal matter?

The platform often appears as a single word in a corner of the quote. Yet it shapes the next five years of your site. A widely used CMS such as WordPress makes it easy to hand the site to another team, because many developers know it. By contrast, a proprietary platform can mean only that agency can maintain your site.

So you want the platform's name, version and the reason for choosing it in writing. Ask any agency that proposes its own platform: "If we part ways tomorrow, how would another team take over this site?" If the answer is vague, reflect that uncertainty as a minus under ownership in your scoring table.

In practice, I ask the platform question together with the maintenance question. If the same agency offers a proprietary platform and a high maintenance fee, calculate the three-year cost separately. As a result, you see the real price of lock-in from the start.

What table should you use to compare proposals side by side?

First, after reading each offer, move all of them into one table. The table below is a simplified version of the comparison template I fill in with my clients. If a proposal gives no clear answer for a row, write "unclear" in the cell. Your unclear cells then become your list of questions for each agency.

Once the table is full, one proposal often eliminates itself. You can then separate the remaining two or three with the scoring method in the next section.

How do you decide with a weighted scoring table?

A comparison table shows you the differences. However, it does not tell you which difference matters most. For that I use weighted scoring. The logic is simple. You give each criterion a weight, score each proposal from 1 to 5 on it, then multiply and add up.

Here is a sample weighting. This is an example, and your priorities may differ: scope clarity 20 percent, ownership and handover 20 percent, team and references 15 percent, maintenance and support 15 percent, SEO and performance 15 percent, total cost 15 percent. Giving price only 15 percent is a deliberate choice. Price should decide between offers that are otherwise equal.

Let us continue with a worked example. Proposal A scores 4 on scope, 5 on ownership, 3 on team, 4 on maintenance, 4 on SEO and 2 on cost. The weighted total is 0.8 + 1.0 + 0.45 + 0.6 + 0.6 + 0.3 = 3.75. If proposal B scores 5 on cost but 2 on ownership, its total usually ends up below A. The percentage calculator can speed up the maths. The real benefit of scoring is that you can explain the decision to your team with reasons.

When is the cheapest quote actually the right choice?

Treating the cheapest quote as automatically bad is also a mistake. Sometimes the lowest price is the right call. For example, a new business that wants to test a market may only need a few pages. A theme-based site that launches quickly makes sense there. It may be smarter to spend the budget on traffic and content instead of the site itself.

For a cheap quote to be the right choice, three conditions must hold. You keep the domain and the content. The site stays portable. And the proposal states clearly what it does not include. If all three hold, the risk of a low price is limited. At worst, you rebuild in a year or two.

However, if the site must bring in sales or leads directly, the picture changes. A site that converts needs careful thinking, from page structure to form design. I explain what that involves in conversion focused web design. On a project like that, the cheapest quote means short-term savings and long-term lost customers.

How should you verify references and a portfolio?

A portfolio page is a shop window. Still, a shop window does not always show what happens inside. So do not just look at references. Verify them. I suggest three steps.

First, open two or three sites from the portfolio. Check that they are still live and work properly on mobile. Next, contact one of those site owners, ideally through a channel the agency did not give you. Ask one short question: "Did you get support after launch, and how quickly did they fix problems?" Finally, ask who will actually build your project. The senior people in the sales meeting may not be the people doing the work.

Check one more thing: are the portfolio sites close to your industry and size? A manufacturer with dealers and export markets has very different needs from a café. I describe those differences in website design for manufacturers. A team that has built something similar will need less trial and error on your project.

What questions should you ask in the proposal meeting?

No matter how good the written proposal is, a short meeting clears up a lot. Use the questions below to prepare. The aim is not to corner the agency. Instead, the aim is to bring hidden assumptions to the surface.

1. Who will run the project day to day, and how do I reach them?
2. What happens if I want changes after design approval?
3. Which platform will you build on, and why did you choose it?
4. How do you handle bugs that appear in the first month after launch?
5. If the contract ends, in what format and how fast do I get all files?
6. Which three requests do clients often make that this price does not cover?
7. What was the biggest problem on a similar project, and how did you solve it?

Question six is my favourite. An honest agency answers it at once, because it knows which requests come later. An agency that dodges it or says "everything is included" is either inexperienced or wants to discuss those items later. Likewise, the last question shows whether the agency learns from its mistakes.

What must you pin down before the contract?

A proposal is a statement of intent. The contract is what binds both sides. So make sure every term of the chosen proposal moves into the contract intact. Anything promised verbally in a meeting should also go in writing. I tell my clients to send a short email summary after each meeting and ask the agency to confirm it.

In the contract, look closely at these clauses: intellectual property and transfer, confidentiality, personal data processing for form submissions, penalties for delay, termination and handover on exit, and jurisdiction for disputes. The contract should state the agency's duties as a data processor. Getting legal advice on this part is the safest route.

Also define the acceptance procedure. How many days do you have to test after handover? How do you report bugs? When does the work count as accepted? If these points are missing, you may face a long wait between the final payment and the final fixes. Consequently, a clear acceptance procedure protects both you and the agency.

What mistakes do buyers make most often with a web design proposal?

Over the years, I have seen clients make the same mistakes with a web design proposal again and again. The first is comparing only the total price. Another is never reading the ownership terms. A third is calculating year one and forgetting the years after.

The third mistake is especially common. A quote can look cheap in year one. Then licence renewals, maintenance and hosting push its three-year total above a rival's. That is why I recommend comparing total cost of ownership over three years. As a worked example, add setup plus three years of hosting, maintenance and licences, then compare quotes on that total.

The fourth mistake is leaving the real users of the site out of the decision. What does your sales team need from the form? Which questions does customer service hear every week? If that input never reaches the brief, even the best proposal answers the wrong question. If you want an independent second opinion, I also review proposals as part of my web design service. My goal there is not to sell you an option. It is to make your choice clearer.