Low-code App Builder
- NestJS
- Prisma
- React
- Redux Toolkit
- CodeMirror
Low-code · Visual editor · B2B fintech (US)
A drag-and-drop visual editor that gave business teams real autonomy: they build and publish production screens without waiting on engineering. I led it end-to-end — backend and frontend — from MVP to production.
What problem does the Low-Code App Builder solve?
In a regulated financial services product, the screens users see change constantly — new fields, new rules, new flows, new compliance requirements. Every one of those changes went through engineering. Business and operations teams had the domain knowledge but no way to act on it, and engineers spent significant time on repetitive UI configuration work rather than on the core product. An off-the-shelf low-code tool covered part of the need but couldn’t integrate deeply with the platform’s own services and data model.
I built a drag-and-drop visual builder — in the spirit of Retool — that replaced that third-party tool, with two halves: the editor, where the business side composes the screen, and the platform that serves it in production.
How was the Low-Code App Builder built?
The editor is a canvas where non-technical users compose pages from sections, columns and components; build tables cell by cell with typed formats (text, number, currency, date, select, checkbox); bind data-driven tables to a data source path; and set role-based visibility rules.
On the backend, a service organized around ten domains — pages, layouts, tables, data-driven tables, versions, deployment, embedded modules, settings, and more — with the version lifecycle as its core abstraction.
This was the hardest constraint: it ran in production for a financial product, so a careless change to a screen couldn’t be allowed to break a live application flow. I modeled the whole system on Git’s mental model — branch, deploy, publish — instead of inventing a bespoke lifecycle.
Publishing touches a lot of assets, so I moved it off the request path into a background job queue: the editor stays responsive while publishing happens asynchronously and reports status back to the user. Version lifecycle events are broadcast on an event bus so sibling services stay in sync.
What technical decisions underpin the Low-Code App Builder?
In-browser TypeScript type-checking
Users write short expressions and one-line functions to compute values. Rather than let those fail at runtime in production, I embedded a code editor running TypeScript in the browser.
- Live type-checking in the browser, not at build time or in production
- One-line expressions, not full scripts — scoped to what the platform can safely run
- Type errors surface as the user types, not after they publish
Explicit save state, as a first-class citizen
Autosave is invisible until it fails. I modeled save status as first-class state, with a persistent indicator.
- Users always know whether their work is safe — they shouldn't have to assume it
- Avoids the classic "did this actually save?" doubt in a production tool
The AI layer: what I built, and what I killed
The first attempt at an AI feature was chat-driven UI generation: describe the screen you want, and an LLM generates it. I built it, evaluated it, and it didn’t hold up — it was slow, and the generated output wasn’t precise enough to integrate correctly with the platform’s existing services and data contracts.
The model plans, a deterministic pipeline executes
That's the design principle that made the orchestrator viable. The LLM never improvises side effects: it chooses what should happen; typed service calls with retries and partial-success reporting decide how.
- An orchestrator parses the user's intent and builds an execution plan
- Seven specialized agents delegate, each with its own scoped reasoning
- No agent framework: orchestrated directly against the model SDK — fewer layers, much simpler debugging
In a financial system, that separation between planning and executing is the difference between a usable feature and an unacceptable risk.
Closing
The tool replaced the third-party low-code product the teams had been using, and moved UI changes out of the engineering queue entirely — business teams build and publish on their own today. Of everything I built here, what matters most to me isn’t the editor itself — it’s having known when to kill the first version of the AI feature instead of polishing it, and rebuilding it on a simple principle: the model decides the what, the code decides the how.