Custom business software: how do you calculate its return?
Software can remove duplicate entry without reducing business expenditure. To decide, separate time recovered, actual savings and the tool’s cost over time. A worked example shows which assumptions change the result.
06 chapters
Measure a task and its rework before estimating a benefit
Measure a recurring task
Choose recurring work: preparing a case, copying an order, finding a document or producing a report. Over a representative period, record its frequency and the time spent by the people concerned. Add corrections and interruptions related to the task.
Include difficult cases
Avoid measuring only an easy case. An average may hide an exceptional case that takes an hour. Record what the tool could actually remove and what will remain human: decisions, client conversations or checks.
Connect the calculation to real work
The guide to signs you need a business application helps identify friction. The return calculation then rests on a specific use, not a general promise of productivity.
- Task frequency over a representative period.
- Processing and correction time.
- The portion the tool can actually remove.
- What the team will do with the time recovered.
Add the project cost and its ongoing operation
Count the initial investment
The initial cost includes scoping, development, tests, data migration and training. Add internal time spent explaining rules, checking cases and supporting the first users. This time exists even if it does not appear on the provider’s invoice.
Add operation and future changes
Recurring costs may include hosting, subscriptions, maintenance, support and external services. Significant changes are a separate cost. Choose a comparison period and state what is included so you can compare the software with another solution over the same duration.
Define the scope before pricing
The market price guide gives scope benchmarks and the estimator starts the scoping process. They do not replace a record of your business’s own costs or a quote for the necessary integrations.
Separate the start from ongoing costs
France Num recommends distinguishing initial expenditure from recurring costs when scoping a digital project.
- Start
Build and prepare
Identify the delivery budget and responsibilities.
- Ongoing
Maintain and develop
Plan hosting, maintenance and necessary changes.
This budget distinction supports the calculation below; the source does not supply the amounts used in this example.
Distinguish available time from a cash saving
Separate recovered time from cash flow
If someone saves two hours, their salary does not automatically decrease. The business recovers working capacity. That capacity may reduce a backlog, improve responses or allow more work to be handled. Describe how it will be used before assigning a value.
Count expenditure actually avoided
An expenditure saving is different: a cancelled subscription, a service no longer needed or a correction cost actually avoided. Do not count the same consequence twice. An hour of rework avoided does not become both recovered time and a separate saving without justification.
Use a cautious assumption
Retain a cautious portion of the theoretical benefit to account for adoption and remaining tasks. Test this assumption with future users. A tool can be technically ready and still little used; process preparation reduces that risk without eliminating it.
A worked example with every assumption stated
The simulation’s assumptions
An educational example, unrelated to any client result. Assume a total initial investment of €14,400 and operating costs of €180 per month. Observation suggests 30 recoverable hours per month, valued at €35 an hour. We retain only 60% of that potential: 30 × 35 × 0.60 = €630 of working capacity per month.
The break-even point
After recurring costs, the retained monthly benefit is 630 − 180 = €450. With these constant assumptions, break-even is reached after 14,400 ÷ 450 = 32 months. This is a simulation result, not a promise of payback.
The three-year balance
Over three years, the cost is 14,400 + 36 × 180 = €20,880. The valued benefit reaches 36 × 630 = €22,680, leaving a balance of €1,800.
This calculation assumes use from the start, with no ramp-up or financing costs: add those items if they apply to you. Compare amounts on an accounting basis consistent with the business.
- Initial investment in the example: €14,400.
- Valued and retained monthly benefit: €630.
- Monthly operating cost: €180.
- Simulated monthly balance: €450; break-even: 32 months.
Test the scenario that could change the decision
Example: retaining 40% of the benefit
In the same example, if the retained benefit falls to 40% of the potential, it is worth €420 per month. After €180 of operating costs, €240 remains. Break-even becomes 14,400 ÷ 240 = 60 months. A single assumption therefore changes the decision substantially.
Test costs and the start-up period
Also test a slower start, higher maintenance costs and an additional integration. If the retained recurring benefit does not cover the recurring cost, the project has no positive break-even point in this model. There may be other reasons to proceed, but name them separately.
Describe benefits you cannot quantify
Some benefits are hard to price: continuity during an absence, better access allocation or lower error risk. Describe the situations and how necessary the improvement is. Assigning an arbitrary amount to make the table positive does not make the project sounder.
Decide on a first scope and measure it after use
Compare the alternatives
Compare custom development with adapting the existing tool and improving the process without new software. The Excel, Notion or business application guide helps examine this gap. Custom software is justified when the specific need remains poorly covered.
Measure one complete first version
- Define a first version that completes a whole task.
- Plan how to measure time, errors and adoption after a few representative cycles.
- A limited pilot can avoid committing to every integration before checking the central use.
Compare assumptions with results
Keep the calculation’s assumptions and compare them with observations. If the benefit is lower, find out whether the problem is the tool, its use or the initial measurement. Business software development should remain tied to these decisions rather than a feature list to deliver at any cost.
The remaining decisions
Is saved time a financial saving?
It first represents recovered working capacity. It becomes reduced expenditure or extra revenue only if a real mechanism makes that possible. The calculation should make this assumption visible.
What payback period is acceptable?
That depends on the expected useful life, cash flow and other investments. Compare several scenarios with the business; there is no universal threshold.
Should maintenance be included in the calculation?
Yes, along with subscriptions, hosting, internal costs and changes already foreseeable. Comparing a build price with a multi-year subscription without aligning scopes distorts the decision.
Does a pilot prove the return on the entire project?
It checks one use and some assumptions. The costs and benefits of other features or integrations still need examining before adding them.
Put the guide against a real project.
A few lines are enough: context, the main constraint, and the expected result.
