What custom software actually costs, and what drives the number
Any firm quoting a figure before understanding your scope is guessing. What genuinely moves the number is scope, integration count, data migration quality, compliance requirements, and whether you need a prototype or a production system. The most useful thing you can do is get two firms to quote the same narrowly-defined first deliverable — comparable quotes tell you far more than a range ever will.
How much does custom software cost?
How to decide:
You want a number before defining scope. Configure. Nobody can price an undefined system honestly. Spend a short paid discovery instead, and own the output.
You need to prove the idea works before committing. Build. A narrow prototype is a fraction of a production build and it de-risks the real decision.
The requirement is genuinely standard. Buy. No custom quote beats a mature product on a commodity function, whatever the number is.
You are comparing quotes that differ by more than three times. Configure. They are almost certainly quoting different things. Re-specify one identical deliverable and re-ask.
What drives the cost:
Scope, and it dominates everything else. The number of objects, screens and workflows drives the number more than the technology, the country, or the seniority of the team. Halving scope roughly halves cost and more than halves risk.
Integrations. Each external system is discovery, credentials, error handling, and permanent maintenance. Well-documented modern APIs are cheap; a legacy ERP with no documentation is a project of its own.
Data migration. Priced on the state of your data, not its volume. Clean and consistent is fast; fifteen years of free-text fields and duplicate entities is where projects overrun.
Compliance and audit requirements. Provable history, retention rules and access control add real work. They are also the requirements most often left out of a brief and discovered halfway through.
Prototype or production. Something to look at and something a business can run on differ by an order of magnitude. Be explicit about which you are buying, because vendors quote different ones.
Who maintains it. Ongoing cost exists whether or not it is quoted. A build with no maintenance budget has simply deferred the number.
How much of your own time you can give. The cheapest projects have an internal owner who answers questions the same day. The expensive ones are expensive partly because decisions took three weeks each.
What people get wrong:
Comparing quotes for different things. Two firms will scope the same brief differently unless you force a single, specific first deliverable. Without that, the cheaper quote is usually the smaller one, not the better value.
Buying the biggest scope first. Ship the smallest genuinely useful thing, in production, then decide. This is also the best test of whether the firm can deliver at all.
Not owning the discovery output. If you pay for discovery, the specification is yours and you can take it elsewhere. Confirm that before you start.
Treating the lowest quote as the cheapest outcome. A build that has to be redone costs the first quote plus the second plus the lost months. Judge on the specificity of the questions you are asked, not the number.
Why do quotes for the same project vary so much?
Because they are rarely for the same project. One firm quotes a working prototype, another a production system with migration and integrations. Force a single narrow deliverable and the spread collapses.
Is offshore development cheaper?
The hourly rate is lower and the total cost often is not, because scope, communication overhead and rework dominate. Rate is one of the smaller variables in this list.
Should we pay for discovery?
Yes, if the output is a specification you own and can take to any firm. A free discovery is a sales call, and it produces a document designed to be quoted by exactly one vendor.
How do we keep a build from running over?
Small first scope, one internal decision-maker who responds quickly, and something in production early. Overruns are almost always scope and decision latency rather than engineering.
Last reviewed 22 August 2026