Price ranges published online are close to useless without context. What matters is which variables move the number — and how to read a quote so you are comparing the same thing across suppliers.
Every article on this subject eventually prints a table of price bands. The ranges are wide enough to be true of almost any project, which is exactly why they tell you nothing about yours. A more useful question is which variables actually move the number, because once you can see those, you can both plan sensibly and read a quote critically.
What genuinely drives cost
The number of distinct workflows
Not features — workflows. A system where five roles each follow a different path through the same data is substantially more work than one where everyone does the same thing with more options. Every role multiplies the permission logic, the interface states and the testing. When scoping, count the distinct journeys rather than the screens.
Integrations with systems you do not control
This is the most consistently underestimated item in the field. Connecting to an accounting package, a carrier or a payment provider is rarely the advertised afternoon. The documentation will be incomplete, the sandbox will behave differently from production, rate limits will appear under real load, and you will need to handle partial failure so a timeout does not duplicate an order. Budget two to three times what the integration appears to need.
Data migration
If existing data must come across, its quality decides the cost. Fifteen years of records with inconsistent formats, duplicates and free-text fields where a code was expected will take longer to migrate cleanly than the new system takes to build. This is worth investigating before anyone quotes, not after.
How certain the requirements are
A documented process with agreed rules is a straightforward estimate. 'We will know it when we see it' is not an estimate, and any fixed price attached to it contains a large contingency — which you pay whether or not it is needed. Reducing uncertainty before quoting is the single most effective way to reduce cost.
Compliance and regulatory requirements
Handling health data, payment details or regulated financial information adds audit trails, encryption requirements, retention rules, access controls and frequently an external assessment. It is not a percentage uplift; it is additional work with its own timeline.
Why two quotes for one brief differ so widely
- They scoped differently. One included data migration, training and three months of post-launch support; the other quoted the build alone. This explains most large gaps.
- Different delivery model. An offshore team at a lower day rate against a local team at a higher one — the comparison worth making is total cost including the management overhead, not the rate.
- One is quoting what you asked for and the other what you need. A higher quote occasionally reflects a supplier who has spotted a requirement you did not state.
- Different contingency. A fixed price carries risk, and the supplier prices that risk. A vague brief produces a bigger buffer.
- One intends to win on price and recover on change requests. This is common enough to watch for: check what the contract says happens when scope changes.
Pricing models, and what each one does to you
| Model | Works well when | The risk you carry |
|---|---|---|
| Fixed price | Scope is genuinely well defined | Change is expensive; supplier may cut quality to protect margin |
| Time and materials | Scope will evolve, and you can steer weekly | Costs are open-ended without active management |
| Fixed price per phase | Most business software projects | Requires discipline to hold scope within a phase |
| Dedicated team | Ongoing development over quarters | You are effectively managing the team, so you need capacity to do it |
Fixed price per phase is the arrangement we use most, because it gives you a firm number for a defined piece of work and a genuine decision point at each boundary — including the decision to stop. A single fixed price for an entire programme sounds safer and generally is not: it forces both parties to negotiate every change against a contract rather than against the goal.
How we arrive at a figure
We do not publish a price list, because a number produced before anyone has read your requirements is a guess wearing the clothes of a quote. The sequence we follow instead is deliberately slow at the start:
- We gather the requirements — what the system has to do, who uses it, which existing tools it has to work with, and what has to be true for the first release to be worth having.
- We establish the scope from that and write it down, including what is deliberately excluded and what is deferred to a later phase. Agreeing the exclusions matters as much as agreeing the work.
- We prepare an initial quote against that written scope, with the assumptions behind it stated, so you can see what the number actually depends on.
- We then go through the requirements and the costing with you, point by point. This is where most of the movement happens: scope gets trimmed, a requirement turns out firmer or looser than it first read, and the figure moves with it.
- Once the scope is settled and nothing material is outstanding, we confirm the final project cost for that phase and the work starts against it.
The cost people forget
Software is not a capital purchase that then sits still. Budget for the ongoing element from the beginning, because it arrives whether or not you planned for it.
- Hosting and third-party services — typically modest, but it is monthly and permanent.
- Security patching and dependency updates. Unmaintained dependencies become vulnerabilities, and the gap compounds: a framework two major versions behind is a project to upgrade, not a task.
- Changes as the business changes. Any system in real use generates change requests, and that is a sign of success rather than a failure of scoping.
- Support for the people using it, particularly in the first few months.
- Plan for the ongoing element as a standing line in the budget rather than an occasional surprise. What it comes to depends on how much the system is used and how fast the business around it changes, so it is worth agreeing at the point the build is scoped rather than after launch.
How to reduce the cost honestly
- Cut scope rather than quality. A smaller system built properly beats a large one built cheaply — the second becomes unmaintainable and gets replaced sooner.
- Build one complete workflow first and put it into real use. You will discover which of your other requirements were assumptions.
- Document your process before requesting quotes. Suppliers price uncertainty, and you remove it more cheaply than they can.
- Use existing products for commodity functions. Payments, email, authentication and analytics are solved; paying to rebuild them is rarely justified.
- Clean your data before migration, using your own team who understand it.
- Be honest about what is genuinely required for the first release. 'Phase two' is a legitimate answer and usually the right one.
And be wary of the lowest quote when it is far below the others. It usually indicates the supplier has not understood the brief, which means the difference will reappear later as change requests — or as a system that has to be rebuilt.
This is the kind of work we do. If it is relevant to something you are planning, our custom software page covers how we approach it, or you can describe the project and we will tell you what we think.