Custom software ROI: formula and worked example

What to include

The best ROI models combine direct savings with operational impact. Licence reduction is easy to calculate, but time saved and fewer mistakes often create the bigger return.

• One-time build cost.
• Hosting and maintenance.
• SaaS licences replaced.
• Hours saved per role.
• Error reduction or faster delivery.

The formula and a worked example

Use this formula: ROI = (total benefit minus total cost) divided by total cost, multiplied by 100%. Suppose a company invests EUR 30,000 and spends EUR 6,000 on maintenance over two years. It replaces EUR 12,000 in licences and saves 20 hours a week at EUR 35 per hour. The two-year benefit is EUR 84,800, the net benefit is EUR 48,800, and ROI is about 136%.

Build three scenarios before you decide

Do not present one precise outcome as a promise. Create conservative, expected, and optimistic scenarios, then verify the assumptions after launch. Keep revenue gains separate from hard savings and include adoption time, migration, training, and ongoing ownership.

• Conservative: count only licence savings and half the expected time gain.
• Expected: use measured process volumes and realistic adoption.
• Optimistic: include capacity growth or extra revenue, but label it clearly.
• Recalculate after 30, 90, and 180 days using actual usage data.

Decision framework for SME software

Do not make software decisions from tool preference alone. Compare process value, data risk, maintenance, and ownership. For growing companies, the best choice is often not the cheapest licence, but the system that permanently reduces manual work and dependency.

Lower-risk implementation route

A strong software decision starts small. Do not replace the whole landscape at once; choose a workflow with visible upside and manageable migration risk.

• Inventory costs, users, and duplicated entry.
• Choose one workflow with a clear owner.
• Build the smallest version people use daily.
• Migrate data with validation and a parallel period.
• Measure time saved, errors reduced, and adoption.

Start with the cost of today's process

Software ROI is often overstated: every possible saving is counted, while implementation, adoption and exceptions disappear. A credible case starts with a baseline. How many transactions are processed, how long does each step take, where do errors arise and what does delay or lost revenue cost? Only then should the team estimate what proportion a new system can realistically improve.

• Separate cash savings, released capacity and expected revenue growth.
• Include migration, training, internal time, management and parallel running.
• Use conservative, expected and ambitious cases for uncertain benefits.
• State which assumptions a pilot must prove before further investment.

A realistic worked example

A back office handles 2,000 documents a month at eight minutes each. Automated extraction with human review could reduce this to three minutes. At a fully loaded hourly cost of EUR 42, theoretical capacity is worth EUR 7,000 per month. Assuming only 65 percent is realised in year one gives EUR 4,550. Against EUR 55,000 implementation and EUR 1,200 monthly running cost, payback is roughly sixteen months. The business case must also explain how the released capacity will be used.

Turn the business case into a measurement plan

Link each expected benefit to a data source, owner and review date. This prevents the project being judged on impressions once it launches.

• Record volume, time, error rate and waiting time before the change.
• Define how each benefit translates into money, capacity or risk reduction.
• Compare a pilot group with the existing way of working.
• Review usage and results after 30, 90 and 180 days.
• Stop, improve or scale using thresholds agreed in advance.

Look beyond payback

Payback is useful, but says little about quality, risk or strategic flexibility. Use a compact scorecard with both financial and operational measures.

• Net savings and cumulative cash flow.
• Lead time, error rate and customer satisfaction.
• Active use and successful process completion.
• Supplier dependency and speed of future changes.

Avoid false precision

Not every benefit can be converted accurately into cash before implementation. Better compliance, lower operational risk or faster product launches may still be decisive. Record these separately rather than inventing a precise figure. An honest range with explicit assumptions is more useful than a dramatic ROI percentage nobody can verify later.

Separate cash savings from released capacity

Saving an hour of administration does not automatically remove an hour of payroll cost. Most software first creates capacity: the same team can serve more customers, fix fewer mistakes or deliver sooner. That capacity has value, but only if the business decides how to use it. Define the destination of saved time before development begins and connect it to revenue, service levels or avoided hiring. This keeps the business case credible instead of presenting theoretical hours as cash in the bank.

• Cash saving: a cost genuinely leaves a budget, contract or headcount plan.
• Capacity gain: the team handles more volume without proportional recruitment.
• Quality gain: fewer defects, complaints, write-offs or missed opportunities.

Model scenarios instead of one optimistic number

A useful ROI model contains at least a cautious, expected and upside case. Vary adoption, delivery time and the share of theoretical efficiency that becomes productive capacity. Include licences, migration, training, support, security and future changes. Also price the cost of doing nothing: rising subscriptions, manual handling and slow decisions are investment choices too. A transparent range gives leaders better information than a precise-looking forecast built on fragile assumptions.

• Use actual operational volumes, salaries and error rates where available.
• Calculate payback as well as the three-year value of the investment.
• Have finance and the process owner challenge assumptions before approval.

Manage realised value after launch

The business case should not disappear once funding is approved. Capture a baseline before launch and name an owner for benefit realisation. At thirty, ninety and one hundred eighty days, compare actual adoption, throughput, cycle time and defects with the forecast. If use is low, improve the process and onboarding first. If value remains structurally weak, narrow or stop the product. That discipline builds confidence in the next software decision and prevents sunk-cost thinking.

• Connect every expected benefit to one indicator and a reliable data source.
• Show which teams and user groups have adopted the new workflow.
• At each review, decide whether to scale, adjust, consolidate or stop.