Real tables. Real forms. Real workflows.
An app here is assembled, not generated: governed primitives that already run field-service, inspection and CRM-style apps in production. Objects on real Postgres tables, forms with rules, grids and views, screens, workflows, groups and permissions. Your agent reaches each one through a named operation, and the platform renders the result for web and mobile.
Every primitive on this page ships today. Nothing here is a roadmap item.
Desktop builds are being finalized for launch — the download page has the access list and the installer link.
Objects are real Postgres tables.
Objects are real tables in a schema that belongs to your account. A dimension is a column; adding one runs a real ALTER TABLE. Every table gets id, a platform id, tenant_id, created_at and last_modified without anyone asking.
Solutions in an account share the schema, so every object name carries a three- or four-character solution prefix — crm_accounts, ven_invoices.
Object views are SQL-backed views that JOIN object tables and add computed columns, with WHERE tenant_id = ? injected for you. They are the production-grade pattern behind a grid.
Grids are queried at runtime with filter operators — $eq, $contains, $gt, $in — plus ordering and pagination. Because your records live in ordinary tables behind a documented REST API, your data is never locked in a format only we can read.
Forms carry rules, not just fields.
Field types cover the working set of a business app: single-line text, numeric, multiple choice, lookups into other objects, signature capture, sections and section headers. Fields carry required, read-only and unique flags.
Rulepacks make those flags conditional. Combine rules with AND, OR and NOT — required if the amount is over a threshold, read-only once approved — and builders can edit them without touching anything else. Calculated fields use an expression parser for totals and derived values.
Public forms accept anonymous submissions with tenant handling built in — the basis for intake and survey apps. Templates prefill records; form packets chain steps into one multi-step flow.
Screens are generated. The drawer obeys your groups.
A screenflow describes screens, navigation and the left-hand drawer. Generating one for an object typically yields the three screens most apps want: navigation cards, a grid list with a create button, and a create-or-update form. Your agent adjusts from there — rename a screen, move a component, change what the drawer shows.
Drawer entries and actions are permission-gated by group. A button a group cannot use is hidden in the renderer and rejected on dispatch, so the UI and the server agree.
Branding is per solution — brand color, primary colors, logo — with header and body script hooks for analytics or a support widget. Translations ship in the same solution definition, so one app can speak more than one language.
Workflows that reach outside the app.
A workflow is an asynchronous chain of activities, fired by an action a person or a system takes. The activity types are the ones business apps actually use: email with {{field}} templating, create, update or delete an object, generate a PDF report from record data, an HTTP POST to Zapier, Make, n8n or any endpoint you own, and a push notification.
Chain them: on approval, email the requester, generate the PDF, post the payload to your billing system, notify the field team. Wire the chain to an action, and the button in the app fires it — with the actor's permissions checked first.
The limit worth designing around: workflows run off the request path, and we publish no retry or exactly-once guarantee for them. Point them at endpoints that tolerate a retry or a miss.
Permissions the server enforces, history per row.
Groups — including a system Everyone group — gate drawer entries, screenflow actions and grid views. Permissions are evaluated on the server and mirrored in the client, so hiding a button is never the only line of defense.
Tenant isolation is row-level. Every object table carries tenant_id; every query is filtered on it automatically; every data write requires an explicit tenant context or fails fast. One account can serve many tenants — build one app, run it for many clients.
To be precise: that is isolation at the data layer inside your account, not separate infrastructure per client. If you are running client work on it, say so before the client asks.
The change log is per row. Turn it on for an object and every change is recorded; people read it in the app, agents read it through get-instance-changelog. Useful for compliance, and for answering “who changed this?” without a support ticket.
Your agent never sees raw solution, form, workflow or screenflow JSON. Reads return compact structural maps — labels, ids, relationships. Writes are named for the change they express: add-field-to-form, update-drawer, set-object-permissions.
That is why the logs on this page read like intent, not like a patch. Every write is a named operation with a fixed shape, checked against your permissions before it lands — not free-form code running against your backend.
Two exceptions, named: a stripped single-field view for editing one field, and the header and body script hooks above, which do inject JavaScript into the rendered UI — treat them like any other script tag you add to a page.
See the primitives assembled.
Blueprints map an app to its primitives and hand you a starter prompt. Or keep reading about how the machine works.
See a blueprint
Field service, CRM-lite, approvals — the primitives map and the prompt that builds it.
Open the blueprintsWhere it runs
Platform apps publish from a working copy to testing and production. Custom frontends promote develop → staging → production.
See the chainWhen the renderer isn't enough
Write React over the same objects and ship it through the same chain.
See the pipelineHow it works · Security · Pricing — every primitive is covered by the organization license and never metered. You bring the AI subscription you already pay for; what a meter would have cost you is worked out on the meter.
Bring us something you want built.
CodeMonster is invite only while we work directly with early adopters. Request an invite and we will meet, scope what you want to build, and get you productive. You bring the AI subscription you already pay for.