Everyone does the sums before signing off: quotes lined up side by side, budgets justified, expectations on paper. But once the custom software is up and running, the sums often stop. The system works, people get used to it, and nobody checks any more whether the investment is delivering what was expected at the start.
That’s a missed opportunity, because the success of custom software is genuinely measurable. The condition: you define upfront what success looks like, and you measure how things stood before. Start only after go-live and you have nothing to compare against.
Without a baseline, there is nothing to prove
Every meaningful measurement starts before go-live. How many minutes does processing an order take now? How often does work need redoing because a mistake crept in somewhere? How many requests does one employee handle per week? These are figures from your own organisation, and you only have them if someone records them before the new system changes everything.
In the same phase, set out which improvement justifies the investment. That forces clarity about the goal before a single line of code exists. For the other questions worth asking at this stage, read our article on what to ask before commissioning custom software.
Four signals that build the full picture
Success rarely comes down to a single figure. Four signals together give a reliable picture.
- Usage: do the people the system was built for work with it every day, or do spreadsheets keep reappearing alongside the official route?
- Time per process: how many minutes does the same task take now, compared with your baseline?
- Errors: how often does work need redoing, and how many corrections reach the customer?
- Output: how many more orders, requests or customers does the same team process?
Usage is the gatekeeper here. Software that people avoid delivers nothing, however well it’s built technically. As long as adoption lags, the other three signals say little.
Translate the gains into euros, including what often gets missed
Saved hours only become convincing once you multiply them by what an hour of work costs. Add the rework that’s no longer needed, and whatever extra the team processes with the time freed up. Set that against the full costs: not just development, but also training, maintenance and the productivity dip in the first weeks after the switch.
Two items are often forgotten. Custom software lasts for years, so spread the one-off development cost over its expected lifespan rather than loading it all onto the first year. And some gains don’t fit in a spreadsheet: faster responses to customers, less frustration in day-to-day work, better visibility of your figures. Name them alongside the hard numbers, rather than leaving them out because they’re hard to put a figure on.
A universal payback period doesn’t exist. It depends on how much manual work the software replaces and how many people use it every day. Be wary of a supplier who puts a fixed number on it without knowing your processes.
Give the measurement the time adoption needs
In the first weeks after go-live, what you’re mostly measuring is people finding their way: old routines rub up against new ones. Evaluate too early and you’re judging the learning curve rather than the software. Measure at several points instead, for example shortly after launch, after a few months and after a year, each time against the same baseline.
Combine the figures with the experiences of the people who use the system every day. They see what a dashboard doesn’t show: the workaround the system forces, or the bottleneck that quietly disappeared.
So measurement starts well before any software exists, with clear criteria and an honest baseline. Want to know what there is to gain in your own processes? We’d rather have that conversation with your figures on the table. Read how we develop custom applications, or see what it delivered for other organisations in our cases.