The moment a site needs to remember something — a booking, an application, a member — it stops being a page and starts being software. That is where projects normally stall: you now need a database, an API, permissions and a screen to read what came in. Describing what the site collects should be enough, and here it is.
| Doing it yourself | 54 | |
|---|---|---|
| Creating the data | Design tables, write the schema | Describe what the site collects |
| Permissions | Write row level security policies | The owner reads the admin, the public only writes through the form |
| The form | Build it and wire it to the API | Created with the collection |
| Reading what arrived | Build an admin screen | It is already there |
| User accounts | Pick a provider and integrate it | Email code login, included |
Written from each product's public documentation. Products change: check theirs before you decide. No prices here for the same reason.
No. You never see it. That is the trade — you also do not get raw SQL power, and if you need that you want a real Postgres provider.
In your site's own collections, reachable only by you through the admin and by your pages through the form.
Yes, whenever you want.
The person enters their email, receives a code, and is in. Nothing to remember, no password database for you to protect.
Yes — pages that only show their content to someone who is logged in.
Yes, from the admin: read, edit, mark as reviewed, delete.
Each site's data is isolated and the admin requires being the owner. Public config goes in site variables; secrets never belong in a page, on any platform.
Limits depend on the plan and the panel shows what you are using. The number is visible before you hit it, not after.
Your pages can call any HTTP API you already have.
Describe it. The admin is part of the site, so it can be changed like everything else.