Where your app's data lives

Projects do not share a space

Each project gets its own tables. One app cannot reach another app's data, even by accident, because there is no route between them to take.

Rows are locked to their owner

Tables are not left open. Each row has an owner, and a logged-in person reads only their own rows. Without this, knowing an address would be enough to read somebody else's booking — which is why it is one of the checks before publishing.

We tested it by knocking, not by reading

We took a visitor key and sent real requests at the apps in our gallery. Across 653 tables, nothing leaked. That is a result from actually opening the door, not from reading the code and assuming.

Secrets do not go in the browser

Code that stores keys or passwords in the browser gets flagged. Those belong on the server side. If a key ends up in the files that go to visitors, publishing is blocked rather than allowed through.

Deleting really deletes, after 30 days

Press delete and the project disappears from view at once. Thirty days later the code, tables, previews and backups go with it. Within those thirty days you can still bring it back.

What the AI reads

To change your app it reads your code and your table structure. What your customers typed in is not what it works from.

Common questions

Can I collect personal details from customers? You can, and the responsibility comes with it. Collect only the fields you truly need, and mask them where they appear on screen.

Can we move our data elsewhere? You can export the whole source, and the table structure goes with it. Nothing is tied to a technology only we can run.

What about backups? Every change that lands adds a restore point. Going back takes the code and the table structure back together, not one without the other.