Privacy policy
Last updated 20 September 2026
This page is not finished. The operating company has not been registered yet, so its name, company number and registered office are shown in square brackets below. Everything else on this page describes how the service actually works today.
Front Counter turns a paper Menu into a digital one. This policy says what the service stores while it does that, how long it keeps it, which other companies see it, and how to have it deleted.
Who is responsible
[Registered company name] (company number [Company registration number]), registered at [Registered office address], is the data controller for Restaurant accounts and for anyone who uploads a Menu without an account.
For a diner who opens a published Menu, the Restaurant is the controller of its own Menu content and this service is its processor.
The service is run from the United Kingdom and sold to Restaurants anywhere. UK GDPR is the baseline it is built to. Where the EU GDPR applies to a Restaurant in the European Economic Area, the same rights apply and the Information Commissioner's Office (ICO) in the United Kingdom is not the only authority you may complain to: you may also go to the supervisory authority where you live or work. Nothing here reduces a protection your own country's law gives you.
Privacy questions go to contact@counteradmin.net.
What is collected
Account data
Your email address, your display name, and the Organization and Restaurant details you enter. Passwords are held by the authentication provider and are never stored or readable by this service.
Menu content
Everything you put on a Menu: Item names, descriptions, prices, Categories, Offers, opening hours, contact details, translations, dietary and allergen markers, Item photos, and your logo. This is business content, and the part you publish is public by design.
Uploaded Menu documents
When you import a Menu you upload photographs or a PDF of it. Those files are stored as private objects, readable only by your own Restaurant, and each page is sent to a model provider to be read. If your paper Menu happens to contain a person's name or a photograph of a person, that reaches the provider along with the rest of the page, so do not upload a document carrying personal information you do not want processed.
Billing data
Subscription payments run through Stripe. Card numbers never reach this service. What is stored is the Stripe customer, subscription, product, price and event identifiers needed to know which plan you are on.
Service email
Password resets, invitations and other messages the service has to send go through an email provider, which sees your address and the message. There is no marketing email unless you ask for it, and you can stop that at any time.
Technical records
Each model-assisted run records only metadata: which provider and model ran, the prompt version, a request identifier, how long it took, token counts, and a failure code if it failed. The uploaded bytes, the prompt, the raw provider response and the extracted Menu text are never written to those records. Errors are reported to the monitoring service as the error message, the route template and an operation name, with credentials and email addresses removed.
What is not collected
- Nothing from diners. A published Menu runs no analytics, loads no tag manager, and sets no cookie. Opening a Restaurant's Menu on a phone is not measured, profiled or tracked.
- No card data. Stripe holds it.
- No advertising. Your data is never sold, rented or shared with an advertising network.
- No model training. Provider requests are sent with retention switched off, so your Menu documents are not kept by the provider and are not used to train its models.
Analytics and cookies
The Restaurant workspace can use Firebase Analytics, and only there. It stays dormant until you allow it in Settings, it defaults to refused whenever the stored choice is missing, unreadable or out of date, and withdrawing consent stops collection and deletes the analytics cookies. No Restaurant identifier is stored with the consent record.
The only cookies set without a choice are the session cookies that keep you signed in. They are strictly necessary, and the service cannot work without them.
Separately, the service keeps a running count of how many times a few things happen each day: the front page is shown, a menu is scanned, a scan finishes, a preview is shown, an account is created, a Menu goes live. Each is a number and nothing else. No identifier, address, device, country or session is recorded with it, nothing is stored on your device to produce it, and no count can be traced back to you or to any visit. It is how we know whether the product is reaching anyone.
Uploading a Menu without an account
If you scan a Menu before creating an account, the upload and the Menu read from it are stored against an anonymous session so you can see the result. They are not linked to a person. If you then create an account, the work moves onto your Restaurant. If you do not, the upload and the extracted Menu are deleted automatically after a short retention window, and the deletion is not conditional on you asking.
The anonymous route is not live yet. Before it ships, the exact retention window will be stated here.
How long data is kept
| Data | Kept for |
|---|---|
| Account and Organization records | While the account is open, then deleted on request or on closure. |
| Menu content and published Menus | While the account is open. Downgrading a plan never deletes Menu content, it only limits what you can add. |
| Uploaded Menu documents and import jobs | With the import job, for the life of the account. Deleting the job or the account removes the stored files. |
| Model run metadata | With the import job. It contains no Menu text. |
| Billing records | As long as tax and accounting law requires, which is normally six years after the final payment. |
| Error reports | The monitoring provider's retention period, at most 90 days. |
Legal bases
- Contract. Running your account, storing your Menu, publishing it, and taking payment.
- Legitimate interests. Keeping the service secure, monitoring errors, preventing abuse of the upload and model endpoints, and improving the product. These are balanced against your interests, and none of them involve profiling you.
- Consent. Workspace analytics, and any marketing email. You can withdraw either at any time.
- Legal obligation. Keeping billing records.
Who else processes your data
These are the only companies that process data on this service's behalf. Each one is bound by a data processing agreement.
| Processor | What it does | Where |
|---|---|---|
| Supabase | Authentication, the application database, and file storage. | European Union |
| Cloudflare | Application hosting and content delivery. | Global edge network |
| OpenAI | Reading an uploaded Menu document, translating Menu text, and ranking Item photo options. | United States |
| Stripe | Subscription payments. Stripe, not this service, handles card details. | United States and European Union |
| Resend | Sending service email, such as a password reset or an invitation. It sees the address and the message, never your Menu content. | United States and European Union |
| Google (Firebase Analytics) | Product analytics on the Restaurant workspace only, and only after the signed-in user allows it. | United States |
| Sentry | Error monitoring. Reports carry the error and the route, never your content. | United States |
Transfers outside the United Kingdom and the European Economic Area rely on the standard contractual clauses and the UK addendum.
Security
Every private request is checked against your account, your Organization membership, your Restaurant and your role before it reads or writes anything, so one Restaurant's data is never reachable from another. Traffic uses HTTPS. Private uploads live in a separate storage bucket from published files. Model requests carry no credentials, no storage keys and no identifiers, and no model response can create, publish or activate anything without a person confirming it first.
Your rights
You can ask for a copy of your data, correct it, have it deleted, restrict or object to processing, or receive it in a portable form. Write to contact@counteradmin.net and expect an answer within one month.
If you are not satisfied with the answer, you can complain to the Information Commissioner's Office (ICO) in the United Kingdom.
Changes
When this policy changes, the date at the top changes with it. A change that affects how your data is used is announced in the workspace before it takes effect.
See also the terms of service.