Teams rarely regret building on low-code. They regret not noticing when it stopped fitting. The platform that let you launch in six weeks can, three years later, be the reason a small change takes a month. But "it feels slow" is not a reason to rebuild, and rebuilding everything at once is the most expensive way to find out you were wrong.
This article is about the decision itself: how to tell, with numbers, whether to keep the platform, and how to move in steps if the answer is to leave. If you already know you are leaving and need the task list, see the low-code exit checklist. If you want to understand the technical limits, when low-code breaks at the platform ceiling covers them.
Why feelings are not enough
Two people on the same team can look at the same platform and disagree. The developer sees every workaround. The business owner sees that the app still works. Both are right, and neither has a number. Without one, the discussion ends with the loudest voice or the latest incident.
Three signals are cheap to collect and hard to argue with. You can gather all of them in a day from invoices, your ticket list and your change history.
Signal 1: licence cost per active user
Take the yearly platform bill, including add-ons, premium connectors and extra environments, and divide it by the people who actually used the apps in the last 90 days. Do not divide by the number of seats you pay for.
What matters is the direction, not the level. A cost that grows faster than the number of real users usually means you are paying for features or tiers to get around limits. If the cost per active user has risen for three quarters in a row, write that down.
Signal 2: workarounds outside the platform
A workaround is anything built next to the platform because the platform cannot do it: a script that fixes data every night, a spreadsheet someone exports to, a manual step that nobody has automated because the platform makes it awkward.
List them. For each, note who maintains it and what happens if that person is away. One or two are normal. When the list grows every quarter, or when a workaround has become critical to a business process, the platform is no longer the system - it is one piece of a system nobody has fully documented.
Signal 3: days to make a small change
Pick the last ten small changes, such as a new field, a changed approval rule or a new report column. For each, count the days from request to live. Compare with the same measure a year ago.
This one is closest to what the business feels. If small changes took two days a year ago and take eight now, something has changed, whether it is the platform, the app's complexity or the people who know it. Find out which before blaming the tool.
An illustrative example
The numbers below are invented to show the method; they are not from a real client.
| Signal | A year ago | Now |
|---|---|---|
| Licence cost per active user, per year | 420 | 610 |
| Workarounds outside the platform | 2 | 7 |
| Days for a small change (median of ten) | 3 | 9 |
All three moved in the wrong direction. That alone does not mean "rebuild". It means the team should spend a week on the question: which of the seven workarounds cost the most, and which part of the app do they cluster around? In this example, say five of the seven are around the order-approval part. That is where you start.
If only one signal had moved, for example licence cost, the right move might be to renegotiate the plan or remove unused seats. A rule of thumb that works for many teams: act when two signals have moved the wrong way for two quarters, and stay put otherwise.
Keep it, when the signals say so
Keeping the platform is a decision, not a failure. It is the right call when changes are still quick, workarounds are few and documented, and the licence cost grows in line with real use. In that case, put your effort into governance: who may build what, how apps are named, and how often unused ones are removed. A tidy platform lasts a long time.
Moving in stages
If the signals say to leave, do not plan a big switch. Plan a sequence of small ones.
- Pick the first part. Choose the part with the most workarounds and the fewest links to other parts. Often that is a single workflow, such as approvals or quoting. Avoid starting with the part everything else depends on.
- Draw the edge. Decide how the new part will exchange data with the old app: a small interface, a shared database view, or a nightly file. Write it on one page. This edge is what lets you move the next part later without redoing the first.
- Build it next to the old one. The old part keeps running. Users do not switch yet. If you need a way to budget this, what a custom system costs in years two to five lists what is easy to forget.
- Run both on real work. Send a small group of users, or a single type of request, to the new part. Compare results for a full business cycle - a month for most teams, a quarter if you have quarterly closing.
- Switch and keep a way back. When results match, move everyone, but keep the old part readable and restorable for an agreed time, for example 60 days.
- Re-measure the three signals. If the workarounds around that part are gone and small changes are fast, you have evidence for moving the next part. If not, you have learned it cheaply.
If the first part is a spreadsheet-like process, moving from a spreadsheet to a small internal tool in 30 days is a useful pattern for the build itself.
Mistakes to avoid
- Starting with the hardest part. It feels brave and usually ends in a long project with nothing to show.
- Copying the old app screen by screen. The reason it is slow to change may be in how it was built, not only in the platform. Rebuild the workflow, not the screens.
- Switching off the old part on the day of the switch. You need a way back until the new part has proved itself.
- Counting only licences as savings. The bigger gain is usually faster change, which is harder to price. Track it anyway, using the third signal.
What to do this week
Collect the three numbers: licence cost per active user, a list of workarounds with owners, and the days for the last ten small changes. Put them in one table next to last year's numbers. Share it with the people who disagree about the platform. Often the conversation changes as soon as everyone is looking at the same page.