Custom software is usually approved on a feeling: the current process is painful and something must be done. That works until someone in finance asks what the company gets back for the money, and the room goes quiet.
The calculation is not complicated. It is just rarely done properly, because most teams estimate the costs carefully and the benefits vaguely.
Start With the Cost of Doing Nothing
The honest baseline is not zero. Staying on the current process has a price, and it is usually paid in hours nobody counts.
Measure it before the project starts:
- Hours per week spent on manual data entry, re-keying, and copy-paste between systems.
- Time lost finding information that lives in three places.
- Errors that require rework, refunds, or apologies.
- Licence fees for tools that only partly fit.
- Revenue lost to slow turnaround or a process customers dislike.
Convert those into money at a loaded hourly rate. That figure is what the new system competes against, and it is often larger than the budget being debated.
Count the Full Investment, Not Just the Build
The second half of the equation is the total investment, which is more than the development quote. A realistic number includes:
- Design and development work.
- Integration with the systems you already run.
- Data migration and cleanup.
- Training and the productivity dip while people adapt.
- Hosting, licences, and ongoing maintenance.
Maintenance is the line most often forgotten. A working assumption of 15–20% of the build cost per year keeps the ROI calculation honest rather than flattering.
Spread these over the period you are measuring rather than treating them as a single up-front figure. Development is mostly a first-year cost; hosting and support continue for as long as the system runs, and they are what turn a promising investment into a disappointing one when ignored.
Put the Benefits Into Three Buckets
Once both sides are on the table, sort the returns into categories your finance team will accept.
Hard savings. Hours removed from a process, licences retired, error rates reduced. These are defensible because they map to a specific number that existed before.
Revenue effects. Faster quotes, higher conversion, more orders handled with the same team. Attribute these carefully — claim only what the change plausibly caused.
Strategic value. Owning your data, removing vendor lock-in, being able to launch a product a competitor cannot copy quickly. Real, but keep it out of the arithmetic and present it separately.
A bespoke development agency that refuses to separate these three is selling, not estimating. The teams worth working with will tell you which benefits they can stand behind and which are optimistic.
A Simple Formula That Survives Scrutiny
The core calculation stays simple:
ROI = (annual benefit − annual cost) ÷ total investment
Run it over three years, because year one carries the build cost and understates the result. Then run it twice more, once with pessimistic numbers and once with optimistic ones. A project that still works at the pessimistic end is a safe decision.
Ask whoever presents the numbers how they were derived, and prefer a smaller figure with a clear source over a large one with none. This is exactly the discussion a custom business software company KrastySoft prefers to have before a contract, since the measurements agreed up front are what prove the value later.
The Metrics to Fix Before You Build
The biggest mistake is measuring nothing until after launch, which makes any claim unprovable. Before development starts, record the two or three numbers the project is supposed to move: processing time per order, tickets handled per person per day, days to close a month.
Capture them for a few weeks. That baseline costs almost nothing and turns the post-launch conversation from opinion into evidence.
Watch the Payback Period, Not Just the Percentage
A percentage hides timing. Two projects can show the same three-year ROI while one repays itself in eight months and the other in thirty.
For most internal systems the payback period is the number executives actually care about, because it determines how long the company carries the expenses before the savings appear. Anything under eighteen months is usually an easy approval; beyond three years, the assumptions deserve another look.
When the Numbers Say No
Sometimes they do, and that is a useful result. If the process is rare, the volume is low, or a standard tool covers 90% of the need, custom development will not pay for itself, and an honest bespoke development agency will say so before quoting.
The value of running the calculation is that it prevents both mistakes: building something the business does not need, and living for years with a profit-draining process because nobody ever priced it.
