What custom software costs, and the five things that actually move the number
Operational software is rarely expensive because of how much of it there is. It is expensive because of what it has to connect to, who is allowed to see what, and how much of the old data has to come along. What each driver does to effort, and how to get an estimate that survives contact with the build.
Key takeaways
If you read nothing else.
- 01
Screen count is the weakest predictor of cost in operational software. Integrations, permissions and data migration are the strong ones.
- 02
Every system you connect to adds its own testing, its own credentials and its own owner who has other priorities.
- 03
Permissions are the driver most often left out of a brief and most often found in the last two weeks of a build.
- 04
Old data is usually the single largest piece of unplanned work, because it was never as clean as anyone remembers.
- 05
The way to control cost is to reduce what the first release must connect to, not to reduce the number of screens on it.
The idea in one picture
The five drivers, in the order they move effort.
- 01
What it connects to
Each external system adds credentials, a test environment, error handling and an owner with other priorities. Four integrations is not four times one, because the failures start interacting.
- 02
Who is allowed to do what
Roles and permissions multiply test cases rather than adding to them. It is the driver most often missing from a brief and most often discovered in the last two weeks.
- 03
How much history comes across
Old data is never as clean as anyone remembers. Reconciling it, deciding what to drop and proving the totals match is regularly the largest piece of unplanned work.
- 04
Who has to approve it
A regulator, an auditor or a customer security review changes how the system is built, not just how it is documented. Audit trails and data residency are design decisions, not features.
- 05
How many kinds of user
One system serving staff, partners and customers is three products sharing a database. Each group needs its own journey, its own permissions and its own support path.
Ask what custom software costs and you will get a range so wide it is useless, which is a fair response to an unfair question. The number depends almost entirely on things that are not in the brief when the question is asked.
What is answerable, and more useful, is which factors move it. In operational software, meaning the systems a business runs on rather than a consumer product, the drivers are consistent enough to plan around. Screen count is not one of them.
Why screens are the wrong unit
A brief that says “about fifteen screens” is describing the visible surface of the system, which is the cheapest part to build. Two applications with fifteen screens each can differ by an order of magnitude in effort, and the difference is never in the screens.
It is in what sits behind them: how many other systems have to agree, how many kinds of user need a different view of the same record, how much of the last decade has to be carried forward, and who has to sign off that it is safe.
The five drivers
1. What it has to connect to
The strongest single predictor. Each integration brings its own authentication, its own test environment, its own error cases and its own owner who is busy with something else.
The cost is not linear. Four integrations are considerably more than four times one, because once several systems participate in a transaction the failures start interacting: one is slow while another times out, and now you need a retry strategy, a reconciliation report and somewhere for a human to intervene.
The thing that makes this driver manageable is that it is almost always sequenceable, which is where most of the saving in a first release comes from.
2. Who is allowed to see and do what
Permissions are the driver most often absent from a brief and most often discovered late.
“Managers approve their own team’s requests, except in finance, where a second approver is needed above a threshold, and regional leads can see everything in their region but not the salary field” is one sentence and a large amount of work. Roles multiply test cases rather than adding to them, and every rule has to hold in the API as well as in the interface, because the interface is not a security boundary.
Write the permission rules down before anyone estimates. If they take more than a page, say so out loud.
3. How much history comes across
Old data is the most reliably underestimated piece of work in this category, for a simple reason: nobody has looked at it closely in years.
The pattern repeats. A field that was optional for the first three years. Two records for the same customer because a system changed in 2019. Free-text entries where a code was expected. None of this is anybody’s fault and all of it has to be decided: cleaned, mapped, or deliberately left behind with a note saying why.
Pulling a sample and reading it is a day of work, and it is the day that makes every subsequent estimate real.
4. Who has to approve it
A regulator, an auditor or an enterprise customer’s security review changes how the system is built, not just how it is written up. Audit trails have to be designed in, because retrofitting them means touching every write. Data residency decides where things run. Access reviews decide how accounts are provisioned.
None of this is expensive when it is known at the start. All of it is expensive when it arrives during a security questionnaire three weeks before launch.
5. How many kinds of user
A system used by your own staff is one product. The same system opened to partners is two: different journeys, different permissions, different support expectations, different tolerance for a confusing screen. Add customers and it is three.
This is worth being honest about early, because a brief often describes the staff experience in detail and mentions the partner portal in a single line, when the partner portal is half the work.
How to get an estimate you can plan against
Four steps, in order:
- Write the permission rules down. One page. If it runs longer, that is information.
- List the integrations with an owner’s name against each. Not the system name. The person.
- Look at a sample of the old data. A day, not a meeting.
- Decide what the first release must connect to, and let the rest arrive later.
Then ask for a range rather than a number, and ask what assumptions it rests on. Anyone giving you a firm price for an unscoped operational system is pricing a guess and protecting themselves with contingency, which you pay for either way.
Discovery and architecture takes about a week for most builds of this kind. The estimate that follows is worth several times the one before it, and the output, meaning the flows, the data model, the integration list and a written scope with exclusions, is yours whether or not the same team continues.
The cheapest lever you have
It is not cutting features. Features are what the business asked for, and removing them is how a project loses the support it needs to finish.
It is cutting what the first release must connect to. A system that talks to one external platform on day one, with three more in a later phase, costs a fraction of the same system with everything wired at launch, and it reaches real users months earlier. Nothing has been taken away from anyone. The order has changed.
If you want a structured way to size this against your own operation rather than against a general article, the readiness assessment is twenty questions about how the work runs today and produces a phased plan with the effort ranges attached. It costs nothing and there is no call attached to it.
FAQ
Questions readers ask.
Why do quotes for the same software differ so much?
Because they are rarely quoting the same thing. One assumes you supply integration credentials and test environments, another has priced discovering them. One includes data migration, another treats it as a separate project. One has priced a permissions model, another has assumed everybody sees everything. Normalize the assumptions in writing and most of the difference disappears. What is left is seniority mix and how much contingency each has priced for the parts nobody has specified.
What makes custom software expensive?
Five things, in rough order. What it has to integrate with, because each connection carries its own testing and its own owner. Who is allowed to see and do what, which multiplies test cases. How much historical data must come across and how clean it is. Whether a regulator or a customer security review is involved. And how many distinct user groups need a different experience of the same system.
Is it cheaper to buy off-the-shelf software than to build?
Usually yes, for a process that looks like everybody else's. Buying gets expensive when your rules are genuinely different from the product's assumptions, because you then pay in configuration, workarounds and the manual work your team does around the gaps. That last cost never appears on the software line and is often the largest of the three. Count it before comparing.
How can I reduce the cost of a software build without cutting scope?
Reduce what the first release has to connect to. A system that talks to one external platform instead of four, with the rest arriving in a later phase, costs far less than the same system with everything on day one, and it reaches real users months earlier. You have not cut a feature. You have sequenced the integrations.
How accurate is an estimate before discovery?
Wide enough that it should be given as a range, and anyone offering a firm number for an unscoped operational system is pricing a guess and protecting themselves with contingency. Discovery and architecture runs about a week for most builds. The estimate that follows it is worth several times the one before it, and it is cheap by comparison.
Should I pay for discovery before committing to a build?
Yes, and keep it as a separate commitment with its own deliverable. A week of discovery produces the user flows, the data model, the integration list and a written scope with exclusions. All of that is yours whether or not you continue with the same team, which is the point: it turns the build decision into one made on evidence rather than on a proposal.
Where this applies
Put it to work.
Talk to an expert
Working through this yourself?
Tell us where you are and what is in the way. Someone who would work on it will reply, usually within one working day.
Or take the 8 minute readiness assessment