No-code platforms are usually sold as a replacement for developers and defended as no such thing. Both framings miss what actually happened, which is more interesting: no-code moved the wall, it did not remove it.
Everything before the wall got dramatically cheaper. Everything after it got slightly more expensive, because now you are rebuilding something that already half exists.
Where the wall is
You hit it the first time you need something the platform’s authors did not anticipate. Not something difficult — something unanticipated. The two are unrelated, and that is what makes the wall hard to plan for.
| Requirement | On a no-code platform |
|---|---|
| A form that writes to a table | Twenty minutes |
| An approval workflow with notifications | An afternoon |
| An internal dashboard over existing data | A day |
| A specific PDF layout the regulator requires | Days, or impossible |
| Bulk operations on 50,000 rows | Slow, often times out |
| An integration with no existing connector | Custom code anyway |
| Fine-grained permissions per record | Frequently the hard wall |
What genuinely changed
- Internal tools stopped queueing. The request that used to sit in a backlog for two quarters now gets built by the person who wanted it, in an afternoon. This is the largest real effect and it is mostly invisible from outside a company.
- Prototypes became free. Testing whether anyone wants a workflow no longer costs two developer-weeks, so more ideas get tested and more get killed early.
- The definition of a developer widened. An operations person maintaining twelve automations is doing software maintenance, whatever their job title says.
- Shadow IT got a user interface. The same tools that let people solve their own problems let them build business-critical systems nobody has reviewed.
The costs nobody quotes
Per-seat pricing scales badly. A tool at $20 per user per month is cheap for six people and a serious line item for four hundred. Model the cost at the size you expect to be, not the size you are.
No real version control. Most platforms offer limited history and no meaningful diff. When an automation breaks, you often cannot see what changed or who changed it — which is exactly the information you need.
Testing is manual. There is usually no way to write automated tests for a visual workflow, so every change is verified by clicking through it. That cost grows with the number of automations, quietly.
The bus factor is one. The person who built it understands it. Nobody else can read it, because there is nothing to read — just a canvas of connected boxes whose logic lives partly in configuration panels.
How to decide, in three questions
- Is this internal or customer-facing? Internal is where no-code is strongest — you control the users, the volume and the expectations. Customer-facing raises the cost of every limitation.
- What happens if it stops working for a day? Mild inconvenience, build it on a platform. Revenue stops, then it needs the same rigour as anything else you run.
- Will the requirements stay inside the platform’s model? Be honest. Most requirements drift toward specificity over time, and specificity is where the wall sits.
The hybrid that works
The pattern that has held up in practice: use the platform for the interface and the workflow, and call out to real code for the parts that need it. Most credible platforms support a webhook or a custom function, and that escape hatch is the single most important feature to check before adopting one.
You keep the speed for the 90% that is genuinely standard, and you keep the option of solving the 10% properly instead of contorting the platform into a shape it resists.
Ask about the escape hatch before you ask about the templates. The templates sell the tool; the escape hatch determines whether you can live with it.
Common questions
Can I export what I build?
Data, usually. Logic, almost never. Assume that if you leave the platform you are rebuilding the behaviour from scratch, and factor that into anything you plan to run for years.
Is it worth learning for a developer?
Yes, narrowly — knowing when to reach for one saves you writing internal CRUD apps you do not enjoy anyway. It is a tool in the box, not a threat to the box.
How do we govern this without killing it?
A register of what exists and who owns each one, plus a rule that anything touching customer data or money gets reviewed. That is enough. Requiring approval for every automation returns you to the backlog you were escaping.
What about AI builders in the same space?
Same wall, different marketing — and the same question about what you own afterwards. We went through that for websites specifically in AI website builders compared.
Leave a Reply