A waitlist is a table. A product backend is a later decision.

The page looks finished, then someone asks where the emails go. That question is how a static demo grows a database server it does not need yet.

What people are actually storing

Watch the first data feature in an AI-built UI. It is rarely a product. It is a list.

• email addresses for a waitlist
• a name and a note from a contact form
• scores, votes, or a short log of what someone typed

Each of those is a table with a handful of fields. A row has an id. A field is a string, a number, a boolean, a date, or a small JSON blob. You want to insert a row from the page, and you want to list the rows later from a dashboard or from the page itself. You do not yet want accounts, permissions per user, file storage, or a private API.

Agents reach for Firebase, Supabase, or a new Express server because those names appear next to the word “backend” in their training data. They work. They also introduce a project, a set of keys, a console, and a bill for a job that is “append one email.”

The line

Use a plain table while all of these stay true:

1. Every visitor can be trusted with the same write. You are collecting public signups, not storing one person’s private records.
2. The shape of a row is stable and small. You can write the fields down before you write the form.
3. Losing fancy queries would not hurt. You need “save this” and “show me the rows,” not joins across ten services.
4. The schema changes from a tool you control, not from code running in the visitor’s browser.

Move to a real backend when any of these show up:

• People sign in, and one person must not see another person’s rows.
• You accept files, payments, or anything you cannot put in a short text field.
• You need server-side secrets to call another API on the visitor’s behalf.
• The rules for a valid row are too important to leave only in the browser.

That second list is a product. The first list is a form with memory. Building the product early feels like progress. It usually delays the moment someone can type an email into the live page.

How the table should be shaped

Write the schema down as data, then apply it. A waitlist is enough of an example:

• email, string, required, unique
• name, string, optional

Names in lowercase, with underscores if you need more than one word. Mark unique only where a duplicate would be a mistake, such as the same email twice. Leave everything else optional until the form truly requires it. A strict schema on day one is how a slightly different form starts failing for reasons the visitor cannot see.

The browser should be able to insert, list, update, and remove rows. It should not be able to invent a new table or add a column. If the page can change the schema, then anyone who can open the page can change the schema. Keep that power in the terminal or the dashboard, where an account token is required.

The waitlist does not get better because it runs on infrastructure you could use for a bank. It gets better when a real person can submit it, and you can read the row tomorrow without starting your laptop’s database.