Comparing three proposals that are not comparable

Three web proposals for the same brief rarely describe the same project. Comparing web proposals means comparing scope boundaries, assumptions and ownership — not the bottom-line total. Normalise every line into one table, price the unknowns, and confirm who holds the domain, the code repository and the hosting account after launch.

Key Takeaways

• A proposal is a scope plus a set of assumptions, and the assumptions usually decide the real cost.
• Normalise all three quotes into one table before you compare any figure at all.
• Discovery, content migration, integrations and revision rounds are where scope quietly grows.
• Ask who owns the domain, repository and hosting account, and get the answer in writing.
• A page-builder build is fine until you need logins, payments or fast mobile pages.
• Hosting, maintenance and licence renewals shape the two-year picture, not the build fee.
• Two reference calls with past clients beat any portfolio screenshot.

Why do three proposals for the same brief look nothing alike?

A proposal is a scope document wrapped in assumptions, and the assumptions do the work. One vendor prices a fixed ten-page brochure site on a page builder. Another prices a content-managed platform with staging, backups and an editor your staff can actually use. The brief said one sentence. The two documents describe different projects, so the totals were never comparable.

The gap widens with anything dynamic. Logins, payments, stock sync, a booking calendar, an internal approvals flow — each one drags in authentication, data modelling, error handling and testing. A vendor who has shipped that before prices it as a known quantity with a realistic buffer. A vendor who hasn't prices it optimistically and finds the gap in week six, usually by asking you for more time or more money.

What should you compare before you look at the total?

Compare the deliverables list, not the summary page. Pull out what gets built, what gets configured, who writes the content, how many design revisions are included, whether a staging environment exists, and what testing happens before launch. Those six items explain most of the difference between quotes, and they are the first things renegotiated when a deadline slips.

• Deliverables — pages, templates, components, and what is custom versus configured.
• Discovery — how many workshops, and who writes the specification you'll be held to.
• Content — who drafts copy, who migrates existing pages, who prepares images.
• Design rounds — how many revisions are included before extra work starts.
• Environments — is there a staging site, or do changes go straight to production?
• Integrations — payments, email, CRM, accounting, courier or SMS gateways.
• Testing — browsers, devices, accessibility, and who signs off on each.
• Aftercare — support window, what counts as a bug versus a change, and who answers.

If you want a second opinion on those answers before you sign anything, our team can help you review a brief and a proposal side by side, and you can see the kind of work we ship on our project portfolio.

Which parts of a proposal actually drive the cost?

Cost follows complexity, integrations and content — not page count. A five-page site with a payment gateway, tax rules and a courier API costs more to build than a twenty-page marketing site. Discovery hours, data migration, third-party licence fees and the number of people who must approve each round of design are the real levers, which is why our breakdown of a web development quote reads line by line rather than page by page.

Two costs sit outside the build entirely. Hosting is driven by traffic, storage, database size and how much you want managed for you. Maintenance is driven by how much the platform moves underneath you: WordPress core and plugin updates, library upgrades, certificate renewals, and the engineer time to apply them without breaking the checkout. Ask each vendor to describe those two lines qualitatively, then confirm current figures with the vendor's own pricing calculator before you commit.

When is the cheapest proposal the right one?

The cheaper option wins when scope is genuinely fixed. A brochure site, a small landing-page set, a straightforward WordPress build on a well-supported theme — low traffic, no logins, no payments, no integration. There, extra discovery and custom code add cost without adding value, and a clean off-the-shelf build is the honest answer.

It stops being the right answer the moment the site touches money or identity. Anything with user accounts, payments, stock levels, regulated data or a workflow your staff depend on needs a data model, error handling and tests. That is not gold-plating; it is the difference between a bug you fix in an afternoon and one you find out about from a customer.

How do you normalise three proposals into one table?

Build one row per deliverable and one column per vendor, then write "not stated" wherever the proposal is silent instead of assuming it's included. Do this before anyone discusses money. The exercise takes about an hour and usually shows that the middle quote is the only one actually covering what you asked for.

1. Write your own requirements list first, before reading any proposal.
2. Create a spreadsheet with one row per requirement and one column per vendor.
3. Mark each cell as included, excluded, or not stated — no blanks, no guesses.
4. Separate build from run: hosting, domain, email, maintenance and updates get their own rows.
5. List the assumptions each vendor has made, and flag every one you disagree with.
6. Ask each vendor the same five written questions and compare the answers, not the tone.
7. Only then rank by total, and re-rank by what happens if the assumption is wrong.

What does a proposal leave out, and what does that cost later?

The expensive omissions are quiet. "Content migration included" might mean fifty pages or five hundred. "Hosting arranged" might mean an account in the vendor's name that you cannot reach. "Training" might mean one screen-share recorded on someone's phone. Each vague line becomes a change request around month three, when you've already launched and lost your leverage.

Watch for the licence trap too. Some page builders, form tools, booking engines and e-commerce extensions charge per year or per seat, and the renewal lands on you. That is not a reason to avoid them, but it belongs in the comparison as an ongoing line, not a footnote.

Who owns the code, domain and hosting after launch?

Ownership is the line item nobody reads and everybody regrets. Ask for the domain registrar, the DNS zone, the code repository, the hosting account and the SSL certificate to sit in your company's name, with the vendor added as a user rather than the owner. If your DNS lives inside someone else's account, moving it later means coordinating record changes and TTL expiry while your email hangs in the balance.

Ask the question early, and ask it in writing. A vendor who hesitates about handing over repository access is telling you something useful. For a fuller list of the questions that separate a safe engagement from a risky one, read our guide to the questions to ask before accepting a web proposal. If DNS records are part of the handover, the vendor's own documentation on managing DNS records is the plainest reference for what actually changes.

What breaks when you choose on total alone?

Nothing breaks on day one. It breaks at month four, when a staff member tries to update the homepage and finds there is no editor, so every text change becomes a paid ticket. Or when an unmaintained plugin conflicts with a core update and the checkout page returns a 500 error during a campaign. Or when the site is fast on the developer's laptop and slow on a mid-range Android phone over 4G, because nobody measured it.

• No staging environment, so every change is tested in production.
• A page builder nobody else will maintain, with content locked inside shortcodes.
• Hosting on a shared plan that buckles under a modest traffic spike.
• Credentials held by the vendor, with no documented handover.
• No error tracking or uptime alerting, so you learn about outages from customers.

Debugging this later is straightforward but slow: get repository access, run a page-speed audit on a real device, check the plugin list and its last-update dates, confirm the PHP version, and check who holds the registrar login. Fixing it is a migration, not a patch — which is exactly why the comparison matters before you sign.

How do you verify a vendor's claims before signing?

Open two of their live sites on your phone over mobile data and time the first meaningful paint. Ask who on their team writes the code and whether that person will be on your project. Then call two references and ask one question: what broke, and how quickly did they fix it? Enthusiasm is easy; recovery stories are evidence.

A realistic scenario

A Kathmandu retailer wants to sell online and collects three quotes. The lowest proposes a themed build with a payment plugin and no staging site. The middle proposes a WordPress build with a staging environment, a content model, payment and courier integration, and a maintenance plan. The highest proposes a custom application with its own admin panel. On the total alone, the cheapest looks obvious.

Normalised, the picture changes. The cheap quote assumes the retailer writes and uploads every product, excludes courier integration, and hands over no repository. The custom build solves problems the retailer does not have yet. The middle quote covers what the business actually does today, with room to grow. That is usually the answer — not the cheapest, not the biggest, but the one whose assumptions match reality.

In short

Comparing web proposals is a scope exercise, not a beauty contest. Normalise the deliverables, price the unknowns, check ownership of every account, and verify with references. Pick the proposal whose assumptions match how your business will actually run the site next year — and get the handover terms written into the agreement before work starts. Our team can help you review proposals or write a clearer brief; start with our software development services or check the frequently asked questions about how we scope work.

People also search for

• What each line in a web development quote actually covers
• Questions to ask before you accept a web proposal
• Custom software versus off-the-shelf: which fits your budget
• Shared hosting, VPS or cloud: what your website really needs
• Cross-platform versus native apps and what drives the cost
• Why two quotes for the same website differ so much
• How to compare website maintenance and support terms

If you're holding three proposals and none of them quite lines up with what you need, our team can help you read them properly and plan the build in the right order. Send the brief and the quotes through our contact page, and take a look at recent work on the Royal Trek Nepal project to see how we scope and deliver.