How to calculate ROI before investing in custom software
The short answer
Estimate the yearly benefit — time freed that will genuinely be reused, errors avoided, revenue gained — and compare it with the total cost: build, running costs and the time your own team spends on the project. Divide the cost by the monthly benefit to get a payback period. Be conservative on benefits, generous on costs, and treat anything that only frees up time as capacity rather than savings unless that time will be redeployed. If the payback only works with optimistic assumptions, start with a smaller first version and measure.
The basic sum
Return on investment for software is not complicated. It comes down to two numbers:
- What it costs over a sensible period, usually two or three years.
- What it’s worth to the business over the same period.
The most useful single figure is the payback period: how many months of benefit it takes to cover the cost. It’s easier to reason about than a percentage, and it forces honesty about when the benefit actually starts.
Step 1: count the benefits honestly
| Benefit | How to estimate it | Be careful of |
|---|---|---|
| Time saved | Hours per week × people × hourly employment cost | Freed time only saves money if it’s reused |
| Errors avoided | How often mistakes happen × what each one costs | Guessing the cost of rare errors |
| Revenue gained | Extra sales, faster quotes, fewer lost leads | Assuming the software causes the growth |
| Costs removed | Subscriptions, outsourcing or contractors no longer needed | Contracts with notice periods |
Capacity is not cash. If automation frees ten hours a week, that is valuable — but it only appears in the accounts if those hours go to work that earns or saves money, or if you avoid a hire you would otherwise have made. Count it, but label it separately.
The automation savings calculator does the time-and-cost part of this for a single task.
Step 2: count all the costs
- The build. The quote, plus a contingency for scope that grows.
- Running costs. Hosting, third-party services, any AI usage, support and updates.
- Your team’s time. Meetings, testing, giving feedback, and learning the new system.
- Switching costs. Migrating data, running old and new side by side for a while.
People usually remember the first and forget the third. Your own team’s time is real.
Step 3: work out the payback
A worked example with hypothetical numbers:
- Three people spend six hours a week re-typing orders. At £25 an hour over 46 weeks, that’s about £20,700 a year.
- Automation could remove two-thirds of it: about £13,800 a year of capacity, or roughly £1,150 a month.
- Errors from re-typing cost about £200 a month in corrections and refunds.
- Total benefit: about £1,350 a month.
- Build plus first-year running costs plus internal time: £12,000.
- Payback: about 9 months.
Then stress-test it. Halve the benefits and add 30% to the costs. If the payback is still acceptable, the project is robust. If it only works on the optimistic numbers, that’s a signal to start smaller.
Benefits that are hard to price but real
Some of the best returns don’t fit neatly in a spreadsheet: faster responses to customers, better decisions from accurate data, staff who stop doing work they hate, or a new service you couldn’t offer before. Note them; don’t inflate them into numbers you can’t defend.
For example, the supplier negotiation tool we built for SinaTools is valuable because it gives the team evidence when a supplier proposes a price rise. Its return depends on the negotiations it supports, which can only be measured after the fact.
Reduce the risk instead of perfecting the forecast
No forecast survives contact with real use. A better approach is to build the smallest version that delivers part of the benefit, measure it, and decide on the next step with real numbers. That also caps how much you can lose if the assumptions were wrong.