eturn on investment is not a forecast of how impressive the interface will look. It is a comparison between the economic change a product can reasonably create and the full cost of creating and operating it. The most useful model is deliberately simple, exposes its assumptions and includes the possibility that the right answer is not to build yet.
- Revenue volume, conversion rate, average order value and gross margin.
- Staff time spent on the workflow, using loaded employment cost rather than salary alone.
- Error, rework, support, refund and delay costs.
- Customer drop-off or churn associated with the current experience.
- Current software subscriptions and manual-service costs the new product could replace.
- The frequency and consequence of compliance, security or operational failures.
Revenue uplift comes from more qualified demand, conversion, retention or a new paid service. Efficiency comes from reducing time per task or increasing capacity without equivalent headcount. Avoided loss covers errors, downtime, fraud, failed handoffs or compliance risk. Strategic value includes information, control or a platform for future products, but it should be labelled separately when it cannot yet be measured.
Include discovery, design, development, migration, training and launch, then add hosting, third-party services, store fees, support, monitoring, maintenance and future platform work. Include the client's time for content, decisions, testing and change management. An estimate that ignores operating cost makes custom software look better on paper than it will in the business.
A practical annual model is: incremental gross profit plus labour saved plus avoidable losses, minus annual operating cost. Payback period is the initial investment divided by that annual net benefit. Use gross profit rather than revenue, and reduce theoretical time savings if the business cannot actually redeploy the capacity. The arithmetic is easy; the discipline is in defending the inputs.
- Conservative: modest adoption, slower rollout and only well-supported benefits.
- Expected: the team's best evidence-based case.
- Upside: stronger adoption, clearly labelled rather than blended into the headline.
- Break-even: the minimum conversion, volume or time saving required to recover the investment.
Name the baseline, event, owner and review date for each claimed benefit before development begins. If the case depends on enquiry conversion, track qualified enquiries rather than visits. If it depends on labour savings, measure task time and exception handling. A product that cannot demonstrate its intended outcome should not automatically receive another round of features.
Agoodbusinesscasemakesitsafetosayyes—andequallysafetosaynotyet.
Build conservative, expected and strong-adoption cases. The result is sensitive to how many people actually change behaviour, how often they use the application and whether time saved becomes productive capacity. Record each assumption and name the person who can validate it.
text
annual benefit = adopted users × uses per year × minutes saved ÷ 60 × loaded hourly cost + avoidable errors + retained or additional contribution net annual value = annual benefit − hosting − support − licences − operations payback months = initial investment ÷ net monthly value
- Count only the share of time or revenue the product can plausibly influence.
- Include onboarding, data migration, process change and internal administration.
- Model failure and low adoption before approving the optimistic case.
- Define the measurement events and baseline before development starts.
- Set a stop, reshape or expand decision for the first evidence window.