Declared data model
Collections and fields are declared and validated before any code is written, and the app reads them through one runtime contract.
AI web app builder
Build an app with records, forms, and sign-in — not a page that looks like one.
Tervane generates working collections, forms, actions, and end-user sign-in behind server-routed endpoints, so the generated app never carries a database key you would have to rotate.
Collections, forms, actions, and roles in the first build.
No model-authored SQL, ever.
Every version is saved and restorable.
The difference between a site that shows data and an app that holds it
Most AI builders will happily render a table of customers. The interesting question is what happens on the second day: where those rows live, who is allowed to read them, what occurs when a form is submitted by someone who is not signed in, and whether any of that survives the next edit.
Tervane treats the data model as the thing being generated. Collections, their fields, the forms that write to them, the actions that run, and the roles that can see them are declared as a validated structure first. The interface is generated against that structure, which is why a later change to a field does not quietly leave a form pointing at nothing.
Access rules are derived, not written by a language model
The most dangerous thing an AI app builder can do is author its own security rules. A policy that reads plausibly and is subtly wrong is worse than no policy, because it looks reviewed.
Here the policies are generated from the validated model by ordinary code, one rule per operation, and the resulting migration is passed through a linter that rejects destructive statements. The model chooses what the app is for. It does not get to choose who can read the rows. That boundary is the reason the backend surface is deliberately narrower than some alternatives.
No keys in the generated bundle
Generated apps talk to their data through server routes owned by the platform. There is no client-side database client holding a project key, which removes an entire class of failure — the one where a builder ships a working app and a scraped credential in the same download.
Uploads, record reads and writes, sign-in, and external data fetches all pass through those routes, which is also what makes rate limiting, quota accounting, and audit trails possible at all.
Sign-in that maps to real roles
Apps that need accounts get end-user authentication with the roles declared in the model, and the interface is generated for each of them — an admin view and a member view are different generated screens, not one screen with a hidden button.
The browser verification step exercises this directly: it drives two separate signed-in contexts and confirms that one member cannot reach the other member's records, before the build is accepted.
Frequently asked questions
- Can it build something with logins and per-user data?
- Yes. Declare the collections and roles in the prompt or in the plan, and the generated app ships with end-user sign-in, role-aware screens, and per-operation access rules derived from that model.
- Who writes the database rules?
- Ordinary platform code, from the validated model. The language model never authors SQL or access policies, and the generated migration is linted for destructive statements before it is accepted.
- Does the exported app contain any secret keys?
- No. Data access is server-routed through platform-owned endpoints, so there is no database credential in the client bundle to leak or rotate.
- What are the limits?
- The backend surface is intentionally constrained. Custom server code, arbitrary npm packages, and model-authored SQL are not available, because none of them can be verified before publishing. That trade is the point.
- Can I take the app with me?
- The front end exports as a real Next.js App Router project with TypeScript and Tailwind, and pushes to your own GitHub repository. The data layer is managed, and a full customer-owned deployment path is still gated.