Insights · 5 min read

Why custom software quotes vary by 3x (how to read them)

Two vendors quote the same build at 3x apart. It's rarely greed. Here's what actually moves custom software cost and how to compare quotes without being a developer.

By GGP Editorial

If you've ever sent the same requirements to three development companies, you know the feeling. One comes back at $40,000, another at $120,000, and you're left wondering which one is ripping you off and which one is about to collapse halfway through.

The gap is real, and it's usually not greed. The same five-page brief reads very differently to different teams, and the honest quotes are pricing very different things. Here's how to read them.

What actually moves the number

Most of the spread comes down to four things, and none of them show up as a line item on the quote.

Assumptions about scope. One team reads "payment integration" as plugging in Stripe. Another reads it as a second payment method, plus refunds, plus reconciliation, plus a fallback when the gateway is down. The second quote is higher because it's pricing the version you'll actually need.

Who writes the code. A senior engineer in New York costs three to four times what a senior engineer in Shenzhen costs, for roughly the same output. That's the single largest driver in most quotes, and it's why location deserves as much attention as the tech stack.

What's included after launch. Some quotes cover two weeks of post-launch fixes. Others bundle three months of support, monitoring, and small changes. A quote that's 20% higher on paper can be cheaper once you add up the maintenance you'll buy anyway.

The unknowns they're willing to carry. Software estimates are guesses about a future neither side has built yet. A fixed, low quote usually means the vendor is quietly planning to say no to changes later. A higher quote often includes room for the things you'll discover.

Reuse from past projects. A team that has already built a property system or a trading platform starts from a working base instead of a blank screen. That should lower the quote, and it lowers the risk too. Worth asking what similar systems they've shipped, and whether they can show you one.

Read the quote, not the total

The headline number is the least useful part of a quote. When two come in far apart, ask each vendor to break theirs into the same buckets.

Line itemWhat to check
Discovery / scopingA real phase with interviews, or a placeholder fee?
DesignHow many screens, and how many revision rounds are priced?
DevelopmentWhich features are listed, and which are assumed?
IntegrationsEach third-party service named, or lumped together?
TestingWho does QA, and is it included or billed hourly?
Post-launchSupport window length, and what counts as covered

A quote that won't break down this way is a quote to be careful with. A team that prices a lump sum with no line items hasn't thought about your project hard enough to be trusted with it.

The questions that expose a bad quote

You don't need to be technical to test a quote. Three questions do most of the work.

Ask what happens when you change a feature after the first demo. A team that says "we'll handle it" and a team that says "changes beyond the agreed scope are billed at X per hour" are both fine, in different ways. A team that gets vague or defensive is not.

Ask who you'll talk to after the contract is signed. If the senior people you met disappear and you're handed to someone new, the quote was a sales artifact.

Ask for one reference who left and one who's still a client. The one who left tells you more.

Fixed price isn't always the safer bet

People reach for a fixed price because it feels safer. You know the number up front, so the risk feels contained. In practice a fixed price shifts the risk onto the vendor, and the vendor protects themselves by padding the number and refusing changes. Time and materials looks riskier because the number is open, but you pay for what's actually built and you can change direction without renegotiating.

Neither is wrong. The point is to know what you're buying. A fixed quote works when the scope is genuinely locked and small. Time and materials works when you expect the requirements to move, which is most of the time.

A realistic number, for reference

Custom software is genuinely expensive, and that's worth saying plainly. A small web app with a few screens runs $20,000 to $60,000. A platform with payments, user roles, and a mobile app lands between $80,000 and $200,000. Enterprise systems go well past that. If a quote is far below these ranges, someone is under-pricing the work or under-scoping it, and you'll pay the difference later either way.

We build for clients in Brazil, South Africa, Singapore, and the US, and the cost lesson we repeat most is simple: the number to worry about isn't the quote, it's the total across the first year. That total includes changes, integrations, and the support the cheap quote left out.

Get the quotes broken into the same buckets, ask the three questions, and compare the first-year total instead of the headline. That's how you stop overpaying for the wrong thing and start paying a fair price for the right one.

Talk to us about your project

Need help applying this?

Tell us what you are building and where you are today. We typically reply within 24 hours.