Apps

An App is the heaviest of the five Keep shapes. It’s a small web application the Agent generates on the spot — HTML, CSS, JavaScript, and CRUD endpoints wired directly to your data.

Use an App when the answer isn’t “here’s what I found” but “here’s a tool the team needs.” A return-request form. An inventory editor. A customer-lookup page for support. A generated dashboard with editable filters.

Creating an App

One sentence in chat is enough.

> Build a CRUD admin for the users table — name, email, plan, and a "cancel plan" button.

The Agent:

1. Reads the users table schema.
2. Generates HTML for a list view + an edit form.
3. Writes CSS in the active theme.
4. Wires CRUD endpoints (list, read, update, delete) through Tablize’s direct-PG layer.
5. Renders the App in Split view.

You can refine by asking — “add a search field by email” or “disable the delete button for admin users” — and each change is a single Agent turn that patches only what changed.

Anatomy of an App

• UI — HTML / CSS / plain JS. No build step, no React. Loads in under a second.
• Data Contract — the set of queries and mutations the App is allowed to perform. Declared up front; the backend enforces.
• Endpoints — auto-generated REST endpoints against the declared queries. Direct Postgres, ~milliseconds.
• Permissions — who can view, who can edit, who can delete. Defaults to workspace members; overrideable.
• Version history — every generation is saved, rollbackable.

Apps are served from the same domain as your workspace, so auth works automatically for workspace members. Public Apps generate a stable URL like app.tablize.com/a/<id>.

The Data Contract

Most “low-code” tools have one of two flaws:

• Open database access — the UI can issue any SQL, which is a disaster when the UI has a bug.
• Pre-built blocks — constrained, can’t express what you actually need.

The Data Contract is neither. When the Agent generates an App, it also generates a list of the queries it will call — parameterized, typed, read-only or read-write. The backend refuses any query not on the list.

So:

• The App is fast — direct PG, no Agent in the request path.
• The App is safe — can’t do anything the Contract doesn’t declare.
• The App is auditable — the Contract is a human-readable list; you can review it before publishing.

If you later want to add a feature, the Agent extends the Contract and regenerates the UI. You don’t handwrite SQL.

CRUD operations

• Create — insert rows.
• Read — list, filter, sort, paginate.
• Update — edit individual rows.
• Delete — soft (default) or hard.

The default form validates against your table’s NOT NULL and CHECK constraints. Custom validations (e.g., “plan must be one of free|plus|pro”) are picked up from column comments or asked during generation.

Themes

Same 11 themes as Dashboards. Switch with a sentence: “use the terminal theme.”

Theme is per-App; a team can have a support app in corporate and an ops app in synthwave without conflict.

Publishing

Apps are draft-only until you publish:

• Draft — only you can see and run it.
• Team — workspace members.
• Public — anyone with the URL (rate-limited, no login).

Each publication mode is a git-style tag on the current version. Reverting a public App to an earlier version un-breaks a bad change without losing history.

Version rollback

Sidebar → the App → Versions. Every save is listed with a short auto-description. Click Restore to revert the live version. Published Apps:

• Team / Public — rollback is instant; users see the old version within seconds.
• Draft — rollback happens in your session only.

Rollback is safe — the Data Contract is versioned alongside the UI, so you don’t accidentally run mismatched queries against a new UI.

Embedding

Same as Dashboards — public Apps support iframe embed:

<iframe src="https://app.tablize.com/a/<id>/embed" width="100%" height="600"></iframe>

Useful for embedding a customer-editable form in a marketing site, or a support tool inside a Notion doc.

Apps vs Dashboards

	Dashboard	App
User intent	Read	Read and write
Panels	Visual	Visual + forms, buttons
Contract	Read-only queries	Read + write endpoints
Complexity	Low	Medium

If you find yourself adding lots of “edit” interactions to a Dashboard, that’s when to migrate to an App.

Limits

Plan	Active Apps	Requests / day
Free	—	Apps not available
Plus	3	10k
Pro	25	100k
Max	Unlimited	1M+

Request counts are across all your Apps combined. Apps that hit the limit degrade gracefully — they show a “rate limited” page until the next day, not a 500.

Custom domains

Max plan supports binding an App to your own domain (e.g., inventory.acme.com). CNAME setup is two lines; TLS is auto-provisioned via Let’s Encrypt.

Common gotchas

• “Update failed” on form submit. Usually a NOT NULL column that the form doesn’t include. The Agent detects and fixes this if you ask: “include the missing columns.”
• App renders blank on first publish. The Data Contract declares a query that fails in production (dev data had something prod doesn’t). Click View errors in the App’s logs.
• Public App URL shows “workspace suspended.” Billing issue on the owner’s account. Fix the billing, App comes back.
• Theme doesn’t match the Dashboard next to it. Themes are per-artifact; set both to the same theme name explicitly.

Next steps

• Dashboards — for read-only sibling cases.
• Reports — for narrative shapes.
• Workspaces & roles — for seat and permission setup before inviting App users.