Calculating the Return on Investment of Bespoke Software

ROI is a decision model, not a sales number

The familiar formula is simple: subtract total investment from total benefit, divide by investment and multiply by 100. The difficult work is deciding what belongs in those numbers. A spreadsheet can produce 187% ROI while hiding weak adoption, omitted support costs and benefits that never become cash.

A useful business case compares credible alternatives over the same period: build bespoke software, buy and adapt a product, improve the current process or defer change. “Do nothing” is not free; it carries labour, errors, delay, licences, operational risk and opportunity cost. But those costs must be evidenced rather than exaggerated to make development look attractive.

Use ranges and scenarios. The purpose is to discover which assumptions control the decision and what must be measured, not to predict three years of organisational behaviour to the nearest pound.

Begin with a measurable operational baseline

Measure the current workflow before automating it. Record transaction volume, active handling time, waiting time, rework, error frequency, support effort and the cost of systems involved. Separate average cases from expensive exceptions; a process may look efficient until month-end or one missing field triggers hours of repair.

Do not rely only on workshop estimates. Sample completed work, system timestamps, invoices and support records. Staff often report elapsed time when only active time is recoverable, or omit unofficial checking they no longer notice.

A baseline also prevents post-launch storytelling. If nobody measured approval time or error rates before release, the team cannot distinguish real improvement from enthusiasm about a newer interface.

Time saved is valuable only when it changes capacity or cost

Suppose 20 employees each save 30 minutes a day. Multiplying those hours by fully loaded salary estimates gross capacity released; it does not prove cash will appear. The value depends on what the organisation does with that capacity.

Benefits are strongest when time avoids planned recruitment, reduces paid overtime, supports additional transactions or releases specialists from administration into higher-value work. If the saved minutes are fragmented across a day and cannot be redeployed, count only a fraction.

Use a realisation factor: perhaps 40%, 70% and 90% across conservative, expected and optimistic cases. That is more honest than treating every theoretical minute as a payroll saving. Automation frequently creates review and exception work too; subtract it.

Error reduction has several different values

An error can cause direct financial loss, staff rework, customer delay, regulatory exposure or reputational harm. Count these separately to avoid both omission and double counting. If rework hours already include correcting invoices, do not add the same labour again as “quality savings”.

Expected loss is probability multiplied by impact, but rare severe events deserve scenario treatment rather than false precision. A control that reduces a one-in-ten-year incident cannot be validated from one quarter of post-launch data.

Software can also move errors rather than remove them. Mandatory fields reduce missing information but may encourage invented values. Automation can make one incorrect rule affect every transaction. Include monitoring, override and correction costs in the design.

Faster revenue is not the same as more revenue

Shorter onboarding or quotation cycles can bring cash forward, improve conversion or increase throughput. These are distinct benefits. Receiving the same payment ten days earlier improves working capital; it does not add the entire payment to revenue.

Incremental revenue should be multiplied by contribution margin, not treated as pure benefit. If software enables £100,000 of additional sales that cost £70,000 to fulfil, the relevant contribution is closer to £30,000 before other effects.

Test causal assumptions. Faster quotes may not increase win rate if price or demand is the constraint. Use pilots, cohorts or historical analysis where possible, and state attribution uncertainty where other business changes happen simultaneously.

Avoided licences require a complete exit model

Replacing several subscriptions can create a clear benefit, but only after contracts, migration overlap, archive access and replacement capabilities are considered. Organisations often pay for old and new systems in parallel longer than planned.

Include licences that genuinely disappear, not products that remain for another department. Account for usage-based fees, integration tools, identity services and reporting products that the bespoke system will still require.

Avoided licence inflation is also different from licence elimination. Model expected vendor increases explicitly rather than assuming today's price forever or claiming every future increase as a bespoke-software saving.

Risk reduction belongs in the model-but not as invented certainty

Legacy security exposure, unsupported technology, key-person dependency and poor auditability have economic consequences. Some can be modelled as expected loss; others are constraints that the organisation is unwilling to accept regardless of average return.

Do not claim that new software eliminates risk. It exchanges risks: obsolete dependencies may disappear while delivery, migration and adoption risk increase. A credible case identifies controls and residual exposure on both sides.

Compliance can be a threshold rather than a benefit. If the organisation must meet an obligation to continue operating, the question may be the least-cost acceptable route, not whether compliance produces a positive standalone ROI.

Count the whole investment, including change

Development cost is only the visible beginning. Include discovery, internal subject-matter time, data cleansing, integration work, security review, accessibility, hosting, monitoring, support, training, parallel running and contingency. Include the opportunity cost of staff assigned to the project where it materially displaces other work.

Recurring maintenance is not an embarrassing exception. Useful software needs patches, dependency upgrades, operational attention and incremental change. Model an annual range based on system criticality and change rate, not an unsupported universal percentage.

Terminal or exit costs matter too: data export, decommissioning, archive retention and transition to another supplier. Bespoke software should create ownership and options, not make future replacement impossible.

Adoption is a multiplier on nearly every benefit

If only 60% of eligible work follows the new process, most variable benefits should be multiplied accordingly. Licence savings may be impossible until adoption is high enough to retire the old system. Support costs may rise temporarily during transition.

Adoption is not simply accounts created. Measure eligible transactions completed, repeat usage, exception routing and continued use of shadow spreadsheets. A mandated system can show 100% login adoption while employees still perform the real work elsewhere.

Build the ramp into cash flow. Benefits rarely begin at full strength on launch day. Training, migration and process refinement mean realisation may grow over months; assuming immediate steady state artificially shortens payback.

Cash flow, payback and NPV answer different questions

ROI summarises return relative to cost but ignores timing. Payback period shows when cumulative cash benefits recover the investment, which matters to liquidity and risk. Net present value discounts future cash flows, recognising that money and uncertainty have time value.

A project can have attractive three-year ROI but an unacceptable payback period. Another may have modest direct savings yet be necessary to unlock a strategic service. Present several measures instead of forcing every decision into one percentage.

Use monthly or quarterly cash flows when timing is material. Apply a discount rate agreed with finance, not one chosen to favour the project. Keep strategic or non-financial benefits visible but separate from cash calculations.

Use scenarios and sensitivity, not one forecast

Create conservative, expected and optimistic cases with different adoption, delivery cost, benefit realisation and launch dates. Then vary one assumption at a time. If the case fails when adoption falls from 85% to 70%, adoption is a board-level dependency, not a training footnote.

Look for break-even values: how many transactions, avoided hires or months of use are required? This turns the business case into an operational target and may expose that a low-volume workflow cannot justify a large platform.

Do not hide uncertainty inside a large contingency. Name it. Data quality, supplier integration and policy decisions need different evidence and mitigations. Discovery should spend effort on assumptions with the greatest influence on value.

A worked structure for a defensible case

Give every major assumption an owner and a planned measurement source. A benefit without an owner is usually an aspiration. Review the case after release and change investment decisions when evidence differs; the original spreadsheet is not a promise that reality must honour.

The decision test

• Are alternatives compared over the same period and scope?
• Does the baseline use observed data?
• Are time savings adjusted for realisable capacity?
• Is additional revenue valued at contribution margin?
• Are implementation, operation and change costs included?
• Does adoption ramp over time?
• Are risk reduction and compliance treated honestly?
• Do scenarios expose the assumptions that control the decision?
• Are payback and cash timing acceptable?
• Will owners measure benefits after launch?

The best ROI model does not guarantee that bespoke software should be built. It makes the conditions for a good investment explicit-and gives the organisation enough evidence to stop, reshape or proceed for the right reasons.