Key takeaways
- Estimate ROI as (benefit − cost) ÷ cost over a set period, and also work out the payback period.
- Count the whole cost, including support, hosting and your own team's time, not only the build quote.
- A saved hour is only worth money if it is used for other work, and the period you choose changes the result.
- Measure the baseline before launch and again at three and six months to check the estimate.
How do you work out the return on custom software? Add up everything it will cost over a set period, estimate the money it will save or earn over the same period, and compare the two. If the benefit is bigger than the cost within a time you can accept, the case is strong. The numbers are estimates, so write down your assumptions and check them after launch.
What does ROI mean for custom software?
ROI stands for return on investment. It compares what you get with what you spend:
ROI = (benefit − cost) ÷ cost
A result of 20% means that for every £1 you spend, you get £1.20 back over the period you measured. A second measure is the payback period: how long the benefits take to cover the cost. Use both, because a high ROI over ten years can still be a poor choice if you need the money back in two.
What counts as a cost?
The build is only part of it. Count:
- Discovery, design, development and testing. This is the quote most people think of first. See what drives the price of custom software.
- Hosting, licences and third-party services the software depends on.
- Support and maintenance. Software needs looking after after launch. What application support covers explains what to budget for.
- Your own team's time. Writing requirements, testing, and training all take hours that could have gone elsewhere.
- Moving data from the old system, and running both for a while.
What counts as a benefit?
Only count what you can turn into money, or into a risk you can describe.
- Time saved. Hours per week × the cost of an hour of that person's time.
- Errors avoided. How often a mistake happens × what each one costs to fix.
- Costs removed. Licences you stop paying for, or work you no longer outsource.
- Revenue gained. Orders you can now take, or quotes you can now send faster. Be cautious here, as it is the hardest to prove.
- Risk reduced. Software that no longer depends on one person, or one spreadsheet. This is real, but hard to put a number on, so list it separately.
A saved hour is only worth money if it is used for something else. If a team saves ten hours but nobody picks up other work, the benefit is smaller than the arithmetic says.
A simple worked example
These figures are made up to show the method. They are not a quote or a benchmark.
A team spends 30 hours a week re-typing orders between two systems. An hour of their time costs the business £20.
| Amount | |
|---|---|
| Time saved per year (30 hours × £20 × 52 weeks) | £31,200 |
| Build cost (one-off) | £60,000 |
| Running cost per year (hosting, support) | £6,000 |
| Net saving per year (£31,200 − £6,000) | £25,200 |
| Payback period (£60,000 ÷ £25,200) | about 2.4 years |
Now compare two periods:
- Over 3 years: benefit £93,600, cost £78,000 (£60,000 + 3 × £6,000). ROI = (93,600 − 78,000) ÷ 78,000 = 20%.
- Over 5 years: benefit £156,000, cost £90,000 (£60,000 + 5 × £6,000). ROI = (156,000 − 90,000) ÷ 90,000 = about 73%.
The same project looks modest or strong depending on the period, which is why you should choose it before you do the sums.
Which period should you use?
Pick one that matches how long you expect the process to stay the same. Three to five years is a common choice. If the way you work changes every year, a long horizon flatters the result, because the software may need rebuilding before it has paid back.
What can make the estimate wrong?
- Assuming everyone will use it. If only half the team uses the new system, you get half the benefit.
- Scope growth. Extra features raise the cost, but rarely the benefit you originally counted.
- Counting the same saving twice. Time saved and cost removed can be the same money seen two ways.
- Ignoring the cost of doing nothing. Compare against the real alternative: the extra hours, errors and licences you will pay for if you leave things as they are.
- Treating the estimate as a promise. It is a decision aid. A range (best, expected and worst case) is more honest than one number.
How do you check the return after launch?
- Measure before you start. Record the hours, error rate or turnaround time you are trying to improve.
- Measure again at three and six months, using the same method.
- Track adoption. Are people using it, and for the right tasks?
- Update the sums with real figures and see how far they were from the estimate.
Doing this also tells you what to improve next, and it gives you facts for any conversation about changes or support.
When is the case weak?
The return is hardest to justify when the process changes often, when few people would use the software, or when an off-the-shelf product already does most of the job. Is custom software worth it? goes through when bespoke beats off-the-shelf, and legacy system modernisation covers whether to repair, replace or leave an old system alone.
What should you ask a supplier?
- What assumptions would you challenge in my estimate?
- What are the likely running costs after launch, and who pays them?
- What can we build first to prove the benefit before committing to everything?
- How will we measure whether it worked?
A good supplier will help you test the numbers and will say when the case is weak. A technical discovery is a way to firm up both cost and benefit before you commit.
If you want a second opinion on the sums, see our planning and technical advice or our custom software development service, or contact us.