Every firm asking this question wants a number. The reason a good developer won't lead with one is that "custom software" covers everything from a single workflow tool to a platform that runs the whole business — so a headline price is meaningless until the scope is clear. What is knowable is what moves the price, and how to keep it down.
What actually drives the cost
Five factors account for most of the range:
- Scope — how much of the business the software covers. A single process is a fraction of a system that spans clients, work, people, time and billing.
- Complexity of the rules — the logic that governs how your firm works. Trust accounting, funding models, approval gates and compliance obligations all add real engineering.
- Integrations — every system you connect to (accounting, document management, lender or clinical platforms) adds cost, and some are far harder than others.
- Data migration — moving and cleaning years of existing data is routinely underestimated.
- Ongoing support and change — software that keeps fitting as the firm evolves is a running cost, not a one-off.
The one mistake that blows the budget
The single biggest cost risk isn't the day rate — it's vague scope. When nobody has written down precisely how the firm works, the build discovers it as it goes: features get built, shown, found wrong, and rebuilt. That rework is where budgets and timelines disappear.
Most overruns aren't a pricing problem. They're a clarity problem.
This is why the way a build is scoped matters more to the final cost than the hourly rate. Money spent removing ambiguity up front is money saved several times over in build.
Buying cheaper by modelling first
Our approach is to build a formal operating model of how the firm runs before writing code — the things you deal in, how they relate, and the rules that govern them. That model becomes a single specification the software is engineered from, rather than a target discovered mid-build. In practice that compresses timelines to weeks rather than quarters and takes the rework — the expensive part — off the table.
It also changes the cost conversation from "how many features can we afford" to "what is the smallest model that runs your business", which is usually a much cheaper starting point that still grows.
Custom vs off-the-shelf, on cost
Off-the-shelf looks cheaper because its build cost is spread across thousands of customers. The fair comparison isn't the sticker price, though — it's the total cost of running your firm on each option: per-seat licence fees over time, the hours lost to the workarounds and shadow spreadsheets a generic tool forces on you, and the ceiling it puts on how you can grow. For firms whose structure is a genuine competitive advantage, that total often favours a custom build sooner than expected. We work through this trade-off in custom software vs off-the-shelf.
So, a realistic way to think about it
Rather than a number, budget around three things: a scoping phase that produces a clear model and a fixed picture of the build; a build priced against that clarity; and an ongoing line for hosting, support and change. Get the first one right and the other two become predictable — which is the whole point.
If you'd like a grounded estimate for your firm, the fastest path is a short conversation about how you actually work — that's the input every real number depends on.