Web Design Proposal Red Flags: What to Ask

The main web design proposal red flags are vague deliverables, mobile design treated as an afterthought, unclear SEO and migration work, and missing terms for ownership, testing and handover. Before choosing a provider, ask what they will actually design, build, test and transfer to you. Use DesignFIT’s comparison page as another way to think through what you need from a design partner.

A proposal is a written plan for the work, cost, responsibilities and terms of a website project. It should help you compare what each provider will do, not just repeat that they will deliver a “custom, responsive, SEO-ready website”. Those phrases sound reassuring, but they do not tell you what the design will include or how you will know the work is complete.

If you have three proposals open, start with the questions in this guide. You do not need to be a developer to spot missing decisions. You need to know which details affect how easily customers understand the offer, trust the business and take the next step.

Why can three website proposals have such different prices?

A proposal’s price reflects the work the provider has included, excluded or assumed. One estimate might cover discovery, custom page layouts, content support, mobile designs, development, testing and launch. Another might assume you supply approved copy and images, choose a pre-built theme and manage the launch yourself. Both may use the phrase “five-page website”.

A low price is not automatically a bad sign, and a high price does not guarantee good work. The useful comparison is what is being made, how decisions will be reached, who is responsible for each task and what happens if something changes. A website redesign cost guide can help you understand the cost factors, but proposals still need to be compared line by line. Examining website development cost data illustrates how widely scope and technical depth differ across price points.

A designer may spend time on the information architecture, which is the way pages and content are organised. They may also create wireframes, simple structural plans that show where content and actions will sit before visual styling begins. These steps can reveal that a page needs a different hierarchy or user journey from the rest of the site. That affects what is built, not just how much decoration it gets.

For example, a service page for a considered, high-value purchase may need to explain the problem, show expertise, answer objections and make it easy to enquire. A standard text-and-image template may not provide the right order or evidence. A proposal that budgets for one general layout across every page may not include the design thinking your business needs.

What should a clear web design proposal include?

A clear proposal explains the project in language you can check. It should identify the goals, deliverables, responsibilities, timing, cost, assumptions, revision process, launch plan and ownership terms. It should also describe how the provider will make design decisions and check that the finished work behaves as intended.

Look for these basics:

Proposal area	What you should be able to find	Why it matters
Goals and audience	The business problem, intended audience and key actions	Keeps design focused on outcomes, not personal taste alone
Scope	Page types, features, content and integrations included	Shows what you are buying and what may cost extra
Design process	Discovery, structure, visual design and approval stages	Makes the decisions and review points visible
Mobile behaviour	How layouts change on smaller screens	Avoids treating mobile as a squeezed desktop design
Search and migration	Technical tasks, URL changes and redirect responsibilities	Helps protect existing pages and search visibility
Quality checks	Testing, acceptance criteria and issue handling	Defines what “ready to launch” means
Handover and ownership	Accounts, source files, licences, training and support	Helps you manage the site after the project
Fees and changes	Payment schedule, exclusions and change process	Reduces surprises when scope or timing shifts

The proposal does not need to be a technical manual. It does need enough detail that you can identify a missing item and ask who will handle it. If the provider says a task is “included”, ask what that means in practice.

Web design proposal red flags to check before you sign

1. The scope is described only by page count

“Up to five pages” tells you how many pages may be produced, but little about what those pages do. It does not say whether each page gets an individual layout, whether some share a template, who supplies the copy, whether the provider enters the content or whether forms and integrations are included.

A page template is a reusable layout structure. Reusing a template can be sensible when pages have similar content and purpose. The risk is not reuse itself. It is paying for a custom design while the proposal does not say which page types are custom, which are adapted and what decisions are included.

Ask the provider to list the page types and their purpose. A services overview, a detailed service page and a contact page may have different jobs. One may help visitors compare options, another may build confidence and the third may collect an enquiry. The visual hierarchy, evidence and calls to action should reflect those jobs.

Ask: “Which page types will have a distinct design, and which will use a shared template? Can you show what the design work includes for each?”

Also ask whether wireframes are included and how many design concepts or revision rounds are allowed. A revision round is a consolidated set of feedback followed by an updated design. The proposal should explain how feedback is gathered and what counts as a new direction rather than a revision.

2. “Mobile responsive” is the only mobile detail

Responsive design means a website layout adjusts to different screen sizes. It does not automatically mean the experience has been carefully designed for a phone. A desktop layout can technically rearrange itself while leaving headings too large, buttons hard to tap, content in an awkward order or important information buried below the fold.

Good mobile design may change more than column widths. The navigation, image crops, content order, form fields and placement of key actions can all need deliberate choices. A phone visitor may be trying to call, find an address or make a quick comparison. A desktop visitor may have room to scan several options side by side. One layout does not always serve both tasks equally well.

Ask whether the provider will design and review mobile layouts before development, or rely on the platform’s default responsive behaviour. Find out which screen sizes and browsers are in scope. The answer need not promise a separate design for every possible device. It should explain how the team will handle small screens, intermediate widths and larger desktop layouts.

Ask: “Can you show how the navigation, key actions, forms and content order will work on mobile before the site is built?”

A useful design review checks real content, not only empty boxes in a mock-up. A long service name, a two-line button label or a portrait image can change how a layout behaves. If the proposal does not say who supplies final copy and images, ask how realistic content will be used during design.

3. “SEO included” has no defined tasks

Search engine optimisation, or SEO, is work that helps search engines understand and surface relevant pages. The phrase “SEO included” could mean anything from setting page titles to planning a site structure, moving existing pages safely and checking technical elements. You need to know which tasks are actually covered.

This matters most when you already have a website. A redesign may change page names, URLs, navigation or content. A URL is the web address of a page. If an old address disappears without a suitable redirect, visitors and search engines may not reach the equivalent new page. A redirect sends a request from one URL to another. A redirect map is a list matching old URLs to their new destinations.

Ask whether the provider will review existing pages and URLs, plan redirects for changed addresses and test them after launch. Clarify who will implement the redirects and whether the work includes checking key pages in Google Search Console if you use it. Do not accept “we’ll handle SEO” as a substitute for named tasks.

SEO also has a design and content dimension. Page structure, navigation labels, headings and internal links help people and search engines understand how information relates. If the proposal does not mention content structure, ask whether the design team will help organise it or expects you to supply a finished sitemap and copy.

Ask: “What search and migration tasks are included, and who will prepare, implement and check redirects if URLs change?”

A local business schema guide explains one kind of structured data, which is information formatted to help search systems interpret details about a business. Do not assume that every redesign needs the same schema work. Ask what is relevant to your site and whether it is included. The HTTP Archive’s Web Almanac performance chapter is a useful reference for understanding that website performance is a broad set of technical measures, not a promise made by the words “SEO-ready”.

4. Ownership and licences are left until the end

Before you sign, establish who will own the finished work and what files and accounts you will receive. Ownership is not one single thing. It may involve the site’s design, written content, code, domain, hosting account, fonts, stock images, software licences and editable source files.

A source file is the working file used to create a design or build, rather than a flattened preview. For example, a design source file can preserve editable components and styles. Getting the live website does not necessarily mean you receive every editable project file or the right to reuse every paid font, photo or plugin. The contract should distinguish between work created specifically for you and third-party tools used under licence.

Do not rely on a verbal promise that “you own everything”. Ask which assets transfer, when they transfer and whether any items are excluded. Confirm that your business controls its domain registrar and primary accounts. If an agency manages hosting or licences, find out what happens when the relationship ends, what it costs to move and whether the site continues to work.

The AIGA Standard Form of Agreement for Design Services is a reference for the kinds of terms a design services agreement can address. It is not a replacement for advice about your particular contract or jurisdiction. If a significant amount of money or important intellectual property is involved, consider getting a lawyer to review the written terms.

Ask: “At final payment, exactly which designs, code, accounts and licences will we control, and what remains licensed or managed by you?”

Be wary of an answer that treats ownership as a detail to sort out after launch. It affects whether you can update the brand, change providers or ask another developer to continue the work.

5. The technical approach is a label, not an explanation

“Custom WordPress”, “bespoke build” and “modern technology” are not enough to evaluate a proposal. Ask what platform will be used, how the site will be assembled and what the chosen approach lets your team do. A theme is a prebuilt set of layouts and styling. A page builder is a visual tool for arranging content and design elements. Either may be appropriate; the relevant question is whether the approach suits the project and can be maintained.

A site with many plugins can create more update and compatibility work, but a plugin count by itself does not prove that a build is poor. Plugins are add-ons that provide features. The proposal should explain which are required, what each one does, who owns its licence and what happens if an add-on is discontinued or its paid plan lapses.

Ask how the site will be kept consistent as pages are added. A design system is a set of reusable rules and components, such as colour styles, typography, buttons and page sections. It helps a team make changes without creating a different look on every page. Ask whether you will receive documentation or training to use those components.

Performance should also be treated as a result of design and implementation decisions. Large images, unnecessary scripts and complex page structures can affect loading and interaction. The Web Almanac performance report provides broader context, but your provider should explain what they will measure on your own pages and how they will respond if a check reveals a problem. A guaranteed score without a defined test setup is not meaningful.

Ask: “What platform and key add-ons will you use, why do they fit our needs, and what performance checks are part of the scope?”

6. Testing and launch are compressed into one line

A proposal that says “build and launch website” may not describe how the team will find problems before customers do. Quality assurance, often shortened to QA, is the process of checking that a site works as intended. It can include checking page layouts, links, buttons, forms, navigation and browser behaviour.

A staging site is a private version used to review work before it goes live. Ask whether you will review the site on staging, who gathers and resolves feedback, and what is included in pre-launch testing. Ask about devices and browsers, but also ask what the tests cover. “We test on mobile” is less useful than a list that includes navigation, forms, interactive elements and content display.

A website also needs acceptance criteria: the agreed conditions that define when the work is ready for approval. These can be practical, such as specified pages being present, forms sending to the correct address and approved content appearing correctly. The criteria should distinguish a defect, where something agreed does not work, from a new request that adds or changes scope.

Ask what happens after launch. Is there a defined period for reporting and fixing defects in the delivered work? What support is included, and what is charged separately? Providers may offer different arrangements. The important part is having the duration, boundaries and response process written down rather than assuming a warranty exists.

Ask: “What checks do you complete before launch, what counts as a defect, and how are post-launch fixes handled?”

For online stores, testing should include the key steps customers take to choose a product and complete a purchase. The Baymard Institute’s mobile e-commerce usability research explores the usability issues that can arise in mobile shopping. Use that as context for your questions, not as proof that a particular proposal includes checkout testing.

7. Content, photography and migration are treated as “your part” without warning

A website design depends on content. If you supply the copy, images and product details, the proposal should state when and in what format. If the provider writes or edits copy, explain which pages and how many review rounds are included. If photography or illustration is needed, clarify who sources it, who pays for licensing and whether original production is in scope.

This is a common source of delays because the project plan may assume content arrives on time. Ask whether the designer will work with draft copy during layout, how late content changes affect the schedule and who enters final text into the site. Content also affects design quality: a layout made with short placeholder text can break when real content is longer.

Migration means moving content or data from the current website into the new one. It may include page copy, blog posts, images, products, customer information or other records. Do not assume “redesign” includes every kind of migration. Ask what will move, who checks it and how any exceptions are handled.

Ask: “Which content and assets do you need from us, what will you create or migrate, and what happens if material arrives late?”

A good proposal makes client responsibilities visible without dumping the project on you. It should identify decisions you need to make, approvals you need to provide and the consequences if those inputs are delayed.

8. Fees, revisions and changes are too open-ended

A fixed project fee is only useful when you can see what it covers. Look for payment milestones, taxes if applicable, out-of-scope rates, expenses and the process for approving extra work. Ask whether any costs recur after launch, such as hosting, software, maintenance or licences. Recurring fees are not automatically a problem; unexplained fees are.

A change request is a request that alters the agreed scope, such as adding a new feature or changing a design direction after approval. The proposal should say how changes are estimated and approved before work proceeds. This helps you avoid discovering a cost after the provider has already done the extra work.

Revision limits need similar clarity. A proposal might include a set number of feedback rounds at particular stages. Ask whether feedback from your team should be combined into one response, what happens if a round is exceeded and whether changes caused by the provider misunderstanding the brief count as a revision. The Clutch web design pricing page can help you explore market pricing information, but it cannot tell you whether a specific quote is good value. Compare the actual scope, assumptions and responsibilities.

Ask: “What can change the fee, how will you price a change before doing it, and what recurring costs should we budget for?”

A practical way to compare three proposals

Do not compare the final totals first. Make a simple comparison sheet and mark each item as included, excluded, unclear or not needed. “Unclear” matters. It is not the same as included, even if the provider expects to handle it informally.

Use these steps:

1. Write down your goal. State what should improve for the business: more suitable enquiries, easier product discovery, clearer service information or another outcome you can recognise.
2. List the key customer journeys. A customer journey is the path someone takes from arriving on the site to completing an action. Note the pages, information and decisions that path involves.
3. Compare deliverables, not adjectives. Translate “custom”, “responsive” and “SEO-ready” into named tasks and review points.
4. Mark assumptions. Note who supplies copy, images, approvals, access credentials and technical information.
5. Check what is excluded. Record costs for hosting, content, photography, integrations, migration and ongoing support if they are not included.
6. Ask each provider the same questions. A consistent set makes answers easier to compare and reduces the chance that one proposal looks clearer simply because it uses more words.
7. Keep the answers in writing. Ask for important clarifications to be added to the proposal or contract before signing.

For example, if one proposal includes custom page designs and another specifies an adapted theme, compare the trade-off against your goals. If your site needs a distinctive service journey, a generic template may be an uncomfortable fit. If you need a simple information site with a tight budget, a well-chosen existing theme could be sensible. The right choice depends on what the business needs, not on a rule that custom is always better.

If you are also weighing different types of provider, compare DesignFIT with other agency options and review the website design service to see how design and build work can fit together.

Seven questions to send before you choose a provider

You can ask these without sounding confrontational. A good provider should be able to explain the work in plain language and say when something is outside scope.

1. “What business and customer problem is your proposed design intended to solve?” Listen for a connection between the brief and the design decisions, not just a list of deliverables.
2. “Which page types have individual designs, and which use shared layouts?” This reveals whether the page count hides different levels of design work.
3. “How will you review mobile layouts and key customer actions before development?” Ask to see how the process accounts for real content and small screens.
4. “What search, URL migration and redirect tasks are included?” Ask for responsibility and checking to be clear, especially if the existing site has pages that people visit or search engines list.
5. “What exactly will we own and receive at handover?” Get a written list covering relevant files, accounts, licences and exclusions.
6. “What tests, approval criteria and post-launch support are included?” Ask how defects are separated from new requests and what support costs after the included period.
7. “What assumptions could change the fee or timeline?” Request a process for pricing and approving changes before extra work begins.

The quality of the answer matters as much as the answer itself. A provider may not know every detail until discovery is complete. That is reasonable if they identify the unknown, explain how they will resolve it and show whether that discovery work is included. It is less reassuring if they make a broad promise but avoid explaining the decisions behind it.

You can find more answers to common project and scope questions in DesignFIT’s FAQ. If you need to understand how fees are structured, review the pricing information and ask how it applies to your specific brief.

What should make you pause before signing?

Pause and ask for clarification if a proposal:

• Lists only a page count and a broad promise of “custom design”.
• Says the site is responsive but does not explain mobile review or behaviour.
• Claims SEO is included without listing relevant tasks.
• Leaves existing URLs, content migration or redirect responsibility undefined.
• Does not say who controls the domain, key accounts, files or software licences.
• Promises a launch but says nothing about staging, testing or acceptance.
• Leaves support, recurring fees or post-launch fixes open to interpretation.
• Gives no process for approving extra work or changes to the brief.

One item does not necessarily mean the provider is unsuitable. It may be a simple omission or an assumption that can be clarified. Reviewing common red flags in a proposal helps you identify warning signs early. The red flag is proceeding without knowing the answer, especially when it affects ownership, cost, customer experience or the ability to maintain the site.

The proposal is a design decision, not just a price

A website proposal describes how a provider intends to turn your business goals into a working experience. The layout influences what visitors notice first. The page structure affects how they find information. Mobile decisions affect how easily they can act on a smaller screen. Content, performance and technical choices all shape whether the design can do its job.

A useful proposal makes those choices and responsibilities understandable. It does not need to promise a particular business result. It should show what work is planned, how the work will be reviewed and what happens when assumptions change.

Before you choose, compare scope, ask about the gaps and get important answers in writing. If you are ready to discuss a website brief with DesignFIT, get in touch to start a project.