A logistics customer told us last quarter they’d spent 18 months and roughly 1.4 million euros on a Mendix project before abandoning it. The platform handled the first 20 screens beautifully. Screen 21 needed a non-standard data grid, and the workaround took longer than rebuilding the whole module would have in Angular.
That story is why we’re careful about what we call DEX Elements. It is not low-code.
The low-code trap
Low-code platforms made a compelling promise. Build enterprise applications without writing much code. Drag, drop, ship. Citizen developers. The promise delivers, up to a point.
The point is the moment you need a complex validation rule, a non-standard layout, a performance-critical data grid, or an integration with an enterprise API that doesn’t fit the platform’s mental model. Then the wall arrives, and the wall is brutal. You’re writing logic inside a proprietary expression language, debugging without proper tools, and deploying inside a runtime you cannot inspect.
We’ve watched enterprises adopt Mendix or OutSystems for one project and then spend more engineering hours working around the platform than they would have spent building the application properly.
What we built instead
DEX Elements uses JSON descriptors to define what applications do. That sounds adjacent to low-code, but the mechanics diverge in four ways that matter.
Low-code hides complexity. DEX makes it inspectable. The descriptor is a transparent specification. Read it, version it, diff it, code-review it with the same tools the team already uses for TypeScript.
Low-code locks you in. DEX generates standard TypeScript. If a customer stops using us tomorrow, they still own a normal application any developer can maintain. There is no runtime dependency on our infrastructure.
Low-code limits extension. DEX has explicit escape hatches. Any screen can incorporate custom components written in plain TypeScript. The framework handles roughly 90% of cases. Custom code handles the rest, with no penalty.
Low-code charges per user. DEX charges for the platform. Pricing has nothing to do with how many people use what was built on top of it.
The real difference
Low-code is a runtime. You build on it, deploy on it, scale on it. The application does not exist outside of it.
DEX is a generator. It produces applications that run independently. The framework provides structure during development. The output is autonomous after deployment.
That distinction matters enormously for enterprises that cannot accept platform dependency for mission-critical systems. They learned the lesson once with Oracle Forms. They will not make the same mistake with a low-code vendor.
Who this is for
DEX is not the right tool for someone building a contact form or a basic approval workflow. There are plenty of tools for that.
DEX is for the team building a 50-screen ERP module with complex validation rules, role-based access, audit logging, and real-time API integration, who wants it shipped in months and refuses to accept vendor lock-in as the price of speed.
That’s a specific customer. We know exactly who they are. They’re tired of being told their only options are slow and safe or fast and locked in. We think there’s a third option, and it starts with making the output theirs.