Somewhere in your company there is probably a workflow built on a no-code platform. Someone sensible built it, it solved a real problem, and it still runs. When the subscription comes up for renewal, the question on the table is whether the platform still does the job, and the answer is almost always yes.
That is the wrong question. The licence is the smallest cost of a visual platform. The larger costs build up quietly in other places, and the largest one, leaving, never appears in the business case at all.
what nine months on a visual platform taught me
I learned this on a side project: a multi-step publishing workflow, built in evenings and on weekends, with a website and six social channels at the end of it. The first version ran on Make.com, with a spreadsheet as the database underneath. Both were defensible choices for a testing project, and the combination worked.
Getting it to work reliably took about nine months. Most of that time went to edge cases: each platform had its own limits and its own formatting rules, one step in the flow would fail silently and leave the spreadsheet half written, and connection errors needed automatic retries built from more steps, which then needed their own error handling. Those were evenings and weekends, so nine months of calendar time covers far fewer hours of actual work than it sounds like. The grind was real either way.
Then I rewrote the whole thing as ordinary code, with an AI coding assistant helping. It took about six weeks of the same side-project hours. The new version is faster, cheaper to run and easier to change, and when something breaks, the error points to the problem.
where the cost actually builds up
Nobody compares platforms on the thing that costs the most. The comparison people run is time to the first working version, and on that measure the visual platform wins almost every time. It should win. That is what it was designed for.
The money goes somewhere else. First, to fixing things when they break, which does not get cheaper over time. In code, a failure tells you the exact line that broke and what changed since it last worked. In a visual flow you get a stopped run and a long diagram to search, and what you learned from the last failure does not help with the next one, because each connection to an outside service fails in its own way.
The second place the money goes is the limit of what the platform can handle. That limit does not announce itself in the first week. It arrives as a slope that gets steeper once the straightforward part of your system is built. A simple “if this, then that” choice grows into a sprawling diagram. Something the system needs to remember ends up as a spreadsheet row that two flows try to update at the same moment. By the time the slope is obvious, months of your business rules live in a format nobody on your team can read or review.
The last of the three, and the largest, is migration: the cost of getting off the platform. It gets left out of the business case entirely, because at evaluation time it is years away and belongs to someone else’s budget.
There is a halfway move that feels clever, and I tried it. Before migrating fully, I kept the old flows running and called them from the new code. Technically it works. It also keeps the platform in the middle of the system, keeps the subscription running for a tool you no longer want, and gives each of those connections a reason never to be revisited: nothing is broken, and the backlog always has something louder on it. Bridges like that tend to become permanent. If your team takes that route, put a removal date on each connection and treat it as a real deadline.
the same shape at company scale
ServiceNow and ThoughtLab’s 2026 maturity index, a survey of 4,500 executives, found the share of organizations reporting streamlined, integrated workflows across business functions fell from 30% in 2025 to 16% in 2026. That is a fourteen-point drop on a measure that was supposed to be climbing. The authors attribute the drop to companies still carrying fragmented platforms, now with a layer of AI agents spread on top of them.
What happened to my side project happens to companies, with more platforms involved. No individual platform failed there either. Each one was bought for a sensible reason, solved the problem it was bought for, and stayed. What changed is that there are now many of them, each holding a slice of a process, each with its own connections and logins, and the work of keeping them joined up costs more each year, because there is more of it.
why leaving costs less than you think
Two things made that six-week rewrite of my side project possible, and only one of them is AI.
The first is that I knew precisely what to build. Nine months on the visual platform had produced a complete specification in my head: every edge case, every limit, every formatting rule. That knowledge could not be shortcut, and AI did not generate it. Had I started in code on day one, I would still have had to learn all of those things. The nine months were the price of learning them.
The second is that, with the specification already settled, writing the code took little time, and an AI assistant did much of it. Those two things together are what change the arithmetic of leaving. A rewrite used to mean a budget line and a steering committee, because the building was most of the work. For a system the size of my side project, it was six weeks of evenings. Your workflows are larger than mine, but the same two conditions apply: the people who run them every day already carry the specification, and the code now gets written faster than it used to. If your estimate of what leaving a platform costs was formed before AI coding assistants arrived, it is probably far too high, and too high in the direction that keeps you on the platform.
when the visual platform is still the right call
None of this means you should never use one. My first version was a sensible choice for something that might not survive its first month. A visual platform is a good fit for a prototype you may throw away, a small flow that will stay small and stable, or a team with nobody who can maintain code. The trouble starts when something built for one of those reasons grows, step by step, into a system the business depends on, and nobody asks about the exit while it is still cheap to answer.
the one-day test before you renew
So before you renew your no-code platform, ask a different question. The platform will handle what you need today; the demo already showed you that. What you need to know is what leaving looks like once it stops handling what you need, and whether you can afford it on the day you find out.
Here is how to check. Take the two or three most complicated flows in the system: the ones with retries, partial failures and data shared between systems, not the tidy one from the demo. Ask your IT team or an external developer to rebuild them as code against your real systems, and give it one day. Then compare the two: how much of it they rebuilt, how easy it is to test, and how easy it is for someone else to read. It costs one day, and it tells you what leaving would cost before you have nine months invested.