How to Measure the ROI of a Custom Software Project

The business case promised to save several hours every week. Six months after launch, staff say the new application is helpful, yet nobody can explain whether the investment has paid off. The project had a budget and a delivery plan, but its expected benefits were never translated into measurable operating changes.

Measuring the return on a custom software project starts before development. You need a baseline, a clear connection between software capabilities and business outcomes, and an honest account of the costs required to achieve them. A spreadsheet filled in after launch cannot reliably reconstruct all three.

This article presents a practical operating model for evaluating a project. The arithmetic examples are illustrative assumptions, not forecasts or financial advice. Their purpose is to show how to make a business case inspectable and how to separate a promising estimate from a realised benefit.

Write down the decision the calculation will support

ROI can help compare projects, decide whether to continue a pilot, or assess a completed investment. These uses need different evidence. A proposal relies on assumptions and ranges; an operating review should increasingly rely on measured outcomes.

Choose the evaluation period and the alternative you are comparing against. The alternative might be continuing the current process, purchasing a commercial product, or making a smaller improvement. Comparing custom software with an imaginary zero-cost status quo will distort the result.

Specify the scope of the investment. A customer portal may require a data clean-up project, new support procedures, and integration changes elsewhere. If those activities are necessary to realise the benefit, they belong in the decision even when another department pays for them.

Also state who will use the result. An operations manager may need evidence of added capacity; the finance team may need an approved cash-flow view. A single headline percentage rarely answers both questions adequately.

Establish the baseline while the old process still exists

Observe the work before it changes. Capture transaction volume, handling time, waiting time, rework, exception frequency, and the people involved. Sample normal work and difficult cases rather than timing only the simplest transaction.

For a quotation process, separate preparation time from the days spent waiting for missing information. Faster document generation might reduce staff effort without significantly shortening the customer journey if approval remains the bottleneck.

Record the measurement method. If employees estimate time from memory, label the baseline accordingly. If timestamps come from an existing system, check what those timestamps mean. A ticket creation date and closure date measure elapsed time, not continuous staff effort.

Keep contextual information such as seasonality, staffing levels, and customer mix. If order volume doubles after launch, total support hours may rise even while effort per order falls. Without both measures, a useful improvement can look like a failure.

Describe a benefit as an observable change

“Improve efficiency” is an aspiration. “Reduce the manual copying needed to prepare an approved quotation” identifies a process that can be observed. Tie every major benefit to a specific activity, an owner, and an expected measurement.

A useful benefit record names the affected users, current performance, proposed change, expected adoption, measurement source, and review date. It should also name dependencies. If the benefit requires suppliers to provide structured data, the software team cannot guarantee it independently.

Distinguish leading indicators from outcomes. Staff using the new quotation screen is evidence of adoption. Reduced preparation effort and fewer correction requests are closer to the intended operating result. Login counts alone are not a substitute for either.

Limit the initial business case to benefits you can explain. A long list of loosely related advantages creates an impressive total but makes accountability difficult. It is better to have three measurable benefits than fifteen speculative ones.

Separate cash savings, capacity, and service quality

Time released by software does not automatically become a cash saving. If employees remain in their roles, the immediate benefit may be capacity for additional work, faster response, or reduced overtime. Describe the actual mechanism through which the business expects to gain value.

Cash savings require an expenditure to be reduced or avoided under a credible plan. Capacity benefits require work that will use the released time. Service improvements may be valuable even when their monetary effect is difficult to isolate.

For example, reducing quotation preparation from twenty minutes to twelve minutes releases eight minutes per eligible quotation. Whether that becomes a lower cost or more sales activity depends on staffing arrangements, demand, and how managers organise the work.

Keep these benefit types separate in reporting. You can present a cash case, an operating-capacity case, and qualitative improvements alongside one another. Combining them without explanation encourages double counting and makes later reviews contentious.

Use a transparent time-saving calculation

Suppose an illustrative team processes 600 eligible requests per month and saves eight minutes on each one. That is 4,800 minutes, or 80 hours, of gross monthly capacity. At an assumed loaded hourly cost of £30, its accounting value would be £2,400 per month.

Now account for adoption and additional review. If only three quarters of eligible requests use the new workflow, the gross capacity falls to 60 hours. If support and checking consume ten additional hours, the net release is 50 hours, with an illustrative value of £1,500.

These numbers do not prove a £1,500 cash saving. They describe a capacity estimate under stated assumptions. A cash claim needs evidence that an expense changed; a capacity claim needs evidence that the time was actually released and usefully redeployed.

Keep the formula visible: eligible volume multiplied by adoption multiplied by time saved, minus new operating effort. Measure the inputs again after launch. This is more useful than preserving an optimistic estimate because it appeared in the original approval document.

Count the full cost of ownership

Development invoices are only part of the cost. Include discovery, design, data preparation, migration, integration, testing, training, deployment, internal project time, and any necessary changes to existing systems. These costs can sit across several budgets.

Recurring costs may include hosting, licences, monitoring, support, incident response, maintenance, security updates, and operational administration. Usage-based services need a volume assumption. If the application introduces AI processing, model usage and human review are part of the operating model.

Plan for changes that are reasonably expected within the evaluation period. An integration maintained by another vendor may need updates; a growing business may require additional capacity or reporting. Avoid pretending that a custom application becomes cost-free once its initial features are delivered.

Make ownership explicit. Somebody should know which costs are fixed, which vary with usage, and which are uncertain. A modest initial estimate can be acceptable if its uncertainty is visible and the project has a way to learn before committing further funds.

Calculate a simple return without hiding timing

For a simple undiscounted view, ROI over a chosen period can be expressed as total attributable benefits minus total project costs, divided by total project costs. State which benefits and costs you included so another person can reproduce the calculation.

Consider an illustrative two-year case with £60,000 in initial costs and £12,000 in annual operating costs. Total costs are £84,000. If attributable benefits are £48,000 each year, the two-year benefit is £96,000 and the simple return is approximately 14.3 percent.

The same assumptions imply annual benefit after recurring operating cost of £36,000. With an immediate steady benefit and no ramp-up, simple payback on the initial £60,000 would take about twenty months. Real adoption usually changes over time, so a monthly cash-flow schedule is more informative.

For material investments, ask the finance owner which discounting, tax, depreciation, and appraisal conventions apply. Keep the operating assumptions available for that analysis. A simple blog formula should not override the organisation's investment methodology.

Avoid counting the same improvement twice

A faster order process may reduce staff effort and increase available sales capacity. Counting the full value of released labour and the full value of additional revenue can overstate the result when both rely on the same hours.

Trace the causal chain. If released time allows account managers to handle more enquiries, estimate the additional contribution after the relevant costs and explain how it relates to the capacity benefit. Choose a consistent treatment with the finance team.

Revenue is also different from profit contribution. Extra sales can require fulfilment, support, payment processing, inventory, and other variable expenditure. A project that increases revenue may still have a weak financial return if those costs absorb the gain.

Treat avoided errors carefully. Use observed error frequency and credible average remediation effort where possible. Do not multiply a dramatic worst-case incident by an arbitrary likelihood to create a large benefit number that nobody can validate.

Make attribution part of the rollout

If the new application launches alongside a pricing change, a marketing campaign, and extra staffing, improved results cannot automatically be assigned to software. Record other changes and choose a comparison approach suitable for the business.

A phased rollout may let you compare similar teams or transaction groups over the same period. A controlled experiment may be practical for some product features. For other processes, a carefully documented before-and-after comparison is the best available evidence, with its limitations stated.

Keep the comparison fair. The first team to adopt may be more experienced or handle easier cases. Compare relevant segments and inspect the exception workload. An average improvement can conceal a process that becomes harder for a smaller group.

Do not make causal claims stronger than the evidence. It is reasonable to say that handling time fell after implementation and that the software likely contributed. It is a different claim to say the application caused the entire commercial improvement.

Use scenarios to expose fragile assumptions

Build a conservative, expected, and optimistic case using a small number of important variables. Adoption, transaction volume, time saved, integration maintenance, and the pace of rollout often deserve attention. The purpose is to see which assumptions determine the decision.

Change related inputs consistently. A faster rollout may require more training expenditure. Higher transaction volume may increase hosting and support costs. An optimistic benefit case with a fixed minimal cost estimate is rarely a useful scenario.

Calculate the break-even conditions. How many eligible transactions must use the application? How much effort must it save? These questions give the pilot concrete learning objectives and make a proposal easier to challenge constructively.

Where uncertainty dominates, buy information before buying the full solution. A small workflow prototype or integration investigation can reveal whether the central assumption is plausible. The discovery expense belongs in the business case, but it may prevent a much larger mistaken commitment.

Give each benefit an accountable owner

Engineering can deliver a feature, but operations often controls whether the feature changes work. Assign a benefit owner who can influence adoption, process changes, training, and the use of released capacity. This should be a real responsibility rather than a name added to a slide.

Review benefits at agreed intervals using the same definitions as the baseline. Explain deviations rather than simply recolouring a status indicator. If adoption is low because a necessary exception path is missing, the next action is a product decision, not another reminder to staff.

Include the cost of measurement itself. A lightweight report drawn from existing workflow events is usually more sustainable than asking employees to maintain a second elaborate spreadsheet forever. Validate automated measures against a few observed cases before relying on them.

Keep a decision log. Record changes to scope, benefit assumptions, and measurement methods. This preserves the reasoning behind the investment and prevents later reviewers from comparing actual results with a target that the organisation quietly abandoned.

## Put the assumptions into a reviewable benefit register

A practical register can be a small table maintained with the project: benefit, baseline, target, measurement source, accountable owner, dependencies, and review date. Add a confidence note that distinguishes observed data from estimates. The purpose is to support a decision, not create a reporting exercise larger than the project.

For the quotation example, the owner might be the sales-operations manager, the baseline could come from observed preparation sessions, and the dependency could be adoption of a standard input form. The register makes it clear that a faster generation feature alone does not deliver the whole benefit.

Keep an assumption when it is uncertain rather than silently replacing it with a precise-looking number. If the team does not know how much review will be needed, the pilot should measure review effort. That uncertainty is useful information for deciding how much to invest next.

The GOV.UK service-benefits guidance also connects baseline measurement with decisions about continuing or changing a service. For a custom software team, the same discipline keeps evaluation connected to action instead of treating a benefit report as an end in itself.

Include an exit or replacement case

Consider what happens if the software no longer meets the business need. Data export, contract termination, migration support, and staff retraining can affect long-term ownership. These costs may be uncertain, but a credible business case should at least identify the dependency.

Ask whether the project creates a capability the organisation can maintain with another team. Documentation, supported interfaces, and usable deployment procedures can influence future cost even when they do not appear in the initial feature list.

Do not assume that the cheapest first delivery is the cheapest ownership path. Compare the likely operating and change costs under the same evaluation period, and show where one option leaves the business with less flexibility.

Decide what to do with disappointing results

A weak early return does not always mean the application should be discarded. Benefits may be delayed by onboarding, missing data, or an unresolved integration. Identify whether the problem is execution, adoption, or the original economic premise.

Set a bounded response. For example, investigate one bottleneck, make a defined improvement, and review the same outcome after a suitable operating period. Avoid an open-ended sequence of additional features justified only by the money already spent.

Some projects deserve continuation because they provide necessary capability, even when a simple ROI percentage is unremarkable. State that rationale directly and evaluate the capability with appropriate evidence. Do not invent monetary benefits to disguise a strategic or operational requirement.

Before your next custom software proposal, create a one-page benefit register and measure one representative workflow. A credible baseline, a full cost model, and an owner for each expected change will make the eventual decision more useful than any polished return percentage on its own.

---