Privacy Policy: FPP Kitchen
Last updated: 17 August 2026
This policy is for the people who use the FPP Kitchen app: the shop's owner and staff. It explains what the app holds about you.
It is a separate document from the customer app's policy, because it describes a different app used by different people. If you are a customer ordering food, the policy you want is the customer app's.
Who is responsible
Mahmudul Hoque is the data controller for the app itself and for the account it signs you in with. Write to m.hoque@gmail.com with any question about this policy or to exercise any of the rights below.
Flitwick Peri Peri is your employer, and decisions about your employment, including who is given access to the app, are the shop's rather than mine.
How responsibility for staff information is divided between the shop and me is not yet settled in writing. The written agreement between us covers customers' information and does not address staff. Until it does, write to me and I will deal with your request or tell you plainly who has to.
The account you sign in with
Today there is one login, shared. It is not personal to you. Its email address is currently my own, and its password is set by me and known to everyone who uses the app, including the shop. The password is stored only as a hash by the authentication service, so nobody reads it out of the database, but it is a shared secret rather than a private one.
Two things follow, and they matter more than anything else in this document:
- The app holds no email address of yours. There is nothing individual to give you a copy of, because there is no account that is yours.
- The record of what was done to an order names the account, not the person. While the login is shared it cannot say which individual acted.
When separate staff accounts are introduced, both change: your own address will be held, and actions will be attributable to you. This policy will be updated to say so at that point, and you should expect it to.
What the app holds
- Which restaurant the account is staff of, and in what role (owner or staff), with the times that record was created and last changed. This is what lets the app show that shop's orders and no other's. The account can also see the same row for colleagues at the same shop.
- A device notification token, if you allow notifications, so a new order can reach the phone in your pocket. It records the account, the device platform, the shop it belongs to, and when the device was last seen.
- A record of what was done to an order. Accepting an order, refusing one, and moving it through ready, collected, out for delivery or delivered each write an entry recording the acting account, the change, the time and any reason typed in. Pausing service or reopening the shop writes the same kind of entry. This is the audit trail behind any dispute about an order, and it is why refusing an order asks for a reason.
Taking an item off sale is not recorded against an account. It updates the menu and stores when, but not who. That is a gap in the software rather than a protection, and it is stated here so nobody relies on either reading of it.
The database can also record cancelling an order and revising a promised time, and both write the same audit entry. Neither is reachable from the app today.
The app does not collect your location, your contacts, your photos, or anything about how you use other apps. There is no analytics, no advertising and no tracking of any kind.
There is no productivity monitoring feature, and none is planned. Be aware all the same that the audit trail above is a timestamped record of actions taken, and that when individual staff accounts arrive it will be attributable to individuals. It exists to answer "what happened to this order", and it is capable of being read as a record of who did what, when.
What you can see about customers
The board does not display the customer's name or telephone number. It shows the order: its number, what was ordered, the total, the payment method and the times.
That is what the screen shows, not a restriction on what the account may read. The signed-in account has permission to read the customer's name and number, and they are printed on the kitchen ticket where a printer is installed, so that the shop can telephone about an order that has gone wrong. The customer app's policy tells customers exactly that.
Customer information you reach through the app belongs to the customer. Use it to fulfil the order and for nothing else.
Why, and on what legal basis
Signing in, keeping you signed in, and recording what was done to an order: Article 6(1)(f) UK GDPR, the legitimate interests of the shop and of its customers in the orders being handled by identified staff and in being able to establish afterwards what happened to an order. A customer who complains that an order was refused is entitled to an answer, and an audit trail is the only thing that can give one.
Notifications about new orders are part of the service rather than marketing. Your phone asks separately before any are sent, and you can withdraw that at any time in your device settings.
Who else sees it
| Who | What for | Where |
|---|---|---|
| Supabase | Stores the database and runs the service | London, United Kingdom (eu-west-2) |
| Google (Firebase Cloud Messaging) | Passes notifications towards your phone | Google's infrastructure |
| Apple (APNs) | Delivers notifications on iPhones | Apple's infrastructure |
Your information is stored in the United Kingdom. Supabase is a US company, so support and administrative access can happen from outside the UK. Notifications pass through Google and Apple; they carry the order number, the total and the fulfilment method, and never a customer's name or number. Those transfers rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses; write to me for a copy of the safeguards.
Your information is never sold, rented, or shared for anyone's marketing.
How long it is kept
The account and its staff access are kept until somebody removes them. Removal is a manual action by me. There is no screen for it, and there is no automatic deletion of anything on a schedule.
Removing staff access does not delete the account, and does not stop notifications. The notification token is separate from the staff record, and new-order alerts are sent to every token registered for the shop. Until that token is deleted as well, a phone keeps receiving them. If you stop working at the shop, say so and ask for both, and tell me if the alerts do not stop.
The record of what was done to an order stays with the order. Orders are the shop's sales records and are kept for at least six years, so the entries attached to them last as long as the order does. Removing them would destroy the audit trail they exist to be. Your name is not in those entries; the account identifier is.
Signing out
Signing out inside the app ends the session on that device. It removes nothing else, and in particular it does not stop the notifications: the token stays registered and the phone keeps receiving that shop's new-order alerts until the token is deleted.
Your rights
Under UK GDPR you can ask me to give you a copy of what is held about you, correct anything wrong, erase it, restrict or object to what is done with it, or transfer it. Write to m.hoque@gmail.com and I will respond within one month.
Two honest limits on that:
- While the login is shared there is nothing individually yours to copy, as the section above explains.
- Erasing an account that has staff access is refused until the access is removed first, deliberately, so that erasing an account cannot silently cost somebody their job's access. Where erasure would destroy the audit trail attached to an order, I will explain what can and cannot be removed rather than quietly doing half of it.
If you are unhappy with how your information has been handled, complain to the Information Commissioner's Office, ico.org.uk, 0303 123 1113. You can go to them without asking me first.
Cookies
The app is a native app. It uses no cookies or similar tracking technology.
Changes
If this policy changes I will update the date at the top. The version in force is the one published at the address you are reading this from.