A founder sent us a one-page spec last spring along with three quotes she had already collected: roughly $28,000, $61,000, and $130,000. Same PDF, same feature list. She wanted to know which agency was lying.
None of them. They had priced three different projects that happened to share a PDF. One quoted two junior developers and assumed the integrations would "just work." One quoted a senior team with QA and a buffer for the payment provider nobody had documented. One priced the risk of locking a vague spec at a fixed price. All three numbers were defensible. Only one of them described the project she actually needed.
We write quotes from the vendor side every week, so we see this gap from the other side of the table.
What sits inside the number
A software quote is a stack of cost layers plus two judgment layers. Take a $50,000 fixed quote for a six-week build. Stripped down, it usually looks something like this:
| Layer | Typical share | What it pays for |
|---|---|---|
| Discovery and specification | 5-10% | Turning the brief into testable scope |
| Engineering | 40-50% | Named developers times weeks |
| Design | 0-15% | Zero when screens already exist |
| QA and testing | 10-15% | Test cases, devices, regression passes |
| Project management | 10% | Planning, client communication, releases |
| Buffer for unknowns | 10-20% | The bugs and gaps nobody can foresee |
| Margin | 15-25% | Profit, sales cost, warranty reserve |
The shares overlap and every agency blends them differently; nobody shows you this table unprompted. We still see this stack in almost every quote we write or review. The only question that matters when comparing bids is which layers each vendor shrank, and which they deleted.
Deletion is the norm at the bottom of the market. QA goes first, because buyers rarely ask who tests. Project management is next, because "direct access to developers" sounds like a perk until nobody runs the project. Buffer is the last to go, replaced by optimism. A $28,000 quote is very often a $50,000 quote with those rows removed and the engineering row staffed by juniors. The work those rows describe still has to happen. It just happens on your time, billed as change orders, or not at all, billed as defects you discover after launch.
Buffer is the honest judgment layer. A vendor that shows a 15% contingency understands the work. Gut estimates run low; that is why IFPUG still teaches function point analysis. Almost no web agency uses the method, but the good ones keep the lesson in the buffer. Margin is the other judgment layer: 15-25% is ordinary and healthy. Below 10%, the vendor plans to earn the margin somewhere you cannot see, usually the change log. Above 30%, you are paying for a brand or a sales team, which is fine if that is what you want to buy.
Why the same spec returns three different prices
1. The people are different
This explains more of the gap than everything else combined. A senior engineer who has shipped payment integrations five times and a junior seeing Stripe webhooks for the first time both appear on quotes as "developer, 4 weeks." Their output differs by multiples, and so does their fully loaded cost. Ask for names or at minimum seniority levels and a start date. "A team will be assigned after signing" means the quote was priced with whoever is free that month, and you will meet them when it is too late to object.
2. The assumptions are different
No spec under fifty pages is complete, so every vendor fills the gaps with guesses. The cheap bid assumes the easy reading of each gap: the API is documented, the content migrates cleanly, the client reviews within days. The expensive bid assumes the historical reading. Both vendors read the same PDF. Ask each bidder to attach their assumption list to the quote. The lists will differ, and the differences are worth more than the totals. An assumption you disagree with is a change order wearing a disguise.
3. The exclusions are different
Check what is missing before admiring what is listed. Content migration, app store submissions, analytics setup, email deliverability, accessibility audits, documentation, training, post-launch support: each is a five-figure line hiding in at least one of your quotes under "not included." The honest quote has an explicit exclusions section. The bid with the longest exclusion list is often the most trustworthy, because its total covers everything else. Demand the list from vendors who omit it. Silence on exclusions is a pricing strategy, not an oversight.
4. The risk premium reflects the contract type
A fixed-price quote on a vague spec carries an insurance charge, 20-40% above the same work quoted open-ended, because the vendor absorbs every surprise. Under German law this maps to the Werkvertrag in the Bürgerliches Gesetzbuch: a result is owed, so the risk of the result sits with the contractor until acceptance. Time-and-materials quotes carry almost no premium, since you absorb the surprises instead. Neither arrangement is a trick. But comparing a fixed bid against a T&M bid on totals alone compares an insured price with an uninsured one, which flatters the T&M number every time. Normalize by adding a realistic overrun to the T&M side before comparing.
5. The pipeline situation leaks into the price
The factor nobody admits. A vendor with a full pipeline quotes high to make your project worth the disruption; a vendor with bench capacity quotes low to keep the team busy. Same spec, same vendor, different quarter, different number. You cannot observe this directly, but you can hear it: ask when the team starts. "Next Monday" in a supposedly busy agency tells you something. So does a quote that expires in seven days versus one valid for two months. Neither signal disqualifies anyone. They calibrate how hard to negotiate and how much weight to give the number versus the team.
How to make quotes comparable
Normalization is manual work, about half a day for three bids, and there is no shortcut. Send every bidder the same breakdown template and require all five answers back in writing: team composition with seniority and start date, the assumption list, the exclusions list, the milestone plan with acceptance per milestone, and day rates for change work. Vendors who answer completely go to the final round. Vendors who answer with "our standard process covers all of that" do not, because a process is not a commitment and you cannot enforce one.
Then rebuild each quote in your own spreadsheet. Add back the missing layers at market rates: QA at roughly 15% of engineering, a buffer of 15% on any fixed bid that shows none, the excluded items you actually need. Our Germany-specific cost guide (app development costs in Germany) gives current rate bands for this arithmetic, and our MVP cost breakdown shows what a scoped-down first version costs when the full quote scares you.
One warning from experience: do not share one vendor's price with another and ask them to beat it. You will get a lower number and a thinner project, since the only fast way to cut 20% from a software quote is removing work you cannot see. Negotiate scope instead. "What would this cost without the admin panel in phase one" produces honest reductions. "Can you do it for 40k" produces creative ones.
What each quote type hides
Every pricing model hides something, so match the model to how well you understand the scope. Fixed price hides the change log: the vendor recovers every ambiguity there, at rates you should have fixed upfront. Time and materials hides the total: spending drifts toward the available budget, and the Agile Manifesto preference for responding to change becomes, in undisciplined hands, a license to never finish. Our position after years on the vendor side: fixed price for defined scope with written acceptance criteria, time and materials for exploration, and a paid discovery phase in front of either when the spec is under ten pages. Discovery is the cheapest money in the project. It converts a guess into a plan, and the plan is what every later number rests on.
The quote test
Lay the normalized bids side by side and pick the one you can take apart, not the cheapest one. The winning quote names its people, lists its assumptions, admits its exclusions, and prices its changes in advance. That vendor has shown you the project as they see it, including the ugly parts. The bid with the lowest total and none of that is not a bargain. It is a number that will not survive contact with the work.
If you are staring at competing bids right now, send them through our contact page and we will tell you what we see in them, including where our own number would land. Our services page lists the engagements we quote most often, so you can check whether your project is one of them before the call.
Frequently asked questions
How many quotes should I collect for a software project?
Three to four qualified bids is enough. Fewer and you cannot calibrate; more and you spend weeks comparing instead of building. Disqualify fast on missing exclusions lists and unnamed teams, then normalize the remaining two or three line by line.
Should I just pick the cheapest software quote?
Only after normalization, and normalization rarely leaves the cheapest standing. Very low bids usually exclude QA, project management, and buffer, or assume junior staffing throughout. Add the missing lines back at market rates and compare again; the ranking almost always changes.
What must a software quote contain at minimum?
Scope with assumptions attached, a named team with start dates, a timeline with milestones, an explicit exclusions list, a payment schedule tied to acceptance, and day rates for change work. A number without these six is a guess with a logo, not a quote.
Why do agencies ask for paid discovery before quoting?
Because an honest quote is built on a spec, and a good spec is a week of work. Agencies that quote fixed prices off a two-page brief are either padding blindly or planning to recover the gap through change orders. Paid discovery produces the document the quote is actually based on, and you keep it even if you walk away.
