What drives the cost of custom software

This guide does not publish price ranges. Any range wide enough to be true would be too wide to be useful. What it does is explain what moves the cost, so you can read a quote critically and get quotes you can actually compare.

Why quotes vary so much

A short brief leaves most of the decisions unmade. Each firm fills the gaps with its own assumptions: one assumes a simple approval flow, another assumes delegation and escalation; one assumes the ERP integration is a nightly file, another assumes real-time with retries. They are pricing different systems that happen to share a name.

The fix is to give every firm the same written scope — and to ask each to list its assumptions.

What actually drives the cost

The number of distinct workflows and roles. Each type of user, and each path work can take through the system, has to be designed, built and tested.

Business rules. Calculations, validations, eligibility and exceptions. A process with many rules and many exceptions costs more than one with few, regardless of how many screens it has.

Integrations. Every connection to another system adds design, build and testing — and connections that must handle failure properly cost more than ones that quietly assume the other side is always up.

Data migration. Moving years of data from an old system, cleaning it and reconciling it is frequently underestimated and frequently decisive.

Compliance, audit and privacy. Audit trails, retention rules, access controls and approval chains are real work. They are also much cheaper designed in than added later.

Non-functional requirements. How many users, how fast, how available, how secure. A tool for ten people in one office differs from a system customers depend on around the clock.

Unknowns. Anything not yet decided carries risk, and risk is priced — explicitly in a fixed price, or implicitly in a time-and-materials estimate that later grows.

What drives it less than people expect

The number of screens. A screen that displays information is cheap; the rules behind it are what cost money.

The choice of mainstream technology. Between established, well-supported technologies, the difference in build cost is small compared with the differences above.

Fixed price or time and materials?

The two models put risk in different places.

• Time and materials: you pay for the time spent. Flexible, and suitable when the problem genuinely cannot be defined yet — but the risk of the work taking longer sits with you.
• Fixed price: you pay an agreed amount for an agreed scope. The risk of the work taking longer sits with the builder — which is only possible if the scope is written down precisely enough to price.

A common and sensible combination is to pay for the analysis as a fixed fee first, then fix the price of the build from the resulting specification. That is how we work: the specification is what turns an estimate into a commitment.

Running costs

The build is not the whole cost. Budget for hosting, monitoring, security updates, and the changes the business will want once it uses the system. Ask any firm what running the system will involve, and who can do it if they cannot.

How to get quotes you can compare

1. Send every firm the same written scope, including what is out of scope.
2. Ask each to list its assumptions and exclusions.
3. Ask how changes will be priced.
4. Ask what you will own at the end.

If you do not have a written scope yet, producing one is the cheapest way to make the quotes meaningful — that is our requirements analysis service, and the starting point for most custom software builds.