Three agencies have quoted for the same project. The prices are $18,000, $47,000, and $95,000. The scopes look broadly similar. Someone is wrong, and you can't tell who.
This happens constantly, and it isn't usually dishonesty. Quotes differ because vendors make different assumptions, include different work, and interpret vague requirements differently. Your job is to make those differences visible before you choose.
Why the spread is so wide
Different assumptions about the same words. "User management" might mean a login screen, or it might mean roles, permissions, invitations, audit logs, and single sign-on. Both vendors quoted honestly against different pictures.
Different things included. One price covers design, testing, project management, deployment, and post-launch support. Another covers development hours only, with everything else billed later.
Different regions. A US agency and an Indian agency can charge very different prices for identical work. Our guide to hourly rates by region breaks down what each level buys.
Different levels of honesty about the unknown. The cheapest quote is sometimes the one that hasn't thought about the hard parts yet. It becomes the most expensive quote about four months in.
Normalise before you compare
Never compare headline numbers. Rebuild each quote into the same shape first.
1. Put them in one table, line by line
Discovery, design, front end, back end, integrations, testing, project management, deployment, post-launch support. Mark anything a vendor didn't mention as "not quoted" rather than assuming it's included. The gaps are the interesting part.
2. Add back what's missing
If one quote excludes design and another includes it, add a realistic design cost to the first. Now they're comparable. Usually a couple of the "cheap" quotes move a long way.
3. Check the hidden line items
Ask every vendor, in writing:
- Is project management included, or billed separately?
- Is testing included, or do we test it?
- Who pays for hosting, third-party services, and app store accounts?
- What post-launch support is included, and for how long?
- Are design revisions limited?
- What's the hourly rate for work outside scope?
4. Convert to one currency, and confirm taxes
Obvious, and still missed. Also confirm whether prices include applicable taxes and what payment terms apply.
Read the assumptions, not the price
The most useful page in any proposal is the assumptions section. If there isn't one, that's your answer about how carefully it was scoped.
Look specifically for what's assumed about: the number of user types, how many integrations, whether designs will be supplied, data migration, content, and who handles app store submission. Vague assumptions become change requests later, and change requests are where budgets die.
Ten questions that separate the quotes
Send these to every vendor and compare the answers rather than the numbers:
- What's explicitly out of scope? A confident vendor has a clear list.
- What are you assuming that we haven't told you?
- What's the riskiest part of this project? Anyone who says "nothing" hasn't thought about it.
- How are change requests priced and approved?
- When do we see working software? "Every two weeks" is a very different answer from "at the end".
- Who exactly will work on this? Meet them, not the sales team.
- Where does the code live during the project? Your repository is the right answer.
- What happens after launch, and what does it cost? Budget 15–25% of build cost per year for maintenance.
- What do we get if we stop halfway?
- What would you build differently on a smaller budget? This reveals whether they understand priorities or just have a fixed template.
Price signals worth reading
A quote far below the others may mean a misunderstood scope, work excluded, juniors doing the build, or a deliberately low entry price. Ask what they think they're building and listen for whether it matches.
A quote far above may reflect a different region, genuine scope depth, enterprise overhead, or an agency that doesn't especially want the project. Ask what's included that others left out.
Fixed price versus hourly changes the comparison too. A fixed price carries the vendor's risk premium and requires a firm scope; hourly is cheaper if scope is clear and riskier if it isn't. See our guide on fixed price versus hourly.
Compare capability, not just cost
Price is one of four things that decide the outcome:
- Evidence. Have they shipped something comparable, that's live now? Ask for a URL, not a portfolio image.
- Communication. How fast and how clear were they during the sales process? That's their best behaviour; it doesn't improve later.
- Ownership. Code, accounts, and IP in your name from day one.
- Continuity. Can they maintain it afterwards, and what happens if their lead developer leaves?
Consider paying for scoping
If the three quotes differ wildly, the specification is usually the problem, not the vendors.
A short paid discovery, typically one to two weeks, produces a written scope everyone can quote against. Then you're comparing like with like, and the estimates that follow are far more reliable. Spending a modest amount to make a six-figure decision properly is normally good value.
The one condition: the scope document must be yours to keep and usable with any vendor.
A practical process
- Write the problem down in plain words, including what success looks like.
- Send the same brief to three or four vendors.
- Ask the ten questions above and collect written answers.
- Normalise the quotes into one table, adding back excluded work.
- Talk to the engineers, not just the salespeople.
- Ask for a live product they built and still run.
- Choose on total cost of ownership and confidence, not headline price.
Where we stand
Our rates are published on the pricing page precisely so you can compare without a sales call, and our custom software cost guide includes a calculator to model your own project.
If you want a number to compare against, tell us the scope and we'll send a written, itemized estimate. It's free and it's yours to keep, including if you take it to another vendor.
