Why Software Development Quotes Differ by 3x Between Vendors

You send the same requirements document to three vendors. The quotes come back at ¥4 million, ¥9 million, and ¥12 million. Is one of them overcharging? Is the cheap one planning to cut corners? You can't tell, and a lot of companies get stuck right here before placing an order.

A gap like that isn't unusual. A quote is four numbers multiplied and added together, so if one of them shifts, the total can move by a factor of several. That also means the gap can be explained once you break it into those four parts.

A quote is made of four numbers

Price = Effort x Rate + Buffer
        ^ "what's included" drives this part

The quote only shows a total, but underneath it looks like this. When quotes differ by 3x, more than one of the four is off at the same time.

Effort: it depends on what got counted

Take a "login feature." If a vendor counts only the implementation, it might be 3 person-days. Count design, review, testing, bug fixing, and handling spec changes too, and the same feature becomes 12.

Experienced vendors count the second way. They know testing and review take about as long as the implementation itself. When a quote from a vendor who didn't count that work looks lighter, the work hasn't gone away. It just hasn't been counted yet.

A small effort estimate doesn't always mean corner-cutting. Vendors with in-house templates for authentication, admin screens, and permissions don't build those from scratch every time. The more they can reuse, the smaller the effort legitimately gets. Ask "why does it only take that much?" and you'll be able to tell the difference.

Rate: who is doing the work

Monthly rates per engineer depend on the vendor's size and structure. If a prime contractor takes the job and passes it to a subcontractor, the middle layer's margin ends up in the rate. A high rate isn't bad in itself. What matters is whether you can see who actually does the work for that money.

The questions are always the same. Is the person designing the system the same person building it? How many people are on the project, and at what allocation? Is the team expected to change partway through? Comparing rates alone tells you nothing.

Scope: where the biggest gaps come from

This is where prices really diverge. Some items never show up as a line on the quote.

Item	What happens if it's missing
Joining requirements definition	You have to nail down every undecided spec yourself
Testing	Verification becomes your job. Bugs surface after release
Environment setup (production, staging)	Development is done, but there's nowhere to run it
CI / deployment pipeline	Every release is done by hand
Monitoring and backups	You find out about outages from your users
Documentation	You can't hand the next round of changes to another vendor
Data migration	Moving data from the old system gets quoted separately
Post-release bug fixes	Fixes after acceptance become extra charges

Leaving these out isn't dishonest on its own. It means "this quote assumes X," and a quote with its assumptions written down is a proper quote. The problem is the quote that doesn't state its assumptions. Those costs come back later as extra charges.

Buffer: insurance against uncertainty

The vaguer the requirements, the more margin the vendor builds in. If the spec says "details will be decided during development," quoting for the worst case is a reasonable call.

This is also one of the few variables the buyer can move. Firm up the spec one more level and ask for a new quote, and the price sometimes drops. When a quote feels high, making the requirements more concrete works better than negotiating a discount.

What's missing from a cheap quote

When you're looking at a cheap quote, there's a fairly standard order to check things in.

Testing. Will they write unit tests? Who does integration testing? A quote that assumes no tests has a lower upfront cost, but every change afterward takes more manual verification. After six months of operation, the math can flip.

Environment setup. Will they build a staging environment, not just production? Projects without one end up testing for the first time in production.

Non-functional requirements. How many people will use it at once, how fast it needs to respond, and how far back you can restore if data is lost. If those three aren't in the requirements, they won't be in the quote either. Rebuilding after you discover performance isn't good enough is expensive.

Post-release support period. How long after delivery will they fix bugs at no charge? One month, three months, or not at all?

Documentation. Without setup instructions and an explanation of the data structure, handing the system to another vendor later gets much more expensive.

What to look at when comparing

Before lining up the prices, you need to put the quotes on the same footing.

1. Are the assumptions written down? A quote that says "this does not include X" can be trusted. A quote that says nothing doesn't give you enough to compare
2. Is it broken down? Look for effort per feature, not a single lump sum. If it's broken down, you can decide which features to cut to fit the budget
3. Acceptance criteria. What counts as done? Projects with vague criteria end in a tug-of-war over "that's extra" versus "that should be included"
4. What happens when things change? How are mid-project spec changes handled? Quoted each time, or included up to a certain point?
5. Maintenance and operations. What do you get for the monthly fee? Who do you contact during an outage, and during what hours?
6. Validity period and re-quote conditions. When will they re-quote if the requirements change?

Once these six are aligned, part of the price gap turns out to be a difference in assumptions. What's left after you remove that is the real difference worth comparing.

When the gap is justified, and when it isn't

A justified gap is one that can be explained. Broader scope, writing tests, more experienced people on the team, including migration work. Ask why, and the vendor can point to exactly where the number moved.

An unjustified gap doesn't come with an answer. A quote that ends with "it's roughly this much" either has no basis or comes from a vendor who doesn't want to show the breakdown. Either way, the price is likely to change after you sign.

Rather than looking at whether the number is high or low, check whether your questions get answered with numbers. That's the more reliable signal.

If you still can't decide

When you can't decide even with the quotes side by side, the problem usually isn't the quotes. The buyer is missing information to decide with. A quote with unstated assumptions gets filled in once you ask the vendor. Most people get stuck because they don't know what to ask.

We also take consultations from companies that already have quotes from other vendors. Before you choose a vendor, we can talk through how to align the assumptions and how far the requirements need to be pinned down before the price moves. It's fine if it ends with just a conversation.

Get in touch