When does low-code stop being enough? Five signals you have outgrown the platform

When a low-code platform stops being the right home for an application, the invoice usually says so first, quota errors say so second, and delivery speed says so last. Three things squeeze you: the platform's own quotas, a licence bill that grows with usage rather than headcount, and business rules that outgrow what the tool can express. A fourth one shows up latest and hurts most, which is the cost of leaving. You do not have to wait for an outage to make the call. If two of the five signals below are visible at the same time, decide now where that application spends its next year.

What low-code is genuinely good at

For narrow, internal work, these platforms are fast in a way that is hard to argue with. A request-tracking app made of a form, a table, an approval step and a notification is live in two weeks. Building the same thing from scratch takes two months, because you are also building authentication, deployment, environments and everything else underneath it. For a tool used by twenty or thirty people, holding a small amount of data, with a life expectancy of a year or two, spending those two months is usually waste.

The strongest use is as the first stop out of spreadsheets. Moving a process off Excel has an awkward middle step where nobody is sure what the process actually is, and low-code fills it well: fields settle down, ownership becomes visible, the workflow stops living in one person's head. The mistake is treating that middle step as a permanent home.

Signal one: you are approaching a quota wall

The limits are documented, and almost nobody reads them before signing. In Airtable, the record limit applies per base, and every table inside that base shares the same pool: 1,000 records on the free plan, 50,000 on Team, 125,000 on Business. Splitting your data across more tables does not help, because the counter sits above the tables.

On the Microsoft side there are two independent layers. Entitlement limits follow the licence: paid Power Platform and Dynamics 365 licences get 40,000 requests per user per 24 hours, while Power Apps per-app licences, pay-as-you-go, and Microsoft 365 licences with Power Platform access get 6,000. On top of that sit service protection limits, evaluated per user in a five-minute sliding window: 6,000 requests, 1,200 seconds of combined execution time, and 52 concurrent requests. Cross one and you get a 429 back with a Retry-After header telling you how long to wait.

What that means in practice is that large overnight batch jobs are a bad fit for this architecture. Bundling calls into batches to reduce the request count does not get you around entitlement limits either; Microsoft's documentation closes that door explicitly, and large batches hit the execution time limit faster anyway. Microsoft's own advice is to move away from periodic bulk jobs toward real-time integration. Any team that has watched a nightly job stop halfway reads that sentence differently.

Signal two: the bill grows with usage, not with headcount

The number people look at when buying is the monthly price per user. The question that matters is different: what is the billing unit, and does that unit grow as the business grows?

There are three shapes. Per-seat pricing is predictable, because it tracks your team size. Per-record or per-storage pricing climbs as data accumulates and never comes back down unless somebody deletes old data, which nobody does. The third is the slipperiest. Bubble meters runtime in "workload units" that count page loads, database searches, file uploads and scheduled workflows, so the app gets more expensive precisely because it is being used. Once you exceed the plan's included workload, the extra usage is billed on top.

Here is a check worth running this week. Divide your current invoice by transaction volume rather than user count, so you get a cost per order, per ticket, per record. Then multiply that figure by the volume you expect in two years. As with cloud spend, the unpleasant surprise always arrives the same way: the unit cost looks small, so nobody does the multiplication.

Signal three: the logic outgrew what the tool can express

This signal never appears on an invoice. It appears in how the team talks. Once you hear "I am not sure what else breaks if we change that", you are at the boundary.

The reason is mechanical. In code, a diff shows what a change does, automated tests confirm it, and review puts a second pair of eyes on it. In a visual editor all three are weak. You cannot read a line-by-line difference between today's version and the one from two months ago, and writing an automated test for a complicated rule is either impossible or sold as a separate product. Past three or four business-critical rules, fear of change sets in, and that fear is what technical debt looks like in a visual tool.

A usable dividing line: if the application manages one record in one system, the platform carries it comfortably. Work that keeps three systems consistent at once, calculates money, or needs a reconstructable audit trail sits where these platforms are naturally weak.

Signal four: you have no exit plan

This belongs in the purchase conversation, not the departure one. Bubble's own documentation is plain about it: apps run only on the Bubble platform, and there is no way to export your application as code. You own your data and your design; Bubble owns the code that runs the app. Data comes out as CSV or through the API, logic does not come out at all. The company commits to open-sourcing the platform if it ever shuts down, which is a decent commitment and no help whatsoever on a Tuesday.

The consequence is that moving a low-code application is not a data migration, it is a rewrite. The data is portable in most cases. What you lose is years of rules buried in screens and automation steps that were never written down anywhere else. Ask three questions before signing: can I export the data in a usable format, on a schedule, without asking anyone? Is there a human-readable dump of the application logic? If my account lapses, how many days do I keep access to my data?

Signal five: nobody knows which apps are running

The biggest benefit of low-code is that people who are not developers can build applications. The biggest risk is the same sentence. OWASP's list in this area started as the Low-Code/No-Code Top 10 and was later renamed the Citizen Development Top 10 to cover AI-assisted building as well. Ten entries; a few of them account for most of what we see.

CD-SEC-02 is account impersonation. On most platforms an automated flow runs with the identity of whoever created the connection, not whoever triggers it. Share the finance manager's approval flow with two hundred people and you have given two hundred people the finance manager's reach into that data. CD-SEC-03 is authorization misuse, where the platform's sharing settings and the underlying system's permission model know nothing about each other. CD-SEC-09 is asset management failure: applications nobody inventoried, built by somebody who has since left, still connected to production data. That last one shares a root with unapproved AI tool use. The easier the tool, the more work happens without IT ever hearing about it.

The answer is not to ban the platform but to make it visible. Making flows that touch production data run on service accounts instead of personal ones, keeping an inventory with a named owner per app, and separating a development environment from production are usually a day of admin work.

The hybrid setup: keep data and rules outside the platform

If an application is expected to live for years, use the platform as the interface and workflow layer rather than the system of record. Keep the data in your own database, keep business rules behind your own API, and have the low-code side call that API. Switching platforms then means rebuilding screens, not rediscovering how the company works.

This has a price. The setup requires real engineering, so you give back part of the speed the platform promised. That is why it is not for every app. Keep the split simple: short-lived, read-mostly tools stay fully on the platform, and anything that touches how the company makes money leans on a core that lives outside it.

If you are moving, go one workflow at a time

The classic failure in rewrite projects is switching off a working system and promising a replacement in six months. Start with the single workflow that hurts most. Move it into your own code, let the low-code app keep reading the same data, and let users work across both for a while. Then the second workflow. At some point the platform app is a read-only reporting screen, and turning it off stops being a project.

Before any of that, write the current rules down. Every conditional field, every automation step, every hidden button is a business rule, and most of them exist in no document anywhere. Teams that skip this step end up relearning the same rules one user complaint at a time.

Something concrete to do this week

Open a sheet and put every low-code application in the company on its own row. Columns: name, owner, number of users, systems it connects to, monthly cost. Then add the two columns almost no inventory has: how full the platform quota is, and what the plan is if you need to leave.

The rows where that second column stays empty are the ones carrying risk. If an app is past sixty percent of a quota and has no exit plan, that is the next piece of work. If you want a second opinion on which apps should stay on the platform and which should move into your own code, build the inventory first and then get in touch.