What is a low-code platform, and what happens after year two?
Low-code moves building closer to the people with the problem. The question nobody asks at purchase is what the applications look like once the person who built them has moved on.
Rithul Palazhi11 min read
On this page
A low-code platform lets people build working applications with far less code than writing one from scratch — visual composition for the structure, with code available where the visual tools run out. No-code removes the escape hatch entirely.
The pitch is usually about speed, and the speed is real. What determines whether the decision looks good in three years is something else: what happens to those applications when the person who built them has moved to another team, and whether anybody can still change them.
What we'll cover
Low-code and no-code
Low-code assumes some code. Visual composition for the common structure, with a scripting escape hatch for logic the visual tools cannot express.
No-code assumes none, which makes it accessible and means that when you reach its limit, you rebuild rather than extend.
The escape hatch is the important difference. Every non-trivial application eventually needs something the visual model does not cover, and what happens at that moment determines whether the tool scales with the problem.
The marketing terms blur, so evaluate the actual boundary: what can be expressed, what requires code, and whether that code is testable and versionable.
Both are platforms first. You are choosing a vendor and an operating model, not just a development approach, which is why the durability questions below matter more than feature comparisons.
Where it genuinely wins
Worth being positive about, because the wins are real and specific.
Internal tools with modest logic. Request forms, approval flows, simple trackers, admin interfaces — things that would sit in an engineering backlog for two quarters and be built in a week.
Applications the domain expert can maintain, where the person who understands the rules can change them without a ticket and a sprint.
Replacing the spreadsheet that became a system. This is the highest-value case in most organisations and the most common one.
Prototypes that prove a workflow before anybody commits to building it properly.
Work with real deadlines and no engineering capacity, where the alternative is not a better application but no application.
Where it stops helping
Complex domain logic. Conditional rules with many branches become unreadable in a visual editor long before they become unmanageable in code.
Anything needing real testing. Automated test coverage on a visual application is limited on most platforms, so confidence comes from manual checking.
High-volume or latency-sensitive work, where the platform's execution model is a constraint you cannot tune around.
Anything requiring code review. If a change needs two people to agree it is correct before it ships, a platform without meaningful diffs makes that difficult.
Deep integration with unusual systems, where the connector does not exist and the escape hatch is the only route, at which point you are writing code inside a constrained environment.
Year two
The part nobody evaluates at purchase, and where low-code decisions are actually judged.
The builder has moved on. The application still runs and nobody knows how it works, because the documentation is the application.
Nobody knows what exists. Applications accumulate across departments with no inventory, and the first census is always surprising.
Changes are risky. Without tests and without diffs, a change is made by clicking and verified by trying, which does not scale with the number of people depending on it.
Things break when the platform updates. A visual application is coupled to the platform's behaviour in ways that are hard to enumerate.
Some applications have become critical without anybody deciding they should be, which is the situation to detect early rather than during an outage.
None of this is an argument against low-code. It is an argument for treating what gets built as software, which is the thing that consistently does not happen.
Lock-in, honestly assessed
Your logic lives in their format, and there is generally no meaningful export. Leaving means rebuilding.
That is a real cost and not automatically a bad trade. An internal tool that took a week and saved a quarter's waiting has paid for itself long before any migration question arises.
The trade is bad when the application becomes critical, at which point you have a system you cannot move, cannot test, and cannot fully staff.
Price changes are the usual trigger, since a platform whose pricing shifts leaves you with a rebuild or an unpleasant negotiation.
Ask what happens to your data, which is usually more portable than your logic — and knowing that in advance shapes what you are willing to build there.
Governance that is not bureaucracy
The middle path between an approval board and no oversight at all.
Keep an inventory. What exists, who built it, what it depends on, and who uses it. This one artefact prevents most of the year-two problems.
Classify by consequence, not by size. An application nobody would notice failing needs no oversight; one that people or money depend on needs an owner and a review.
Name an owner for anything above trivial, and reassign when they leave rather than discovering it during an incident.
Review access to data. The common risk is an application quietly reading more than its purpose requires, because broad access was the easy configuration.
Have a promotion path. When an application outgrows the platform, the answer should be a known route to being rebuilt properly, not an argument.
Questions to ask before buying
What happens when we need something the visual tools cannot express?
Can changes be reviewed before they take effect, and can we see what changed?
Can we test an application automatically?
What is the upgrade story, and what has broken for customers in the last year?
What can we export, both data and logic, and in what form?
How does pricing change with usage, since per-user and per-run pricing behave very differently as adoption grows?
The answers matter more than the feature list, because the feature list is what you evaluate in month one and these are what you live with in year three.
Counting what it costs
Low-code business cases are usually built on build time, which is the part that is easy to measure and rarely the largest number.
Licence cost scales with adoption, and per-user pricing that looked cheap for a pilot behaves differently when four departments are using it.
Per-run or per-execution pricing rewards a different design entirely, and an application built without knowing which model you are on can be expensive in ways nobody predicted.
Maintenance is the recurring cost. Somebody keeps each application working through platform updates and changing requirements, and that time is real even though it appears on no invoice.
Count the rebuild in the risk, not the cost — the probability that a critical application has to be rebuilt elsewhere, times what that would take.
Compare against the honest alternative. For most internal tools the alternative is not a well-engineered application; it is a spreadsheet, or nothing, and both have costs of their own.
Review annually. The platform that was obviously right at twelve applications may not be at ninety.
Where CodeWords fits
CodeWords is aimed at the automation half of this rather than at building applications: describe what should happen in plain language, and it builds, connects, and deploys the automation. It connects to more than 3,000 integrations.
- Open CodeWords and start a new automation.
- Describe the outcome to Cody, the automation builder, including the exceptions.
- Connect the systems involved, once, and reuse the connections.
The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What to get right first
An inventory of what gets built, from the first application onwards. It is a spreadsheet, it takes minutes to maintain, and it prevents nearly every problem described in the year-two section — because the underlying issue is not that low-code applications are fragile, it is that nobody knows they exist.
Two habits make the difference. Record an owner for anything beyond a personal tool, and reassign it when they move rather than when it breaks. And classify by consequence rather than complexity, so oversight lands on the applications people actually depend on instead of being applied uniformly to everything.
Frequently asked questions
What is the difference between low-code and no-code?
Low-code has an escape hatch to real code; no-code does not. The difference matters at the point where the visual tools cannot express what you need, which every non-trivial application eventually reaches.
What should not be built on a low-code platform?
Complex conditional logic, anything needing automated tests or code review, and anything latency-sensitive. Also anything that would be catastrophic to lose, since portability is limited and rebuilding is the exit.
Is lock-in a reason not to use it?
Not on its own. An internal tool built in a week that saved a quarter of waiting has already paid for itself. The trade turns bad when an application quietly becomes critical, which is what an inventory and an owner are for.
What goes wrong after a year or two?
The builder moves on, nobody knows what exists, and changes become risky because there are no tests and no diffs. The applications are fine; the absence of any record of them is the problem.
How much governance is appropriate?
An inventory and an owner per non-trivial application. Classify by consequence rather than complexity, and have a known route for promoting something that has outgrown the platform rather than arguing about it each time.
What should I ask a vendor?
What happens when the visual tools run out, whether changes can be reviewed and diffed, whether applications can be tested automatically, what has broken during upgrades, and how pricing behaves as usage grows.
Does low-code replace engineers?
It changes what they spend time on. The simple internal tools stop reaching the backlog, and the engineering attention moves to the systems where correctness, scale, and testability matter — which is usually a better allocation of both.
How should I cost a low-code platform?
Licence cost as adoption grows, the pricing model's effect on how applications should be designed, and ongoing maintenance — which appears on no invoice and is usually the largest recurring number. Compare against the honest alternative, which is often a spreadsheet rather than a built application.
When should the decision be revisited?
Annually, and whenever the count of applications jumps. A platform that was clearly right at twelve applications may not be at ninety, and pricing models frequently change the answer before the technology does.
How do I find out what has already been built?
Ask each department and check the platform's own application list, then record owners. The first census is always larger than expected, and the applications nobody remembered are usually the ones with no owner and the most access to data.
What is the single most useful practice?
An inventory with an owner per application, maintained from the first one. Nearly every problem that shows up in year two reduces to nobody knowing what exists or who is responsible for it.