DEV Community

cpengc1984
cpengc1984

Posted on

"Supports custom code" means nothing. Here's the 3-level ruler that tells you if a low-code platform will lock you in.

#lowcode #devtools #opensource #softwareengineering

Every low-code vendor says "we support customization." But supports is a weasel word — recoloring a button is customization, and rewriting a scheduling engine is also customization. What actually decides whether a platform locks you in is how far up its extensibility goes. Here's a ruler.

The three levels of customization

Level What you can do Most no-code A real dev framework
L1 — Config Fields, forms, workflows, permissions, themes ✅ ✅
L2 — Extension Custom components, custom actions, external API calls, business rules ⚠️ limited ✅
L3 — Framework Modify/extend the core, custom engines, deep rewrites, source under control ❌ wall ✅ (when open/controllable)

Where it stops is where your ceiling is. Plenty of no-code platforms are delightful at L1, then hit "can't do that" at L2/L3 — and you retreat to writing your own thing next to it. Now low-code is the burden.

Why you get locked in

  1. Black-box SaaS — no source, so any extension point the vendor didn't expose is simply out of reach.
  2. Two sources of truth — your extension code and the platform's config live in different systems, so a platform upgrade breaks/voids your work.
  3. Crippled self-hosting — the on-prem edition quietly drops extension capabilities.
  4. Closed ecosystem — only their component marketplace; your stack can't get in.

How model-driven + open source raises the ceiling

  • One unified extension system — your extensions (custom fields/components/actions) and the platform itself are built on the same metadata. Extension isn't a bolt-on, it's a first-class citizen — upgrades don't wipe your customizations.
  • Source under your control — open + self-hostable is what makes L3 framework-level extension actually possible: an extension point you can't reach, you can add.
  • AI at the metadata layer — AI-generated extensions land in the same model, so they stay maintainable and evolvable.

That's the road Oinone takes: 100% metadata-driven, front + back end open source, self-hostable — customization reaches L3.

How to stress-test extensibility in a POC (never trust the word "supports")

  1. Bring a requirement the platform has no built-in support for and ask "how would I build this?" — watch whether it's an L2 extension or a flat "can't."
  2. Ask whether your customizations survive a platform upgrade.
  3. Pin down the source & self-hosting boundary — what's modifiable, where you get locked.
  4. Check whether extensions and the platform share one system (this decides maintainability).

Try it (one command, self-hosted, ~5 min) 

curl -L https://github.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin
Enter fullscreen mode Exit fullscreen mode

"Supports customization" is noise. "To which level, and will it lock me in" is the real question. For long-term autonomy, prefer platforms where extension is a first-class citizen and the source is under your control. Bring the L1/L2/L3 ruler to your next selection meeting.

If the ruler was useful, a ⭐ helps more engineers dodge the lock-in trap:

Top comments (0)