Ask three firms to quote the same product and you can get $40k, $150k and $400k. That spread isn't fraud; it reflects genuinely different teams, scopes and risk. The global software outsourcing market is worth roughly $613 billion in 2025 precisely because companies are constantly making this build-cost calculation. The problem is that a single dollar figure compresses a dozen decisions into one number, and unless you unpack them you can't tell whether the cheap quote is a bargain or a trap. Here's how to read a quote.
What you're actually paying for
A software price is mostly senior time × risk × scope. Three projects with the same feature list can cost wildly different amounts because:
- Seniority differs. Hiring a single bad developer can cost 30% of their first-year salary just to replace, and far more in shipped bugs and lost time. Cheaper teams often mean more, less-experienced hands, which shows up later as rework rather than savings.
- Scope is fuzzy. “A marketplace app” can mean two screens or two hundred. Vague scope is the number-one driver of the 27% average budget overrun, because every unstated assumption becomes a change order once work begins.
- Quality bar differs. Tests, accessibility, security review and documentation cost real time, and save far more later. A quote that omits them isn't cheaper; it's deferring the bill, with interest.
Think of it as paying for the probability your project ships and keeps working, not for lines of code. A higher number from a team that has done it before is often buying down risk you'd otherwise pay for in delays and a second attempt.
A concrete example
Take a customer-portal project: login, dashboard, a payments integration, an admin view. The $40k quote is realistically three screens, a single mid-level developer, no automated tests, no real security review, and "we'll figure out payments later." The $150k quote is the same screens plus proper auth, a tested payments flow, error handling, basic accessibility, and a senior reviewing the work. They are not the same project; they only look the same on a feature list. The cheaper one often arrives at the $150k total anyway, just later and after a painful detour.
Rough 2026 ranges
- MVP / proof-of-concept: $40k–$90k for one focused product, a small senior team, 2–3 months.
- [Production product](/services/custom-software-development): $90k–$300k for real users, integrations, security, scale.
- Enterprise platform: $300k+ for multi-team, compliance, legacy integration, SLAs.
These are starting points, not promises; the only honest number comes after a short discovery. Be wary of any firm that quotes a precise figure before understanding your scope; either they're padding heavily to cover the unknowns, or they'll come back with change orders once they hit them.
How to compare quotes fairly
- 1.Normalise the scope. Write one spec and have everyone quote that. Otherwise you're comparing different projects with the same name, and it's worth reading our checklist for choosing a software development partner before you send it out.
- 2.Ask what's excluded. QA, deployment, project management and post-launch support are where "cheap" quotes hide their real cost. Get the exclusions in writing, and compare that against our published pricing so you know what a fair number looks like.
- 3.Price the maintenance tail. Software costs money every year it lives: hosting, dependency updates, fixes, small changes. A quote that ignores maintenance is incomplete; the running cost of a system over a few years often rivals the build. We covered why that tail matters, and it's doubly true for anything with an AI component, where inference and monitoring are ongoing.
- 4.Weigh the risk discount. A team that has shipped at your scale before carries less delivery risk. That's worth paying for, and it's the part of the price that's hardest to see on the invoice. It's also why how long an MVP actually takes to build is worth reading before you anchor on a launch date.
The questions a quote should answer
Before you accept any number, make sure the quote answers these. If it doesn't, the gaps are where the cost overrun lives:
- Who is actually building this, and how senior are they? Seniority is the single biggest line item hiding inside the total.
- What's included in QA, security and accessibility? "Working software" and "production-ready software" are months apart.
- How are changes priced? A change-order policy you only read after signing is a change-order policy designed against you.
- What does support cost after launch, and for how long? The first month after go-live is when the real bugs surface.
A vendor who answers these crisply is giving you a comparable number. One who waves them away is giving you a headline that will move.
When the cheaper quote is genuinely right
Not every project needs the premium option, and pretending otherwise is just a different way to waste money. If you're testing an idea that may not survive contact with users, a lean build from a smaller team is the rational choice, since spending enterprise money to validate a hypothesis you haven't proven yet is its own kind of overrun. The same logic applies to internal tools with a handful of forgiving users, or to a throwaway prototype whose only job is to settle an argument about whether something is worth building at all. The judgement call is matching the spend to the stakes: for a throwaway experiment, go lean and cheap; for a revenue-critical system that your customers and reputation depend on, pay for the team that won't drop it. The mistake in both directions is the same, a failure to ask what this particular software is for before deciding what it should cost.
The expensive quote is sometimes the cheap one. Re-building a failed project means paying twice.
Want a real number for your project? Send us the scope and we'll come back with a transparent, itemised estimate in 48 hours.