How to Measure ROI on a Custom Software Project

To measure ROI on custom software, record a baseline before you build, then compare the yearly benefit (hours saved, revenue gained, costs avoided) against the full cost of building and running it. ROI is net benefit divided by total cost. Payback period, meaning build cost divided by net yearly benefit, is often the easier number for owners to act on.

The maths is simple. The discipline is in measuring honestly, before and after, so the result is a fact rather than a sales pitch. If you are earlier in the journey, our full guide to commissioning custom software covers the decisions that come before the business case.

Step 1: Why must you measure a baseline before building?

Without a "before" number, any "after" number is a guess. Spend a week or two recording how the work happens today. You are looking for figures you can measure again after launch:

• Time per task: how long it takes to create a quote, process an order, prepare a weekly report, or onboard a client.
• Volume: how many of those tasks happen each week or month.
• Error rate: wrong invoices, duplicate records, missed follow-ups, double bookings.
• Speed to respond: how long a new enquiry waits before someone contacts it.
• Tool spend: subscriptions, per-seat licences and add-ons the new system could replace.

Ask the people doing the work to log it, rather than estimating from a manager's memory. Estimates almost always undercount the small interruptions: copying data between tabs, chasing a colleague for a file, re-checking a spreadsheet formula.

Step 2: Which benefits should you count?

Group benefits into four buckets and be strict about what goes in each.

1. Time saved. Hours no longer spent on manual work, valued at the loaded cost of the people doing it (salary plus overheads).
2. Revenue gained. More enquiries converted because responses are faster, higher order values from better quoting, or capacity to serve more customers without hiring.
3. Costs avoided. Subscriptions cancelled, errors no longer refunded, a hire you no longer need to make this year.
4. Risk reduced. Fewer data mistakes, better security, less dependence on one person's spreadsheet. Real, but hard to price, so list it separately rather than inflating the headline number.

Only count time saved if it turns into something. If the team now finishes early but nothing else changes, the saving exists on paper only. If those hours absorb growth without a new hire, or move to sales follow-up, the value is genuine.

Revenue is where enthusiasm runs ahead of evidence. When enquiries arrive in volume (the featured Meta ad accounts we manage produced 6,600 between them), copying each one by hand into a spreadsheet stops being a minor chore and starts delaying replies. That is why our own Ops Console pulls website-form and Meta lead-ad enquiries into one lead centre automatically. But the revenue effect of faster replies should be measured after launch, not assumed in the business case.

Step 3: What costs belong in the calculation?

Count everything, not just the development invoice.

• Build cost, including discovery, design, development, testing and data migration.
• Maintenance and support: typically 15–25% of the build cost per year, as an estimate that varies with scope.
• Hosting and third-party services: servers, email and SMS delivery, AI usage, monitoring.
• Internal time: your team's hours in workshops, testing and training.
• Transition dip: productivity often falls for a few weeks while people learn the new system.

For typical build ranges, a simple internal tool or automation commonly runs US$6k–20k and a custom CRM US$20k–90k, depending on scope. Our explainer on when building custom software actually pays off versus buying helps you compare these against off-the-shelf subscriptions.

Step 4: How do you calculate ROI and payback? A worked example

Here is an illustrative example with round, hypothetical numbers, not client data. A five-person operations team at a services company replaces a patchwork of spreadsheets and a per-seat tool with a custom job-management system.

From those figures:

• Payback period = $30,000 / $22,800 = about 1.3 years, or roughly 16 months.
• Three-year ROI = (three years of benefit, $90,000, minus total three-year cost of $30,000 build + $21,600 running, i.e. $51,600) / $51,600 = about 74%.

Now stress-test it. Halve the hours saved and the payback stretches to about 2.8 years. If the project only works under the optimistic assumptions, it is a weak project. A strong one still pays back within a reasonable horizon when you cut the benefits by a third.

Step 5: How do you track ROI after launch?

Re-measure the same baseline metrics at fixed checkpoints, with the same method.

• At 30 days: adoption. Are people actually using the system, or running the old spreadsheet in parallel?
• At 90 days: time per task and error rates should have settled. Compare against the baseline.
• At 6 and 12 months: cost savings and revenue effects become visible. Check subscriptions were genuinely cancelled.

Build measurement into the software itself where you can: timestamps on when an enquiry arrived and when it was first contacted, counts of records processed, logs of report generation. Then ROI tracking becomes a dashboard instead of a project. Our explainer on how internal dashboards save teams hours every week shows the kind of numbers worth surfacing.

What mistakes make ROI estimates unreliable?

Watch for these when you, or a supplier, build the business case:

• Counting time saved twice, for example in both "hours saved" and "hire avoided."
• Ignoring running costs, which recur every year while the build cost does not.
• Using a manager's estimate instead of measured task times.
• Assuming 100% adoption from day one.
• Treating every feature as equal. Often a few features deliver most of the value; the rest are cost.
• Never re-measuring, so nobody learns whether the next project should go ahead.

If your project involves AI, the same logic applies with a few extra cost lines such as usage fees; see our guide on calculating ROI on AI automation before you invest.

Frequently asked questions

What is a good ROI for custom software?

There is no universal benchmark, because risk and strategy vary. A practical test is payback: many owners look for the build cost to be recovered within one to three years under conservative assumptions. Strategic systems that enable a new revenue line may justify a longer horizon.

How do I value time saved if my team is salaried?

Use the loaded hourly cost, meaning salary plus overheads such as benefits, equipment and office space, divided by working hours. Then ask what the freed time will actually be used for, because that determines whether the saving is real.

Should I include soft benefits like better morale?

List them, but keep them out of the headline calculation. Morale, fewer errors and lower key-person risk are genuine reasons to build, and can tip a close decision. Mixing them into the hard numbers makes the case harder to trust.

What if the ROI looks negative?

Look for a smaller first version that targets only the highest-value workflow, or consider an off-the-shelf tool instead. A negative ROI is useful information: it may save you from an expensive project that should not happen yet.

Can an agency guarantee ROI?

No honest one will. An agency can help you build a realistic business case, design the software to capture the metrics, and deliver to a fixed price, but adoption and business outcomes depend on how the system is used.

Build the business case before the software

A clear baseline and an honest ROI model make every later decision easier, from scope to priorities. We're glad to help shape one alongside a fixed-price quote: arrange a discovery call, or explore our custom software services first.