Almost every business case for custom software is unfalsifiable. It projects efficiency gains, better decisions and improved customer experience, none of which anybody will measure afterwards, and all of which will be reported as delivered regardless of what happened.
That is not dishonesty. It is that nobody wrote down what they would check, and by the time the system is live the people who approved it have moved on to the next thing. A return you cannot verify is a return you cannot learn from, which is why organisations repeat the same estimate on the next project.
Measure the baseline before you build anything
The single reason most software returns cannot be calculated is that nobody recorded the starting position.
Before the project begins, find the process the software is meant to improve and time it. How long does the task take now, how many times a month does it happen, how often does it go wrong, and how long does fixing it take. Four numbers, gathered over a fortnight, by asking the people who actually do the work.
This is the cheapest and most skipped step in the entire process. It costs a couple of days and without it every subsequent claim about improvement is an assertion.
We now refuse to write a business case without it, having watched too many projects finish with everybody convinced things were better and nobody able to say by how much.
The four numbers worth tracking
Most ROI models contain a dozen benefit lines, of which two are real. Narrow it deliberately.
Time on a named task. Not productivity in general, but a specific job that a specific person does a known number of times. Two hours a week saved for four people is a number you can defend, and it is worth roughly the loaded cost of those hours.
Error and rework rate. How often does the current process produce something that has to be corrected, and what does the correction cost. This is frequently larger than the time saving and almost always omitted, because nobody tracks rework as its own category.
Revenue the system makes possible. Orders that could not previously be taken, customers that could not be served, a service that could not be offered. Only count this where the constraint was genuinely the software, which is rarer than business cases suggest.
Cost avoided. Licences you stop paying, a contractor you no longer need, a manual step you were about to hire for. This is the most reliable line because it appears in an invoice that stops arriving.
What not to put in the model
Being disciplined about exclusions is what makes the remaining numbers credible.
Improved decision making. Nobody can measure it, it will be claimed regardless, and including it signals that the rest of the model has not been examined either.
Employee satisfaction, unless you are running a survey with a before and after. It is a genuine benefit and it is not a financial one, so it belongs in the narrative rather than the arithmetic.
Scalability and future flexibility. Real, and worth building for, and not a number. Putting a value on it invites the reader to ask where the figure came from, and there is no good answer.
Keep those in the case as stated qualitative benefits. Just keep them out of the total, because a total containing one unverifiable line is an unverifiable total.
The second year is where the arithmetic actually settles
Build cost is estimated carefully and running cost is estimated by nobody, which is how projects that looked positive over three years turn out not to be.
After launch you are paying for hosting, third-party services, security updates, platform deadlines that arrive annually whether or not you have plans, and the developer time to handle all of it. A workable rule is fifteen to twenty percent of the original build cost every year, and higher if the system integrates with anything you do not control.
Add the cost of the knowledge. Somebody has to understand this system, and if that person leaves, the next one spends weeks reaching the same position. That is a real recurring cost and it belongs in the model, which is the argument we made in the comparison between custom and off-the-shelf.
The projects we see go wrong financially are rarely the ones that overran on build. They are the ones where nobody budgeted the second year, so maintenance came out of a budget that had other plans.
Compare against the honest alternative
A business case comparing custom software against doing nothing will always win, and it is the wrong comparison.
Compare it against the realistic alternative, which is usually a subscription product that does eighty percent of the job, configured properly, with the remaining twenty percent handled by a process change. That option has a known price, a shorter timeline and somebody else maintaining it.
Sometimes it loses badly, and then your case is strong. Sometimes it is closer than expected, and knowing that before committing is worth considerably more than a favourable number.
The subscription option changes shape over time too, which is worth modelling rather than assuming, and we went through that in why subscription pricing keeps winning.
Write down what would prove you wrong
The discipline that separates a business case from a pitch is stating in advance what result would mean the decision was a mistake.
If the task still takes ninety minutes six months after launch, the efficiency case failed. If the error rate is unchanged, the quality case failed. If nobody outside the original team uses it by the second quarter, the adoption case failed.
Write those three sentences into the approval document with a date attached. It costs nothing, it makes the case more credible rather than less, and it gives you an actual review rather than an assumption.
Organisations that do this get better at estimating within about two projects. Organisations that do not repeat the same optimistic model indefinitely, because nothing ever contradicts it.
When the honest answer is no
A model worth trusting has to be able to produce a negative, and there are recognisable cases where it should.
When the process you want to automate is about to change anyway. When the number of people affected is small enough that the saving cannot cover maintenance. When nobody internally will own the result. When the real problem is that a process is unclear, in which case software will encode the confusion rather than resolve it.
That last one is the most common and the most expensive. Building a system around a process nobody has agreed on produces an expensive record of the disagreement.
Our custom software development team asks for the baseline numbers before quoting, and occasionally the answer is that the case does not hold. That conversation is cheaper before the build than during the second year.
Frequently Asked Questions
What is a realistic payback period?
Eighteen months to three years for most internal systems, including maintenance. Anything promising under a year is usually excluding running costs or counting benefits nobody will measure.
How do we measure the baseline?
Time the current task, count how often it happens, count how often it goes wrong, and time the correction. Gather it over a fortnight by asking the people doing the work rather than estimating from a process document.
Should soft benefits go in the model?
In the narrative, not the total. Improved decisions and staff satisfaction are real and unmeasurable, and one unverifiable line makes the whole total unverifiable.
What should we budget for maintenance?
Fifteen to twenty percent of the build cost annually, higher if the system integrates with anything you do not control. Add the cost of somebody understanding it, because that recurs whenever people change.
What should we compare custom software against?
The realistic alternative, which is usually a subscription product doing most of the job plus a process change. Comparing against doing nothing produces a case that always wins and tells you nothing.
How do we know afterwards whether it worked?
By writing down in advance what result would mean it failed, with a date. Re-measure the same four baseline numbers at that date. Without a stated failure condition, every project is reported as a success.
When is custom software clearly not worth it?
When the process is about to change, when too few people are affected for the saving to cover maintenance, when nobody will own it internally, or when the underlying process has not been agreed. The last is the most expensive.
Does this apply to smaller projects?
Proportionally. A small build does not need a formal model, and it still needs a baseline and a stated failure condition. Those two take an afternoon at any project size.
Talk to our team if you are approving a software business case and nobody has measured what the current process costs.