What drives the cost of building software
Two products described in the same sentence can differ fourfold in price. Understanding which factors move the number is more useful than any average, and it lets you read a quote properly.
Reading time · 8 min
Scope clarity moves the number before anything technical does
The largest single factor in most quotes is not the technology. It is how precisely the thing being built has been described. A vague brief is priced with a risk margin, because the studio is pricing an unknown and carrying the difference. That margin is invisible on the invoice and often substantial.
This is why a scoping exercise frequently pays for itself before a line of code is written: the same product, specified properly, is cheaper to quote because it is cheaper to be wrong about. If you are comparing two quotes and one is dramatically lower, check whether it is pricing the same scope or simply a less careful reading of the brief.
The factors that actually move it
Platform count is the most mechanical. Web only, web plus one mobile platform, or web plus both — each is a different surface to build, test and support, and the cost does not divide evenly because shared logic helps while platform-specific behaviour does not.
Language count behaves similarly, with a twist: the second language is expensive if it is retrofitted and cheap if it is planned. Arabic specifically brings right-to-left layout, typographic tuning and bidirectional text handling, which is real work the first time and close to free on every project afterwards if the team has the patterns.
Integrations are where estimates most often break, because their cost is set by someone else's system. A well-documented payment provider is routine. An undocumented internal API, a bank portal, or a government system with no sandbox can cost more than the entire product around it — and the honest answer before investigating is a range, not a number.
Then: how much the data model has to enforce. A product where any user can see everything is far simpler than one with roles, hierarchies and an audit trail. Permissions are not a feature you add at the end; they are a shape the whole system takes.
And finally the standard you are building to. An internal tool used by twenty trained staff and a public product used by thousands of untrained people are different products even if the screens match. Error handling, edge cases, accessibility and resilience are most of the difference between a demo and something that survives contact with users.
The costs that arrive after launch
A build price is not a product price. Software needs hosting, monitoring, dependency updates, security patches and someone to answer when it breaks. A quote that covers only the build is not wrong, but you should budget for the rest rather than meet it as a surprise in month two.
The cheapest way to control this is to reduce how much of it you need: test coverage on the paths that carry money and data, automated deployment so releasing is not a person, and documentation good enough that a second team could pick the work up. All three cost a little during the build and a great deal if skipped.
The expensive version is the rewrite — and rewrites are usually caused not by bad code but by nobody being able to safely change it. That is a documentation and testing failure more often than an engineering one.
How to read a quote you have been given
Look for the exclusions first. A quote that lists what it does not cover has been thought about; one that describes only what it includes leaves the boundary to be discovered later, under pressure.
Look for stated assumptions, for the same reason — they are what lets a change be priced by arithmetic rather than argued about. Look for who owns the output, and when. And check whether post-launch support is included, billed, or simply unmentioned.
Then compare like with like. Two quotes are only comparable if they describe the same scope at the same standard, and in practice they rarely do. The useful exercise is not picking the lower number but working out what the difference between them is buying — and whether you want it.
The levers you control
- Specify the scope properly before asking for a price — it removes the risk margin.
- Decide platform count deliberately; each one is a surface to build, test and support.
- Plan the second language from the start rather than retrofitting it.
- Investigate risky integrations before the estimate, not after.
- Be honest about whether you need roles, hierarchies and an audit trail — they shape the whole system.
- Budget for the year after launch, not just the build.
Common questions
Why will no one give me a number up front?
Because a number given before the scope is pinned down is either padded enough to be safe or low enough to be renegotiated later. Neither helps you. What a studio can give early is the range and, more usefully, the factors that would move it.
Is offshore development cheaper?
Per hour, often. Per shipped product, it depends entirely on how much of the cost moves into coordination, rework and supervision. The useful comparison is total cost to a working release, not a rate.
What is the most common way budgets are blown?
An integration whose difficulty was assumed rather than checked, and scope that grew because the deferred list was never written down. Both are avoidable in the week before the build starts.
Related guides
Working on something like this?
Tell us what you're building. We send back a one-page response with scope, timeline, and a number you can plan around.
Send us a brief