How to review a web design proposal before signing
A web design proposal should specify business goals, page templates, deliverables, content responsibility, revisions, responsive work, development, SEO migration where needed, integrations, milestones, acceptance criteria, ownership, exclusions, ongoing fees, and support.
Ahmed JamalInsights

The starting point
When two web design proposals show different prices, the tempting move is to compare totals. I would compare responsibilities first.
One proposal might include research, copy direction, design, development, and launch checks. Another might cover design screens only. The cheaper option might still be right for your business, but only after the missing work has a clear owner.
A proposal should tell you what will be done, what you will need to provide, and what will happen when the project changes.
Find the outcome before the deliverables
Look for a plain explanation of the project goal. For a service business, the goal might be clearer enquiries. For a SaaS team, the goal might be easier product understanding or more qualified demo requests.
A proposal full of design trends without a clear business problem leaves an awkward question: how will anyone judge the finished work?
The proposal does not need a promise of higher revenue. The provider should still understand which visitor action the site needs to support.
Compare scope line by line
Here is the comparison I would make between two offers.
Page count versus unique page types. Five URLs using one template are different from five individually planned pages.
Design versus build. Does the fee end at Figma, or include a working site?
Copy. Does the provider write, edit, structure, or place supplied content?
Responsive work. Are mobile and tablet states included, or treated as an extra?
SEO. Are headings, metadata, clean URLs, redirects, and technical checks included? A redesign with current rankings needs a separate migration plan.
Forms and integrations. Does 'contact form included' mean delivery to one inbox, CRM routing, or tracked bookings?
Handover. Who provides accounts, editable files, documentation, and training?
Write down any unclear item instead of assuming the provider meant the most complete version.
Look for boundaries, not vague reassurance
A well-scoped project names revision rounds, approval points, payment milestones, and the procedure for additional work.
Ask what happens if you add a service page halfway through. Ask how late content affects the schedule. Ask whether a major change in direction counts as a revision or a new phase.
Clear change rules protect the client as much as the designer. Both sides know how to handle a genuine new requirement without arguing about what was promised.
Check intellectual property and access separately. A domain registration, a hosting account, a CMS subscription, licensed fonts, custom code, and Figma source files are not the same asset. Rights depend on the agreement and relevant law. Have a qualified professional review material contractual questions when needed.
Ask how the work will be accepted
'Website complete' is too broad as an acceptance test.
Useful acceptance checks include:
- The agreed pages exist and follow approved content.
- Responsive states have been reviewed.
- Forms deliver to the expected destination.
- Analytics events fire in testing.
- Links, metadata, and redirects are checked.
- The client receives the agreed editing access.
- Open issues are listed with owners and dates.
If the project includes an existing site, the proposal should also explain how old content and URLs will be handled during launch.
Compare the full cost of ownership
A one-time project fee tells part of the story. Ask about recurring hosting, CMS, paid plugins, licences, email, support, and future content updates.
Some providers offer a monthly service. Others hand over the site and leave the team to run operations. Neither model is automatically better. Pick the one your business has the people and budget to maintain.
Make the choice on fit
After scope is clear, judge the actual working relationship. Does the provider explain tradeoffs? Are questions answered directly? Who will make design decisions? Who will run QA? Who speaks with your team?
A strong proposal should make the project easier to picture. By the time you sign, you should understand both the work being bought and the decisions still ahead.


