The platform vendor's deck says low-code halves development cost. Finance wants to know what it will save here, on these tools, with this team. Nobody has a baseline to compare against.
That gap is where low-code decisions tend to stall, or get made on someone else's numbers. This piece covers the measures that settle the question, how to read the published benchmarks, and how to get your own figures before you commit.
The three numbers that decide it
Low-code ROI comes down to three measures, each taken before and after the build:
Time to market. Hours or weeks from an agreed request to a tool in daily use. Use the median, because one stuck project distorts an average.
Build cost. Engineering hours and what they cost, plus the platform license and any partner fees.
Maintenance cost. Hours each month spent on fixes, changes, and keeping integrations working after launch.
Where the tool replaces manual work, two more belong beside them: the time one case takes, and how many cases run each month. Multiply the two, before and after, and the saving becomes a figure finance recognizes.
Cost alone understates the return. A tool that ships in weeks starts paying back a quarter earlier. One that shortens review time moves every launch that depends on it. Count those too, or the comparison favors whatever was cheapest to build.
What the published benchmarks say
You will be shown industry figures. These are the ones that circulate most, with the sources they cite:
Gartner forecast that by 2025, 70% of new applications built by organizations would use low-code or no-code technology, up from under 25% in 2020.
A Forrester Total Economic Impact study reported a 53% cut in development cost at a European financial services company.
OutSystems reports maintenance effort falling by up to 90%.
A Mendix benchmark study reported a 68% cut in IT infrastructure cost at a multinational manufacturer.
Read them for what they are. Total Economic Impact studies are commissioned by the platform vendor, and the platform makers publish their own benchmarks. "Up to" describes the best case. Each figure is a reason to measure your own, and none of them is a forecast for your team.
Two before-and-after records
At Saxo Bank, creative operations ran across disconnected tools, with brand checks done by hand outside the workflow. Launchpad brought requests, approvals, and assets into one Retool platform used across four markets. Saxo's own analysis found median time to market fell 78.3%, with project duration going from 310 hours to 67. Review readiness fell 86.1%, from 8.1 days to 1.1.
At an e-commerce partner to luxury brands, support agents opened up to six tools to answer one ticket. A support console in Retool now shows the order and shipping data in one view, and AI drafts replies for agents to approve. Average handle time went from 3 to 4 minutes to 30 seconds. AI handles 80% of incoming tickets, and more than 20,000 have run through the console.
Both results can be stated as a before and after for one reason: the before was recorded first.
Three ways to make the call
Commit on the benchmarks. The quickest decision. The risk comes later, when nobody can show whether the platform paid back, because nothing was measured at the start.
Run a measured first build. Pick one workflow with a known cost, record the numbers today, build it, and measure again once the tool is in daily use. The return figure arrives after the build, which takes some patience from finance.
Stay with traditional development. The right call when the software is the product itself, or when the logic is unusual enough that it needs to be written from scratch. Many teams run both: low-code for operational and workflow tools, developers on the core system logic. Low-code or traditional development covers where that line sits.
Where teams get the measurement wrong
The most common mistake is counting only the cost saving. A full picture includes faster releases, fewer handoffs between teams, and being able to see where work is waiting.
The second is measuring after the build only. Without a baseline, an improvement is an opinion. The old figures can often be rebuilt from tickets, timesheets, or the request queue. Recording them first is still easier.
The third is ignoring maintenance. A tool that was cheap to build and needs an engineer every week is expensive by the end of the first year. The tool was free to build. Maintaining it is not. covers that cost in detail.
Our view
We recommend a measured first build, because it gives finance a number from your own operation rather than someone else's average. Choose a workflow where the manual cost is countable: orders re-keyed between systems, tickets handled by hand, approvals waiting in an inbox.
Record the baseline with the people who do the work, before anyone opens the editor. The product owner picks the workflow and signs off the measures. The result then decides the size of the next commitment. For what the build itself is likely to cost, see what it costs to build a production-ready internal tool.
Benchmarks start the conversation. Your baseline ends it.
