← Back to Blog

How to Read a Web Development Proposal Before You Sign It

The line items that matter, the red flags hiding in vague scopes, and the questions that separate a real partner from an expensive mistake.

IndustrySeptember 24, 20268 min readBy Joseph Rajewski
How to Read a Web Development Proposal Before You Sign It

Earlier this year we published a Denver-metro pricing benchmark covering what websites and web apps actually cost. The follow-up question we hear most often is not "is this price fair?" It's "I have three proposals in front of me and I can't tell them apart." Fair. Proposals are written to be signed, not compared. This post is the decoder: what the line items mean, where problems hide, and the questions that surface them before you're locked in.

We write proposals for a living, so treat this as the vendor showing you the seams on purpose. If a proposal can't survive these questions, you want to know that now.

Read the scope section like a lawyer, because someone will

The scope section is the contract's load-bearing wall. Everything else (price, timeline, payment terms) hangs off what is and isn't in scope. Two habits will serve you well:

Look for nouns with counts. "A modern, responsive website" commits to nothing. "Up to 12 unique page templates, a blog with category and tag archives, a contact form with CRM integration, and a searchable events calendar" commits to something you can point at during a dispute. If the deliverables can't be counted, they can't be missed, and that ambiguity always resolves in the vendor's favor.

Find the exclusions list, or worry about its absence. A mature proposal says what's not included: content writing, photography, data migration beyond N records, third-party license fees, post-launch changes. An exclusions list means the vendor has been burned before and prices honestly. No exclusions list usually means the exclusions arrive later, as change orders.

The line items that deserve your attention

Discovery. If it's missing, ask how the vendor knows what to build. If it's free, ask what happens when discovery reveals the project is bigger than the estimate. Discovery priced at zero is usually discovery that produces whatever conclusion keeps the sale alive.

Content migration. The single most underestimated line in the industry. "Content migration included" needs a number attached: how many pages, posts, products, users, files. Migrating 40 pages is an afternoon. Migrating 4,000 posts with embedded shortcodes from a 12-year-old install is a project of its own. Vague migration language is where five-figure surprises live.

Third-party costs. Hosting, plugin and theme licenses, email services, search, CDN, payment processing. These belong in the proposal even when they're billed directly to you, because they're part of what the site costs to own. A proposal that omits them isn't lying, exactly. It's just letting you discover the real total on your own time.

Accessibility. If WCAG isn't mentioned, it isn't happening. "ADA-friendly" is not a standard. Look for a named conformance target (WCAG 2.2 AA is the current bar), and ask whether it's verified by audit or just intended. For Colorado organizations especially, this stopped being optional a while ago; public entities are under explicit deadlines and private-sector suits keep climbing.

Post-launch support. The site will need updates the week after launch. The proposal should say who does them, at what rate, with what response time, and whether a retainer or hourly arrangement applies. "30 days of bug fixes" is a warranty, not a support plan; ask what day 31 looks like.

Red flags, in rough order of expense

  1. A single number with no breakdown. One price for "website design and development" makes comparison impossible and negotiation worse. You can't remove what was never itemized.
  2. Timeline with no dependencies on you. Every real project waits on client content, feedback, and approvals. A proposal that doesn't say what it needs from you (and what happens to the schedule when it's late) has a timeline written for the sales meeting, not the project.
  3. Payment schedule detached from deliverables. Deposits are normal and fair; we take one ourselves. But payments after the deposit should map to visible milestones: design approval, staging delivery, launch. "50% up front, 50% on completion" leaves the definition of "completion" as a hostage negotiation.
  4. Ownership language that isn't there. You should own the site: code, design files, content, accounts. If the proposal is silent, ask directly who owns what on the last invoice's payment, and what happens if you part ways mid-project. A vendor who hosts everything under their own accounts and hesitates on this question is building a moat around your business.
  5. No named humans. "Our team" designs nothing. Who is doing the work, and is any of it subcontracted offshore without your knowledge? You're not owed a full roster, but you're owed honesty about who you're actually hiring.

The five questions that sort your shortlist

Send these to every vendor still standing. The answers matter less than how they're answered.

  1. "What's the most likely thing to go wrong on this project, and how do you handle it?" Vendors with experience have an immediate, specific answer. Vendors without it say nothing ever goes wrong.
  2. "What would make this cost more than the proposal says?" You're asking them to disclose their change-order triggers up front. A good partner answers eagerly, because it protects them too.
  3. "Can I speak to a client from two years ago?" Not last month's launch. Two years out is where the support experience, the honesty of the maintenance plan, and the quality of the build have all shown themselves.
  4. "What do you need from us, and when?" Tests whether their timeline is real, and previews what working with them demands of your team.
  5. "If we ended the engagement at the halfway point, what would we walk away with?" The answer reveals ownership, documentation habits, and whether their process produces value continuously or only at the end.

Cheap, expensive, and priced-about-right

Our benchmark post covers the numbers, so here we'll only add the pattern: proposals cluster, and the outliers are information. The proposal at half the median price is missing scope you'll pay for later, using templates presented as custom work, or built on labor arrangements that won't survive your project. The proposal at double the median is either serving a much bigger risk profile than you have, or testing whether you're price-sensitive. Neither is automatically wrong. Both deserve the question: "walk me through why this number is different from the others I'm seeing."

The proposal you want is rarely the cheapest and almost never the vaguest. It's the one that makes your obligations, their obligations, and the definition of done boring and explicit. Boring proposals come from teams that have shipped enough projects to know where the bodies are buried, and that's exactly who you want digging.

If you'd like a proposal you can hold to this standard, ask us for one. We'll happily answer all five questions unprompted.

#pricing#proposals#procurement#agency#contracts

Need help with your project?

Let's discuss how Digital Pixel can help bring your vision to life.

Get in Touch