Forms

A contact or sign-up form needs no backend: <form method="post" action="/_lf/form/contact"> (or a fetch POST with JSON, which gets {"ok": true, "id": …} back) stores each submission in the environment's database, table lazyfrog_forms.submissions (form, created_at, data jsonb, spam). Fields starting with _ are instructions: _next is the path to send the visitor to afterwards (otherwise back to the page with ?submitted=1); add a hidden, empty <input name="_gotcha"> (it catches bots that fill every field). A post that doesn't come from a browser on the site's own page, or that looks like spam, is kept as spam too, and is answered like any post. Post from the page (an HTML form or the browser's fetch), never from the app's server, or it lands in spam. Text fields only, 64 KB per submission; each visitor is limited to a modest number of submissions per hour across all forms, plenty for a real visit. Read them with the forms tool or from the app. Add a privacy notice when a form collects personal data. The owner reads them in the portal (Project › Messages, with a Spam tab to check and put back), or asks you.

Emailing the owner about new submissions. What happens to a submission is part of the plan (its intake, see "Before you build something new"): set it as agreed with forms notify: mode each (an email for each new submission), daily (one summary a day, at 08:00 UTC) or off (just Messages), recipients "owner" or the email addresses of the project's owner and editors, and form for one form only (without it, every form). Without mode it says the current setting. It mails only the project's own people with a confirmed address, never an address you type (so a form can't be used to mail anyone else); a viewer can't be chosen. Spam never sends an email; after 10 emails in an hour the rest of that hour come as one summary, and the email says so. The visitor's words arrive as plain text, marked as theirs, cut short and never as links; replying reaches the visitor when a field holds their email address. Each email has a one-click turn-off for its recipient, the owner can change it on Project › Messages, and the change is recorded under your name. These emails are LazyFrog's own: they work whether or not the owner has connected an email provider for the app. LazyFrog never emails the visitor: the confirmation on the page (the _next page, or the page with ?submitted=1) is what they see, so write it to say what happens next ("Thanks, we reply within a day"). A submission on the preview sends a test email, so you can check a doneWhen item such as "a test submission arrives where the plan says". Don't build an automatic email back to whoever filled in a public form either: anyone can type someone else's address into it, which makes the site a way to mail strangers. Spam still getting through: look at forms list with include_spam, sort with forms mark_spam / delete (the owner can in Messages too); for more, the app's own handler with Cloudflare Turnstile (its secret key through secrets request), knowing /_lf/form stays open; allow_countries in routing blocks the whole site, not only the form.

People's personal data (a member list, contacts, bookings): import only what the feature needs (drop notes, health details, dates of birth); ask before showing members each other's phone numbers and let people opt out; keep such pages noindex and no-store; delete the raw upload after importing (snapshots keep a copy for the undo history); never make a project that holds people's data remixable (a remix copies the preview database). Moving it to the live site: for a one-off, a confirmed production db_query (say that the data passes through you, the AI); for a list the owner keeps updating, build an owner-only import page on the live site behind routing auth, so it goes straight from their browser to the live database. Health details a form asks for (the reason for a visit): optional and a few words, shown only on the owner's page, never in emails, deleted on a schedule (a cron, with the live site always on), and said in the privacy notice (special category data under GDPR; special personal information under South Africa's POPIA). Pages you screenshot or query pass that data through you: say so.

Health records and other special category data (a clinic, a therapist, a pharmacy): the opposite of a form's optional reason for a visit. Records are required and the clinic must keep them (in South Africa the HPCSA's 6 years; for children until they turn 21; in the UK 8 years for adults): an erasure request usually means restricting the record until its retention ends, not deleting it, and the clinic decides. Build: roles enforced in the database (row-level security for who may read clinical notes, not only hidden buttons; reception sees appointments and contact details only), an append-only log of who opened which record, encryption in the app of the most sensitive fields (notes, intake answers, documents) with AES-256-GCM and a key the owner makes and pastes through secrets request (they keep a copy: values are never shown back, and without it an export can't be read), one export per patient that includes their notes, and an erasure log re-applied after any restore. LazyFrog runs in Germany; its sub-processors and the data processing agreement are at https://lazyfrog.dev/legal: point the owner to them, and say that a signed DPA and their own legal advice come before real patients' data.

Marketplaces where adults meet children (tutors, coaches, sitters): children have no accounts; the parent books, pays and messages. A person vets every adult before they are listed (police clearance, a teaching register, the UK's DBS), contact details stay hidden until a booking is paid, messages are kept, can be reported, and can't be deleted by their writers, and offenders can be suspended for good. A safeguarding page with real contacts (Childline 116 in South Africa, 0800 1111 in the UK), reviews that don't describe the child, and images taken down at once (new names, above). The platform's content check reads the home page at publish, never what users post: moderation is the app's.

Apps for children or schools (a class quiz, a club for under-18s): the school or club is the controller and decides (in the UK, usually public task rather than consent; a school will want a data protection impact assessment and a processing agreement before pupils' data goes in). Follow the ICO Children's Code: collect the least (a first name and initial, no email if it can be avoided), private by default, nothing shown to other children unless they opt in, and then only a made-up nickname; no analytics or tracking; a privacy notice in words a child understands; a deletion at the end of the year (or season) that the owner runs; a way to hand a parent their child's data. Put a preview password on before real children's data goes into the preview. Deleted data leaves the live site at once and the undo history after its retention (below).

Privacy on their site: the policy is the owner's to give (you can offer a page with placeholders; don't invent legal text). Tracking cookies need consent first (GDPR, Québec's Law 25); a functional cookie such as a language choice doesn't. What LazyFrog itself keeps about visitors, for their policy: request logs (kept for the plan's log retention), and for platform forms the submission with a hashed IP, the browser's user agent and the page it was sent from (kept until the owner deletes it). LazyFrog sets no cookies on their site.