Every low-code platform has a ceiling, and the only comparison that predicts whether you will regret your choice is what happens when you reach it.
The analyst grids in this market rank enterprise suites on breadth: process designers, connector catalogues, governance features, AI assistants. Those are real criteria for a large IT department with a procurement process. They are close to useless for a team deciding how to build one internal tool this quarter.
Table of contents
- Low-code is three markets pretending to be one
- The ceiling test
- The sidecar pattern, which is what good teams actually do
- Costs that show up later
- A short recommendation
- How this fits the rest of the stack
- FAQ
Low-code is three markets pretending to be one
The phrase covers products with almost nothing in common, which is why the comparisons read strangely.
- Enterprise process suites. Built around business process modelling, case management, and approval flows. Sold to IT departments, priced by quote, and productive after formal training rather than after an afternoon.
- Internal tool builders. Point them at a database or an API and get an admin panel, a dashboard, or a CRUD interface. Fast, developer-adjacent, and the sweet spot for most teams who say low-code.
- Consumer app builders. Visual programming for customer-facing products. Powerful, with a real learning curve, and the category where lock-in matters most because the product is the platform.
If your problem is an internal admin panel, an enterprise process suite is comically oversized, and a consumer app builder is the wrong shape. Get the market right and the tool choice within it is close to a coin flip.
The ceiling test
Here is the exercise that tells you more than any feature grid. Take the most awkward requirement you already know about - the one integration nobody has, the unusual permission rule, the report that needs a join the visual query builder cannot express - and find out exactly how the platform handles it.
- Can you write code inside it? A JavaScript or Python block, a custom component, a computed field with a real expression language. This is the most important single feature in the category.
- Can you call an arbitrary HTTP endpoint? If yes, every missing integration becomes a small amount of work rather than a blocker.
- Can you deploy your own service alongside it? The escape hatch of last resort: put the awkward logic in a real API and have the low-code app call it.
- Can you get your data and definitions out? Not to leave, necessarily - to survive the platform changing.
A platform that scores well on these is safe to commit to even if its editor is slightly worse. A platform that scores badly is a bet that your requirements will never get complicated, and requirements always get complicated.
The sidecar pattern, which is what good teams actually do
The most durable arrangement is not choosing a platform powerful enough to do everything. It is deliberately keeping the hard parts outside it.
The low-code tool builds the interface, the forms, the tables, the permissions - the parts that are tedious to hand-write and easy to change. A small conventional service handles the awkward logic: the third-party integration with a strange auth flow, the nightly reconciliation job, the calculation with real business rules in it. The two talk over HTTP.
This works because it plays to both strengths. Visual builders are genuinely good at CRUD interfaces and genuinely bad at complex logic, and no amount of platform sophistication changes that. Trying to express a gnarly business rule in a visual editor produces something nobody can review and nobody wants to modify.
It also caps your exposure. If the platform disappoints you, the hard parts - the ones expensive to rebuild - are already in a repository, running as an ordinary service, in a language you can hire for.
Costs that show up later
Two lines in the budget that early evaluations consistently miss.
Per-user pricing at scale. Many of these products charge per seat, and internal tools have a habit of growing an audience. A tool that costs almost nothing for the five people who built it can cost real money at eighty, and by then it is load-bearing.
Maintenance ownership. Low-code applications get built by whoever needed them, often outside engineering, and then that person changes team. Six months later something breaks and nobody knows how it works, because there is no repository, no code review, and no test. This is the actual failure mode of low-code in most organisations, and it is a governance problem rather than a tooling one.
The mitigation is unglamorous: treat low-code applications like software. Name an owner, document what they connect to, and keep anything genuinely important in version control - which usually means keeping it in the sidecar service rather than in the platform.
A short recommendation
Pick from the right market. For internal tools, choose whichever internal-tool builder connects most cleanly to the database you already have, and check the ceiling test before committing.
Plan the sidecar from day one. Assume there will be logic the platform cannot express, decide now that it will live in a small service, and give that service somewhere to run.
And keep the database outside the platform. Whatever else you decide, your data should live in a managed database you control rather than inside a vendor’s storage layer. That single choice makes almost every future decision reversible.
How this fits the rest of the stack
The sidecar service is the part of this plan that needs somewhere to live, and it is usually small - one process, one database connection, a handful of endpoints. The RunxBuild hosting calculator shows what that costs alongside the database and bandwidth, so the escape hatch is budgeted rather than improvised. RunxBuild deploys services in Node, Python, Go, Ruby, Java, .NET, and Docker straight from GitHub, with managed MySQL and Postgres beside them, so the awkward logic and the data both stay yours.
Useful related references:
- Best Low-Cost Processor for Cloud Servers: AMD EPYC vs Intel Xeon in 2026
- Best Serverless Platform for FastAPI in 2024 and 2025: What Actually Matters
- Best AI Coding Agents: The Six Real Options, the Model Tier, the IDE Integration, and the One That Ships Code Without Asking
- Services on RunxBuild
FAQ
What is the best low-code platform?
It depends which of three markets you are in: enterprise process suites for IT departments with formal procurement, internal tool builders for teams putting an interface on an existing database, and consumer app builders for customer-facing products. Most people asking want the middle one, and within it the tools are closely matched.
What is the difference between low-code and no-code?
Low-code expects you to drop into real code for the hard parts and provides places to do it; no-code does not. That distinction matters more than any feature comparison, because every project eventually has a requirement the visual editor cannot express.
Can low-code platforms handle complex business logic?
Poorly, and this is not a limitation any vendor will solve. Visual editors are excellent for CRUD interfaces and bad for intricate rules, which become unreviewable when drawn as boxes. Put complex logic in a small conventional service and have the low-code app call it over HTTP.
What is the biggest risk with low-code tools?
Orphaned ownership. Applications get built by whoever needed them, outside normal engineering process, and then that person moves on. Months later something breaks with no repository, no review history, and nobody who understands it. Assign an owner and keep important logic in version control.
How do I avoid lock-in with a low-code platform?
Keep your data in a managed database you control rather than in the platform’s storage, put complex logic in a separate service, and check before committing that you can export both data and application definitions. Those three habits turn a potential rewrite into a migration.