A platform that builds business apps — without code

A multi-tenant platform where a company builds its own internal applications from settings rather than source code — workflows, forms, views, roles, triggers, AI agents — and a separate runtime serves those apps to end users.

The Studio does not generate code. That one distinction drives most of the architecture below.

When a customer invents a field at runtime, it has to go somewhere. There are three classic answers, and each hurts in a different place.

Most platforms pick one and live with its weakness. This one refuses to.

Letting the runtime read the builder's tables is simple and wrong twice over: a six-to-ten table join on every request, and every builder schema change becomes a runtime schema change. Publishing is a compile step instead.

The decision I'd defend hardest, because it looks like a compromise and isn't. Because the JSONB is authoritative, the typed table can be dropped, retyped, renamed or rebuilt from nothing — the backfill replays it. That is what makes deploy-time DDL against customer data survivable rather than terrifying.

The case that proves someone thought it through is the in-flight one: dropping a column an older still-deployed version references would corrupt running instances. So a deploy unions every active version's field set and aborts on a type conflict rather than guessing.

Instances are pinned to the version they started on, and a published version rejects structural edits. The usual answer stops there — “you can't change a published workflow” — which isn't good enough, because what most needs fixing in production isn't structural.

Known gap: view configuration isn't versioned, so it can drift from the workflow version it belongs to.

The builder — Studio frontend and backend — and the shared runtime engine, AI agents included. Design-time and runtime, not a single service. Most of the work went into the read and commit paths.