Privacy Policy

This policy explains what [COMPANY LEGAL NAME] ("we", "us") — the company that runs The Main Course (the "service") — does with personal data. It forms part of our Terms of Service. It is written for three readers: restaurant owners who use the service, guests who book a table through it (booked a table? section 6 is yours), and visitors to the websites it publishes.

What this policy does not cover: the websites restaurants publish through the service are the restaurants' own websites. What a restaurant puts on its site, and how it treats its own customers' information, is the restaurant's responsibility, under its own privacy notice — not ours.

1. The short version

• We collect what the service needs to build and run your website — and nothing for advertising. We have added no analytics, advertising, or tracking tools anywhere in the service, including the guest booking pages. (Some content is still loaded straight from other companies — typefaces on published pages and on the booking form, and a map where a page shows one; sections 7 and 8 say which, and what those companies receive.)
• Your restaurant's details, menus, and photos are sent to the AI providers that write your pages and generate your images. That is how the product works, and section 9 names who they are and where they operate.
• Files you upload are publicly readable at their web address, because your website has to be able to show them. Don't upload anything confidential.
• Your guests' booking details are stored for your restaurant, shown only to you and to the guest who made the booking, and never used by us to reach out to anyone. Guests' requests about their data go to the restaurant they booked with.
• We never sell personal data, and we never share it for advertising. We run no ads and send no marketing. We never see or store your card details — paying for a plan happens with our payment provider (section 9), not with us.
• Deleting a website deletes its records, including its bookings and the files you uploaded. A little survives it — section 13 says exactly what and why, and how to ask about anything else.

If the summary and a section below ever disagree, the section wins.

2. Who is responsible for what

We wear two hats, and the difference decides who answers for what:

• For restaurant owners (your account, your answers, your website, your uploads), and for the operation and security of the platform itself, we are the business responsible (the "controller").
• For guests' booking data taken by the built-in booking system, the restaurant is the business responsible (the controller) and we act on its behalf (the processor). The commitments we make to restaurants for that data are in section 17 of our Terms of Service; what we actually do with it is section 6 below. One narrow exception — the abuse check in section 6 — is our own responsibility as the platform's operator.
• For visitors to a published website, the restaurant that owns the website is responsible for it. Our role is infrastructure (section 7).

3. What we collect about restaurant owners

Your account. Your email address and password, held by our sign-in provider (Supabase); we never see or store your password ourselves. Our own records keep your email address and when the account was created.

Your answers. Everything you tell the service about your restaurant so it can build your website: name, address, opening hours, phone and email for the business, cuisine and concept, menu text, delivery areas, links to your social and review pages, notes you type (for example, notes to the logo designer), and brand colors. If you use "Import from Google", we keep the place identifier, the overall rating and review count, and the link to your Google listing — individual review texts are never stored.

Your files. Menus, photos, and logos you upload, and the images generated for your pages. These are stored at web addresses that anyone who has the address can open — your website needs to display them, so do not upload anything confidential. Hidden camera metadata (such as GPS location) is removed from photos when our full image processing runs. When it cannot run, we still remove that metadata from the most common photo format (JPEG); a file in another format, or one our tools cannot read, is stored as you uploaded it and may keep its own metadata. These are kept until the website they belong to is deleted (section 13).

Your website and its history. Every version of every page the service builds or edits for you, kept so you can undo and restore, and the messages you exchange with the builder's assistant. These are kept until the website is deleted (section 13).

Your web address, if you move its settings to us. When you connect a bare web address (a "domain" — for example yourrestaurant.com without the "www."; Terms, section 9.3), we store the copy of your domain's existing records that we showed you for review — including email records — because managing the domain requires them.

Usage records. One record per action that counts against your plan's allowances, and one per paid AI call, so allowances and abuse limits can be enforced. These are account records, not behavioral profiles.

Your plan and what you have paid. Which plan your account is on, when it changed, and what our payment provider (section 9) tells us about your subscription — that a payment succeeded or failed, and the identifiers it uses for your customer and subscription records. The card itself is typed into our payment provider's own form and never reaches us, so we hold no card number, no expiry date, and no security code. Where you give a billing address or a tax number for an invoice, that is held by the payment provider, which issues the receipt.

What we do not collect from owners: we store no payment card details, and the records our own application keeps hold no IP addresses or browser details for owners. The sign-in system records each sign-in session — including the network address and browser used — as part of keeping accounts secure, and the infrastructure providers the service runs on may keep their own technical logs (section 9).

4. What we use it for, and on what legal footing

To run the service: build and publish your website, take your bookings, enforce plan allowances and abuse limits, take payment for a plan and keep the records of it, keep the service secure, help you when you contact us, and meet legal obligations. That is the list. We do not use your data for advertising, we do not sell it, and we do not build profiles of you beyond what the features you can see on screen show you.

Where the law asks us to name a legal basis: we process owners' data to perform our contract with them (building and publishing the website, taking bookings, taking payment, support); in our legitimate interests in keeping the service secure and preventing abuse (which is also the basis for the scrambled network address in section 6); and to comply with legal obligations (which is why records of what you paid are kept for as long as tax law requires — section 13). We process guests' booking data on the restaurant's instructions, as its processor. Nothing we do rests on consent, so there is no consent to withdraw — if that ever changes, this policy will say so first.

None of this data is required by law. It is needed to provide the service: without an email address there is no account, and without your restaurant's details there is nothing to build a website from.

5. The AI providers that build your website

The service's whole point is that AI writes your pages and creates your images. Doing that sends your content to the AI providers that do the work:

• Text and page-writing — your restaurant's answers (including its name, address, phone, and hours), your menu text, your uploaded menu files and photos (which the AI reads to extract your dishes and to classify your photos), the pages being edited, the instructions and messages you type to the builder, and — if you ask for help connecting a web address — that question, including your web address, the name of the company you bought it from, and the settings we ask you to add.
• Image generation — text descriptions built from your answers (for a logo, that includes your restaurant's name and your own logo notes). Your files are not sent to the image provider; only descriptions are.

Your guests' booking data is never sent to any AI provider. The providers are named in section 9, including where they operate. We reach them through their business programming interfaces, under their standard business terms, and we ask them for nothing beyond the work described above. [WHAT THOSE TERMS SAY ABOUT USING WHAT WE SEND TO TRAIN THEIR MODELS IS TO BE CONFIRMED WITH EACH PROVIDER AND STATED HERE BEFORE THIS POLICY IS RELIED ON.] Their own policies are linked from section 9 if you want the detail.

6. Guests' booking data (built-in bookings)

When a guest books a table through the built-in booking system, we collect, on the restaurant's behalf: the guest's name, an email address or phone number (at least one, so the restaurant can reach them), party size, the time booked, and any note the guest types. The note is a free box and the form offers allergies as an example of what to put in it, so it can contain health information; it is stored with the booking, shown only to the restaurant, and used for nothing else. If a booking is later moved, the record also keeps what was first asked for — the earlier time and party size.

If you are a restaurant using built-in bookings: your guests' booking data is collected for you, and telling your guests how it is used — your own privacy notice — is your responsibility, not something this policy does for you (Terms of Service, section 17).

What we do — and deliberately do not do — with it:

• It is shown only to the restaurant, on its own booking sheet — and to the guest who made the booking, through their own private manage link. It never appears to other guests or the public. We set no cookies and use no browser storage on the booking pages, and we load no trackers there; the hosting infrastructure the pages are served through (section 9) may set its own operational cookies, which we do not control.
• One thing on the booking pages does come from another company: the typefaces. The booking form is drawn in the restaurant's own lettering so it matches the site the guest was just on, and that lettering is loaded from Google Fonts by the guest's browser, directly — which means Google receives the guest's network address, under Google's own privacy policy. It is a typeface, not a tracker, and it sets no cookie of ours; we name it because a guest reading the bullet above would reasonably expect the page to reach nobody at all.
• We never reach out to guests. The service sends no confirmation emails, no reminders, no marketing — the guest's contact details exist so the restaurant can reach them, and the guest's receipt is the on-screen confirmation code and a private manage link, shown once. (If a guest writes to us, we answer — see the end of this section; and where the law requires a notification, section 12 applies.)
• The manage link is stored only in scrambled form (a hash), so it cannot be read out of our database. Because it travels in a web address, it can appear in technical logs (section 12).
• The network address a booking comes from is used to limit abuse (too many bookings from one place) and stored only in scrambled form (a salted hash) with the booking — the raw address is not written to our database. This is an operational safeguard, not anonymization. Limiting abuse of the booking system is our own responsibility as the platform's operator (section 2), so for this one use we are the business responsible, on the basis of our legitimate interest in keeping the service secure and working.
• The restaurant's booking sheet can group past bookings by matching contact details, so the restaurant can see how often a guest has been in. This is computed when the sheet is read — no guest profile or guest account is stored — and a missed visit is only ever what the restaurant itself marked.
• Booking records are kept for the restaurant and delete with the restaurant's website (section 13). A guest cancelling marks the booking cancelled; it stays on the restaurant's sheet as its record of what was booked.
• The restaurant can delete what it holds about a guest, itself, at any time, and it chooses between two things when it does: deleting the name, email address, phone number and any note left with the booking — which leaves the booking on its sheet as a table for a number of people at a time, with nothing on it about who — or deleting those bookings outright. It can do this for one booking or for everything one guest has ever booked. Neither can be undone, and nothing anywhere keeps a copy of what was deleted. Where the details go and the booking stays, it keeps its seats, its confirmation code and the scrambled version of the guest's own manage link — so the restaurant's covers stay right, and a link the guest already has still opens a booking with nothing on it about who made it.
• A restaurant can also set a standing rule that deletes those details on any booking older than a length of time it chooses. This is off unless the restaurant turns it on, it deletes details rather than bookings, and it is carried out while the restaurant is using the service rather than at a fixed moment — so it is a rule about what is kept rather than a promise about exactly when.

If you booked a table (guests): the restaurant you booked with is responsible for your data, and requests about it — access, correction, deletion — go to the restaurant first. Asking it to delete what it holds about you is something it can do itself, straight away, without us. If you cannot reach the restaurant, contact us at [CONTACT EMAIL] and we will pass your request to it and help it respond, as its processor.

If a restaurant connects a third-party booking provider (rather than the built-in system), bookings happen on that provider's own pages under that provider's own privacy policy — that data never reaches us.

7. Visitors to published websites

Websites built with the service are published as the restaurant's own website. For visitors to those sites:

• The pages are served by our hosting provider (section 9), whose infrastructure handles every visitor request and keeps its own technical logs. We add no analytics, advertising, or tracking tools to published pages; the third-party content named in the next two bullets is loaded by the visitor's browser from those companies directly.
• Generated pages load their typefaces from Google Fonts, and pages that show a location map embed Google Maps — in each case the visitor's browser connects to Google directly, which means Google receives the visitor's network address, under its own privacy policy; an embedded map may also set Google's own cookies inside the map.
• Ready-made photographs are not one of these. The photographs the service puts on a page when a restaurant has none of its own are ours, and wherever a publish can manage it they are copied into the published website itself — so loading one reaches nobody but the site's own hosting. Where a publish could not copy one, it loads from our storage instead, which is the next point.
• Pages normally carry their own styling software and photos, but this is best-effort: a website can end up loading its styling software, on every one of its pages, from Tailwind Labs, the company that publishes it, and some images — including the picture shown when the site's link is shared in a message or on social media — from our storage. In each case the connecting browser's network address reaches that service.
• If the restaurant uses built-in bookings, the booking form on its site is served through our systems — that is section 6.

Everything else about a published website — what it says, what it links to, and the restaurant's own obligations to its visitors — is the restaurant's, under its own privacy notice.

8. Cookies and what stays in your browser

The builder — the signed-in part of the service where owners make their website — uses functional cookies only; there are no advertising or analytics cookies anywhere in the service:

The builder also keeps a few small conveniences in your browser's own storage: the web address you told us you had bought or were about to buy, a saved list of suggested website improvements and which of them you ticked, the web addresses whose email warning you have already read, whether you have been shown round the builder, whether you turned down the offer to design a logo, and display preferences such as whether times are shown as 12- or 24-hour. These stay in your browser: they are conveniences, not records — the service never treats them as the truth about your account. Each of these, like both cookies, exists only to do something you asked for, which is why we show no cookie banner.

When you look at a preview, or a small picture, of your own website inside the service, your browser loads that page's typefaces and styling software from the same companies section 7 names, exactly as a visitor's browser would.

Because the service does no tracking, there is nothing for a "Do Not Track" or Global Privacy Control browser signal to switch off; we do not respond to those signals, and no tracking happens either way.

Your guests get none of this: we set no cookies and use no browser storage at all on the booking pages. The whole service — the builder, the booking pages and published websites alike — is served through hosting infrastructure (section 9) that may set its own operational cookies for security and traffic handling, which we do not control.

9. Who receives data (our providers)

The service runs on a small number of providers. This table is the current list, and we keep it current. The rows marked (guest data) are also the subprocessor list for guests' booking data that our Terms of Service (section 17) promise: before the providers handling guests' booking data change, we tell restaurant owners — by email to the address on the account, by a prominent message inside the service, or both — so they can object.

A note about your files. Uploads and generated pictures live in storage in the United Kingdom, but they are served from a public web address so your website can show them — which means copies are also kept for a time on Cloudflare's network around the world, close to whoever is looking. Your guests' booking details are not files and are never served this way.

Beyond these providers, we disclose personal data only: when the law requires it; where necessary to enforce our Terms of Service or to establish, exercise, or defend legal claims; to protect the rights, safety, or property of the service, our users, or others; to professional advisers under confidentiality; or to a successor who takes over running the service under the same terms (Terms, sections 11.5 and 18.4). We never sell personal data — a successor receives it only to keep running the service, which can happen as part of a sale of the business itself, never as a sale of the data.

10. Where data goes in the world

Our providers operate in several countries, and using the service moves data between them: the database, sign-in and the files' home are in the United Kingdom — though the files themselves are served from a public web address, so copies of your photos, logos, menu files and the pictures we generate are also held for a time on Cloudflare's network, wherever is nearest the person asking for them; the service itself, and the hosting of published websites, run on Cloudflare's global network, which handles each request in whichever country is nearest the person making it; images are generated in the United States; and AI text requests go through a relay in the United States (OpenRouter), which passes each one on to a company running the GLM models — that company can be outside the United Kingdom and the European Economic Area, including in China, where the company that makes those models is based.

Three more things leave those countries by a different route. Checking whether a web address is free, and working out who you bought one from, sends that address to the public directories the world's domain registries keep — including registries in the United States, the United Kingdom and the Netherlands. Looking up a web address's current settings sends it to Cloudflare's public directory service. And wherever a page loads a typeface, a map, or the software it is styled with, the browser doing the looking reaches Google or Tailwind Labs in the United States directly, from wherever that browser happens to be.

Where the law requires safeguards for a transfer, we rely on [TRANSFER MECHANISM — counsel to complete per provider before publication], and you can ask us at [CONTACT EMAIL] for a copy of the safeguards that apply. Section 5 says what is and is not sent to the AI providers; guests' booking data stays with the storage and hosting providers and is never part of the AI flows.

11. What we never do

We do not sell personal data, and we do not share it for cross-context behavioral advertising (the "sharing" some US state laws regulate). We show no advertising and use no advertising or analytics trackers. We send no marketing. We never reach out to a restaurant's guests. We do not use guests' data for our own purposes beyond running and securing the service (section 6). We store no payment card details: paying for a plan happens with our payment provider (section 9), on its own form, and the card number never reaches us. What we know about your payments is which plan you are on and whether a payment succeeded (section 3).

12. How we protect data — and the limit of that promise

Protections built into the service include: guests' booking records are designed to be readable only by our own server code, not directly from a browser; third-party booking credentials are stored encrypted; guests' manage links and network addresses are stored only in scrambled form; hidden photo metadata is stripped as section 3 describes; and the sign-in system is operated by a dedicated provider. Web addresses requested from our systems — which can include a guest's manage link — can appear in technical logs kept by us or our infrastructure providers; ours are short-lived, and theirs are kept on their own schedules (section 13).

No promise of absolute security is made or should be believed — from anyone. No method of storing or transmitting data can be guaranteed secure, and we do not guarantee it. If we become aware of a breach affecting data we process for a restaurant, we tell the restaurant without undue delay (Terms, section 17); where the law requires us to notify anyone else, we do.

13. How long we keep things

Plainly: things are kept until you delete them or the thing they belong to. Nothing expires on its own. The nearest thing to an exception is a standing rule a restaurant can switch on for itself (section 6) — and that too is carried out while the restaurant is using the service rather than at a fixed moment, so it is a rule about what is kept rather than a clock.

• Your answers, pages, page history, assistant messages, domain records, your uploaded files, and your guests' bookings are kept while the website exists, and deleting the website deletes them — including every guest booking record, and including the pictures, menus and logos you uploaded and the images we generated for your pages.
• Guest details are also deletable on their own, by the restaurant, for one booking or for one guest's whole history, and by the standing rule above. Both are described in section 6. Neither can be undone.
• Deleting a website does not delete your account; closing your account (Terms, section 16) deletes your account data within 30 days, including your files in storage. Closing an account is currently done by contacting us, and completing it is a manual process on our side.
• Records of what you paid outlive all of this, because tax and accounting law requires them to be kept — typically for six years, depending on where we are established. They are records of a transaction, not of your website, and most of the detail sits with our payment provider (section 9) rather than with us.
• One thing outlives deleting a website, and this policy would rather say so than be tidy: usage records (plan and AI metering) are kept as account records and are deleted with the account (above). Your files used to outlive it too; deleting a website now removes them as part of the deletion. Copies held on the network that serves your website stay reachable for a while afterwards, because they are cached close to whoever was looking (section 10), and copies in our routine backups clear when those cycle out. If anything looks to you like it is still there, tell us at [CONTACT EMAIL].
• If the service itself closes, the data it holds is deleted (Terms, section 11.2).
• Our infrastructure providers keep their own technical logs on their own schedules, which we do not control.

14. Your rights and choices

Depending on where you live, the law may give you rights over your personal data — to see it, correct it, receive a copy you can take elsewhere, have it deleted, limit what we do with it while a question about it is resolved, object to a use of it, or complain to your data-protection authority. We honor these where the law provides them:

• Owners: some of it you can do yourself — your answers and website are editable in the service, and deleting a website or closing your account (section 13) is deletion. For anything else, including receiving a copy of your data, write to [CONTACT EMAIL].
• Guests: your restaurant is the business responsible for your booking — start there (section 6). Deleting what it holds about you is something it can do itself, in the service, without waiting on us. We help it respond, and we will pass on a request you send us.

California and some other US states give their residents similar rights. We do not sell personal information and we do not share it for cross-context behavioral advertising, we use no sensitive personal information beyond running the service, we keep things only as section 13 describes, and we never treat anyone differently for exercising a right. To exercise one, use the routes above.

The service makes no decisions about you by automated means that have legal or similarly significant effects.

15. Children

The service is for businesses and its account holders must be at least 18. It is not directed at children, and we do not knowingly collect children's data. A guest booking a table provides only the details in section 6; the booking pages are not directed at children, and if we learn we hold a child's details in a way the law does not allow, we will tell the restaurant and help it put that right.

16. Changes to this policy

If we change this policy in a way that reduces your protections or expands what we do with personal data, we tell owners at least 30 days before it takes effect — by email to the address on the account, by a prominent message inside the service, or both — the same way the Terms of Service change (Terms, section 18.5) — and because this policy forms part of the Terms, such a change carries the same right: if you do not agree, you may cancel before it takes effect. Changes that only describe the service more accurately — a provider named in section 9 changing, a new feature being described — take effect when posted, and the date at the top says when. Where our Terms require advance notice of a change (the subprocessor list for guests' booking data — Terms, section 17), that notice is always given, through the ways section 9 describes.

17. Contact

[COMPANY LEGAL NAME]
[COMPANY ADDRESS]
[COMPANY REGISTRATION NUMBER, if applicable]
Email: [CONTACT EMAIL]
[EU REPRESENTATIVE — required under GDPR Art. 27 if we have no EU establishment]
[UK REPRESENTATIVE — required under UK GDPR Art. 27 if we have no UK establishment]
[DATA PROTECTION OFFICER — only if counsel advises one is required]