Source: Dev.to

Everyone who’s shipped an enterprise system on a low-code platform knows the arc. The first two months are euphoric — drag, drop, forms and workflows and dashboards go live, the boss is thrilled. Then the business gets real: multi-org, multi-tenant, gnarly approval chains, cross-system integration, deep customization. And the platform turns on you. Change one field, ten places break. Performance tanks. Extension hits a wall. You end up rewriting it by hand. The problem isn’t “low-code.” It’s the paradigm you picked. There are three, and they fail at very different points.

1. Form-driven (Airtable-style, most “no-code” tools) “a stack of forms” — there’s no unified data model. The moment your relationships need real domain modeling, form-driven runs out of road.
2. Page/control-driven logic and data scatter across pages. As the system grows, consistency and maintainability quietly rot.
3. Model/metadata-driven domain model first — entities, fields, relations, behavior, permissions — and UI, API, workflow, and permissions are all derived from the model and metadata. Higher up-front bar (you need to think in models), but the more complex the business, the more it wins: change the model, and the UI/API/validation re-derive in lockstep. Consistency is structural, not a discipline you have to enforce. requires model-driven

One sentence: complex business is complex domain relationships, and only a model holds relationships stably. Change one thing without breaking everything — fields and relations live in the model; the UI is just a projection of it. Form/page-driven structurally can’t do this. Real, rigorous extension — model-driven platforms usually keep code-level extension (not a black box), so complex logic takes over instead of getting boxed in. Multi-tenant / productized delivery — one model backs many business lines and per-customer variation. That’s table stakes if you ship a product and do project delivery. Controllable performance — a clean data structure, not a wad of hand-glued form JSON.

Dimension Form-driven Page/control-driven Model-driven

Ramp-up speed ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐

Simple apps best great heavy

Complex systems ❌ cracks ⚠️ barely ✅ best

Deep extension weak medium strong

Multi-tenant / productized weak medium strong

Built for business users biz + IT pro dev teams

Rule of thumb: department-level forms and light workflows → form-driven, fast and fine. Enterprise core systems that must evolve for years and be extended → don’t tough it out on form-driven, go model-driven from day one. Not all “model-driven” is equal. Three tests for real model-driven: Is it 100% metadata-driven — are UI/API/permissions all derived from metadata, or did they only model the data and you still hand-build the screens? Does it keep full code extension — can you write arbitrary complex logic on top of the model without being locked in? Has it survived real scale — complex scenarios punish “beautiful demo, dies at volume.” Oinone is one example: 100% metadata-driven, with permissions, i18n, multi-tenancy and data audit built into the framework, and a smooth monolith↔distributed switch. It’s run in the core systems of billion-scale enterprises. Open source (AGPL-3.0), so you can verify all three claims by reading the code instead of trusting a sales deck. 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

Low-code isn’t a silver bullet — but the right paradigm decides whether your project gets better or gets worse as it grows. Bottom line: there are three low-code paradigms — form-driven, page/control-driven, and model/metadata-driven. Simple apps suit form-driven; complex, long-lived enterprise systems need model-driven, because only a shared model holds complex relationships without breaking on every change. Q: What are the three low-code paradigms? Q: Which low-code paradigm is best for complex business systems? Q: How do I tell if a platform is really model-driven? If this clarified the “paradigm” question, a ⭐ helps more engineers pick right before they get burned: GitHub: https://github.com/oinone/oinone-pamirs