How to measure the ROI of custom software
How to measure custom software ROI: quantify time saved, errors avoided, and revenue gained, then build a defensible business case with payback period and NPV.
Most software business cases fail not because the software was a bad idea but because nobody defined what success would look like in numbers. The base rates are sobering. In a joint study with Oxford covering more than 5,400 IT projects, McKinsey found that large projects ran 45 percent over budget and 7 percent over schedule while delivering 56 percent less value than predicted. ROI on custom software is measurable if you set it up correctly before the build, track the right baselines, and stay honest about what the software actually caused. This is a practical guide to doing that, not a spreadsheet template that flatters the decision you already made.
Framing ROI beyond cost savings
The first mistake is treating custom software as a cost-cutting exercise only. Labor savings are real and easy to count, but they are usually the smallest part of the return.
Think in three buckets. First, efficiency: time your team stops spending on manual work. Second, quality: errors and rework you avoid. Third, growth: revenue you can capture, retain, or newly open because the software does something off-the-shelf tools could not. A tool that cuts a two-hour daily process to ten minutes has an obvious return. A tool that lets you win a category of customers you previously had to turn away has a bigger one that is harder to see. The market reflects how many companies are making this bet: Grand View Research valued the custom software development market at $43.16 billion in 2024 and projects it reaching $146.18 billion by 2030, a 22.6 percent compound annual growth rate. Enterprises are not buying bespoke code for fun. They buy it when the packaged option leaves value on the table.
If you are still deciding whether custom is the right path at all, when to build custom software covers the qualifying questions before you get to ROI.
Quantifying time saved and errors avoided
Start with the workflow the software replaces or improves, and measure it as it is today.
- Count the people doing the task, how often, and how long it takes.
- Multiply by a loaded hourly rate to get the current cost of that process.
- Estimate the post-launch time realistically. Software rarely takes a task to zero.
Errors are the part teams skip because they are harder to see. Track how often mistakes happen now, what each one costs to fix, and what it costs downstream. A pricing error caught by a customer is far more expensive than the minutes spent making it. The waste is not hypothetical: PMI's Pulse of the Profession found organizations lose 11.4 cents of every dollar spent on projects to poor performance, and a large share of that traces back to rework and unclear requirements. A validation rule that prevents a bad record from ever entering the system has value you can put a number on, even if it takes some digging.
Revenue and retention impacts
Growth effects are where custom software often justifies itself, and where measurement gets slippery.
Be conservative and specific. If a faster onboarding flow lets sales close deals sooner, estimate the shortened cycle and the deal volume it applies to. If a feature reduces churn, tie it to a measurable retention change, not a hope. If the software opens a new revenue line, model it as its own case with its own assumptions.
The discipline is to attribute carefully. Software is rarely the only thing that changed, so avoid claiming credit for gains that had other causes. A defensible smaller number beats an impressive one nobody believes.
There is also a category of benefit that resists a dollar figure but is real: things the business simply could not do before. A system that lets you serve a customer segment you had to decline, or that removes a bottleneck capping your growth, has strategic value beyond the hours it saves. Do not force these into the spreadsheet with invented numbers, but do name them in the case, because sometimes the qualitative gain is the whole reason to build.
Building a defensible business case
A business case that survives scrutiny has a few traits: baselines measured before the project, assumptions stated in the open, and both costs and benefits laid out over time.
Do not forget the full cost side. The build is only part of it. Include hosting, maintenance, support, and the internal time your team spends on the project. Our breakdown of the hidden costs of custom software exists so these do not ambush your ROI later. A case that shows total cost of ownership honestly is far more persuasive to a CFO than one that quietly leaves out the ongoing bills.
The delivery method belongs in the case too, because it changes the risk-adjusted return. The same McKinsey research found that every additional year a project runs increases its cost overrun by about 15 percent, and that 17 percent of large IT projects blow past 200 percent of budget, severe enough to threaten the company running them. Method matters here: the 2020 Standish CHAOS data shows agile projects succeeding at roughly 42 percent versus 13 percent for waterfall. A business case that assumes a long, single-delivery build is quietly assuming the worst odds.
| Metric | Figure | Source |
|---|---|---|
| Large IT project average cost overrun | 45% over budget | McKinsey / Oxford (5,400+ projects) |
| Value shortfall vs. prediction | 56% less than planned | McKinsey / Oxford |
| Waste per project dollar | 11.4 cents | PMI Pulse of the Profession |
| Agile vs. waterfall success rate | 42% vs. 13% | Standish CHAOS 2020 |
Payback period and NPV basics
Two simple measures cover most decisions.
- Payback period: how long until cumulative benefits equal the total cost. Short paybacks are easier to approve and carry less risk.
- Net present value (NPV): the value of future benefits and costs discounted back to today, because a dollar next year is worth less than a dollar now.
For most internal tools, a clear payback period is enough to get a yes. For larger platforms with benefits spread over years, NPV gives a fairer picture because it accounts for timing. You do not need a finance degree. You need a consistent method and honest inputs.
The size of the project should shape how much rigor you apply. The same McKinsey and Oxford data set found that software projects carry the highest risk of cost and schedule overruns of any project type, and that the total cost overrun across the projects studied came to about $66 billion, more than the annual GDP of a small country. A five-figure internal tool does not need a discounted cash flow model. A seven-figure platform absolutely does, because the range of outcomes is wide enough that timing and risk change the answer.
One factor buyers forget is timing of value, not just amount. A phased build that delivers a working, useful slice in the first couple of months starts returning value while the rest is still being built. A big-bang project that delivers nothing until month twelve carries all its cost before any benefit arrives, which pushes out payback and raises risk. Given that every added year of duration compounds the overrun, this is a practical argument for shipping in increments: earlier value improves the ROI math directly, before you account for the reduced risk of finding out sooner whether the thing works.
Tracking ROI after launch
The business case is a prediction. The point of measuring is to check it against reality.
Instrument the software so you can see the metrics your case depended on: process times, error rates, conversion, retention, whatever you claimed would move. Compare against the pre-launch baseline you captured. Some assumptions will prove optimistic and some conservative, and knowing which teaches you how to estimate the next project better. This is exactly the discipline the 56 percent value shortfall punishes companies for skipping: they never measure whether the predicted benefits arrived.
This is also how you decide where to invest next. The features that drove the return earn more investment; the ones that did not can be trimmed. That feedback loop is where custom software compounds in value. If you want help building a case grounded in your real numbers, you can start a project or read more on the blog about when building pays off.