Privacy notice

Who I am

Gentle Plate is run by one person - me, the developer you read about on the landing page. In data-protection terms I am the controller for everything on this page. The way to reach me is hello@gentleplate.uk, and I read everything that arrives there.

The waitlist

If you join the waitlist, I store the email address you typed, with the time it arrived and, once you click the confirm link, the time you confirmed. My database keeps the link only as a hash, so the row can recognise it without holding it. The form runs a Cloudflare Turnstile check to keep bots out, and it also keeps a small per-IP daily counter - your IP address, the date and a count - to slow down abuse; each row is deleted seven days on, and nothing links that counter to your email. The legal basis is your consent - you asked to be told when a spot opens.

That email gets used for one invite and nothing else. No newsletter, no sharing - one confirm link when you join (another if you ask again before confirming), then nothing until your invite. It sits in its own small database, kept deliberately separate from the app's diary database and outside the backups, until your invite goes out or until you ask me to take it off the list. Removal is manual and honoured: email me and I delete the row by hand.

The app itself

The app is invite-only. If you use it, it stores what you log: food entries, your settings and targets, the dishes you choose to keep (with their ingredient lines, steps, source link, note and any picture you add — pictures sit in the same provider's file storage, in a folder only your account can read), the ingredient swaps you accept or undo on a recipe (so later suggestions can lean on what you actually cook), any corrections you make to an estimate, feedback you send from Settings, and a small per-day usage count that rate-limits the estimator. Every row is keyed to your account, not your email: the database holds an account ID, and only the sign-in service knows which email it is. Signing in is a six-digit code emailed to you - no password to keep. The basis for all of it is that storing your log is the service - you asked for an account, and a food notebook that forgets your food would not be one.

The cycle features are optional and off until you turn them on. Cycle dates are sensitive, health-adjacent data, so the app only holds them because you chose to enter them - that choice is the explicit consent, and deleting them is a button, not a request. The dates themselves go no further than the diary database and its backups. One thing worked out from them does travel: the name of your current phase goes along with a recipe you import, so the suggested swaps can lean that way.

The journal is optional too, and it is the one thing here I cannot read. Notes are encrypted on your device with a passphrase that never leaves it. My database holds the scrambled result, which days have one, when each was last saved, and a small scrambled check value that lets the app tell a right passphrase from a wrong one - never the words or the passphrase. That check is also what someone holding a copy of the database could test guesses against, so the lock is as strong as the passphrase you choose. Forget the passphrase and the notes are gone for me as well as for you.

Your diary also lives in your own browser's storage, which is why the app works offline. Those copies sit on your devices, not my servers, and clearing them is in your hands.

The Android app can, if you connect it, read your daily step count, distance and exercise sessions from Health Connect on the phone. It asks Health Connect for those three things only and can read nothing else, never writes anything back, and uses them for two purposes: a day you moved more gets a slightly wider range, and the Lately page can show your steps and distance as averages by week and by month, if you keep that page on. What it reads stays on the phone - it is never sent to my server, never shared with anyone, and the app opts out of Android's cloud backup so it is never copied off the phone either. Disconnecting in Settings deletes what the app kept; the permission itself is yours to revoke in Health Connect. It is off until you turn it on, and that choice is the consent.

Network calls happen when you take the matching action: logging, estimating, scanning, sending feedback. Five honest exceptions, besides the page counter described below. Opening the app, or one of its pages, fetches what that page shows - your diary, settings, that day's journal entry, your usual meals - and checks which features are switched on. As you type a food, the app asks my server whether you've logged something like it before; nothing typed that way is kept. A save that failed offline retries quietly in the background until it lands. The app renews its sign-in token in the background. And if the app crashes, it tells me.

A crash report is the error message, the stack trace (anything in quotes is stripped from the message and from the top line of the trace on the way in, which is where typed food ends up) and your browser's user-agent string - browser, version, operating system and, on Android, the phone model. When a failure has a known cause, a short row also lands in a table so I can count how often it happens: a one-word code, the time, which part of the app it came from, the same user-agent string, a few short technical values - a status code, a timing, how the AI's reply ended - and a scrambled version of your email. A weekly job clears anything older than 90 days, and the encrypted backups described below can hold a row for up to 30 days more.

Who else touches data, by name

• Cloudflare hosts the site, runs the Turnstile bot check on the waitlist form, and keeps the waitlist itself. It also pools the app's connection to the diary database, so diary rows pass through Cloudflare on their way to and from Supabase. Requests pass through Cloudflare's network the way they do for any site it hosts, and its edge keeps standard HTTP request logs. Since September 2026 it also counts page views here and inside the app, so I can tell whether anyone is finding this. It sets no cookies and keeps nothing on your device - no way to recognise you on a second visit, and no way to follow you anywhere else. I see totals, not people.
• Supabase runs the sign-in and the diary database, in London, the same project that holds your account. It has your email address, its own record of your sign-ins, the diary itself, and the journal in a form it cannot read.
• Resend delivers the sign-in code, the welcome email when I invite you, and the confirm link when you join the waitlist. The first time you confirm, it also carries one note to me saying your address confirmed, so I know to send the invite. On the plan I use it keeps a copy of each email for 30 days.
• OpenRouter, and the AI model providers it routes to, see your food text or photo when you use the estimator, and a recipe's ingredients (or your screenshots of it) when you import one - along with the foods you've told the app to avoid, whether you eat gluten-free and, if the cycle features are on, which phase you're in. Only then. Routing is restricted to providers OpenRouter classifies as zero-data-retention, i.e. ones that do not keep prompts or completions after serving the request. No name, no email, and nothing linking one estimate to the next travels with it.
• Open Food Facts receives the digits of a barcode you scan - just the digits, with no identity attached.
• GitHub holds a weekly backup of the app's diary database (never the waitlist) as an expiring attachment to the backup run in the project's private repository - never committed to the code itself. Since 14 August 2026 each backup is encrypted before upload with a key only I hold and expires after 30 days; the last unencrypted ones expire on a 90-day clock, all gone by mid-November 2026. Separately, a weekly job collects food names the app's food index failed to match - name, a count, a last-logged date, pooled across everyone with no names or emails attached - into the private repository so I can teach the index real misses; that list doesn't expire.

One more, of your choosing: paste a recipe link and my server fetches that page for you - the recipe site sees a request from the server, never from you. And the tip jar on the front page is a Stripe page: nothing here loads from Stripe or talks to it, but if you tip, Stripe takes your card and email on its own site under its own notice, and I see the amount and the email you gave them. That is the whole list. There is no advertising and there are no tracking scripts on this site or in the app. The only third-party code either one loads is Cloudflare's - the Turnstile check on the form, and, since September 2026, the page counter described above. Both come from Cloudflare, who already host all of this.

Your rights

Export and deletion are buttons in the app's Settings, not a support ticket. Export gives you one JSON file holding everything the database keeps under your account, the journal included, still encrypted. Deletion is immediate and total: type the word and every diary row goes in one atomic batch, then your sign-in record at Supabase; if the second step fails you are told, and a retry finishes it. This device is signed out as part of it, and another device that is still signed in cannot save to the deleted account: every diary row points at the sign-in record, and that record is gone.

Five honest limits on deletion, stated rather than implied away: backup files keep deleted rows until they expire on the schedule above, Resend keeps its copy of any email it carried for up to 30 days, the copies in your own devices' browsers are yours to clear, and the failure rows described earlier are tied to a scrambled email, not your account, so they are in neither the export nor the delete - they leave on the weekly 90-day clear. And food names already pooled into the index-miss list stay in that list's history, with nothing tying them to you. Restoring from a backup is a manual, ask-me affair - no automation ever writes one back.

You also have the usual UK GDPR rights - access, correction, erasure, portability, objection - and for anything the buttons don't cover, email me and I'll do it by hand. Waitlist removal works the same way.

Complaints

If you think I've got something wrong with your data, complain to me first at hello@gentleplate.uk. UK law (the Data (Use and Access) Act, in force since June 2026) gives you that route and obliges me to acknowledge your complaint within 30 days and answer it without undue delay. I intend to be considerably faster than that.

If my answer doesn't satisfy you, the Information Commissioner's Office is at ico.org.uk and you can go to them at any time.

When this page changes

If what the app does with data changes, this page changes in the same release, with a new date at the top. It never claims more than the code does.