A business case for custom software needs four numbers: what the current situation costs you today, what the software is expected to change, what it will cost to build and run over three years, and what the honest off-the-shelf alternative would cost instead. A case without the cost of doing nothing is an argument, not a business case.
Most rejected proposals fail on the third and fourth of those, not the first. This guide covers how to assemble each one so the decision survives scrutiny from someone who did not write it.
Key takeaways
- Price the status quo first: If leaving the problem alone is free, there is no case — and if it is not free, that number is your strongest argument.
- Use three years, not the build cost: Ongoing cost typically runs 15–25% of the build per year and is the line most often omitted.
- Compare against off-the-shelf honestly: If the real reason for building is preference rather than a costed constraint, the standard tool is usually the better commercial decision.
- State what would make this wrong: A case that names its own weakest assumption is far more likely to be approved than one that appears certain.
Start with the cost of doing nothing
Quantify the current situation in the units your finance team already uses. Hours spent per case multiplied by loaded cost. Error rate multiplied by the cost of an error. Revenue lost to a process that takes four days when competitors take one. Staff turnover in a role where the tooling is the stated reason people leave.
You do not need precision here; you need a defensible order of magnitude and a stated method. Timing twenty real cases end to end over two weeks produces a more credible baseline than a confident estimate, and costs almost nothing.
This number is what the rest of the case is measured against. Without it, every benefit you claim is unfalsifiable, and reviewers treat unfalsifiable benefits as zero.
Build the four-part comparison
Current cost is the baseline above, stated as an annual figure.
Expected value is what changes, expressed in the same units. Be conservative and explicit: "cycle time falls from four days to one, which removes about 900 hours of chasing per year" is reviewable. "Improved efficiency" is not.
Delivery risk is the probability that the build costs more or delivers less than planned, and what you will do about it. Naming this makes the case stronger, not weaker — every experienced reviewer knows the risk exists, and a case that ignores it looks naive rather than confident.
Ownership is who runs the result after launch: the internal time to operate it, the budget to change it, and the person accountable for the outcome. Cases that skip this produce software that works and then decays.
Count the whole three-year cost
The build price is the smallest part of what you are approving. A complete figure includes:
- Build, including the admin interface and each integration
- Hosting, third-party services and licences
- Maintenance, security updates and platform changes
- Support, whether internal or contracted
- The internal time to operate and administer it
- The cost of change in years two and three, which is always non-zero
Ongoing cost commonly lands between 15% and 25% of the build per year. A €80,000 build is realistically a €140,000 to €160,000 three-year commitment. Presenting the build figure alone is the most common reason a business case is approved and then quietly regretted.
Compare against off-the-shelf without flattering yourself
Name the specific standard products that could serve this need, and the specific thing each one cannot do. Then price that gap annually.
If the gap is a genuine constraint — pricing rules no product supports, an approval hierarchy that does not exist in any standard tool, a regulatory requirement — you have a real case for building. If the honest answer is that the standard tool is workable but disliked, the commercial decision is to buy it and spend the difference elsewhere.
Include the configuration and integration cost of the off-the-shelf option too. Comparing a full custom build against a licence fee, with no implementation cost attached, is the most common way this comparison is rigged without anyone intending to rig it.
For how this decision fits into a wider programme, see the digital transformation roadmap.
State the measure and the review point
Every case should name the measure that will show whether it worked, the date it will be checked, and who checks it. Operational measures such as cycle time and error rate should move within a quarter of go-live. If they have not moved after two quarters, the problem is adoption or scope, and more delivery will not fix it.
Committing to this in advance changes the quality of the decision. It also protects you: a project measured against a number agreed beforehand is judged on evidence rather than on whoever tells the story best afterwards.
Write down what would make this the wrong decision
Finish the case with the two or three assumptions it depends on most, and what you would expect to see if they were wrong. Volume that does not materialize. A process that changes before the build completes. An integration that turns out to be unsupported.
This section is what separates a business case from a pitch. Reviewers approve proposals from people who have thought about how they might be wrong, because those are the people who will notice early enough to do something about it.
Related guides
Related reading:
- What an Automation Discovery Phase Should Deliver
- How to Choose a Digital Transformation Partner
- Digital Transformation Roadmap: A 7-Step Business Guide
If the work prompted by How to Build a Business Case for Custom Software leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Digital Roadmap.
Ali Boran Gazel