Worldwide pre-launch service
Privacy notice
Version 1.1 · Effective 28 July 2026
Launch dependency: the production addresses are dinner-picker.com, app.dinner-picker.com and admin.dinner-picker.com. The operator’s durable public email and postal contact still need to be added before inviting restaurants or shoppers to submit personal information at scale. During design-partner work, you can exercise your choices through your connected in-app conversation.
Who is responsible
The Dinner Picker pre-launch project decides why and how the personal information described here is used. It is the data controller for account, restaurant relationship, directory and service-analytics information. The operator’s complete legal identity and contact address will be published before the public launch gate.
Information we use
- Account and relationship details, including name, email address, telephone number, country or region, postal code, role, restaurant and sign-in history.
- Restaurant listing content, ownership claims, verification evidence, opening hours, services, structured menu items, prices, allergen information, offers and the person responsible for accuracy.
- Food-order records, including basket snapshots, customer contact and fulfilment details, restaurant instructions, totals, status history and payment-provider references. Dinner Picker does not receive card numbers or security codes.
- Connected support messages, private operational notes, approval decisions and audit records.
- Communication choices, consent records, objections and the minimum suppression record needed to respect a do-not-contact request.
- Service activity such as profile views, menu views, basket and checkout starts, call selections, QR source, campaign, session identifier, approximate country inferred from network headers, IP/security logs and basic device information.
Sources and purposes
Information comes from you, an authorised restaurant representative, service activity, public business sources and directory datasets such as OpenStreetMap or official food-business records. A public listing is not treated as owner-verified until the approval workflow is complete.
| Purpose | Legal basis |
|---|---|
| Create accounts, process claims, publish approved listings and provide connected support. | Taking steps at your request and performing the service agreement. |
| Create and transmit food orders, show order status and connect the customer to the restaurant’s direct payment account. | Taking steps requested by the customer and performing the ordering service; the restaurant separately performs the food-sale contract. |
| Keep the directory accurate, review content, prevent abuse, secure the service and maintain an audit trail. | Legitimate interests in running a reliable and secure directory; legal obligations where applicable. |
| Measure profile, menu, basket, checkout, call and QR activity and improve the product. | Legitimate interests in understanding whether the service is useful, using proportionate event data. |
| Send optional product or promotional communications. | Consent where required, or a documented lawful business-marketing route. You can object at any time. |
Contact preferences and objections
Account holders can separately allow marketing by email or telephone and can enable do not contact for marketing in account settings. Administrators see the same durable suppression status in the connected CRM. A suppression choice switches off optional marketing but does not prevent essential security, claim, approval or support messages.
You can object to direct marketing at any time. Use account settings, the in-app conversation, or reply to any communication with “no thanks”. We retain a minimal suppression record so the objection is not accidentally lost during a later import.
Sharing and international access
We use service providers for hosting, databases, security, application delivery and payment interfaces. Order and customer details are shared with the selected restaurant so it can fulfil the order. Stripe processes payment details and the direct restaurant charge under its own terms; card details entered into Stripe’s embedded component do not pass through Dinner Picker servers. We do not sell personal information or use solely automated decisions that have legal or similarly significant effects.
Retention
- Active account, listing and connected-message records are kept while the relationship continues and normally for up to 24 months after closure.
- Food-order and payment-reference records may be retained for up to six years where needed for contracts, accounting, fraud prevention or legal claims; card data is retained by the payment provider, not Dinner Picker.
- Event analytics are normally kept for up to 24 months before deletion or aggregation.
- Unconverted prospect records are reviewed or removed within 12 months of their last verification or meaningful contact.
- Approval and security audit records may be kept for up to six years where needed to establish what was authorised or published.
- Minimal do-not-contact suppression records are retained while needed to honour the objection.
Your rights
Depending on the circumstances, you can ask for access, correction, deletion, restriction, portability, or object to processing. Where processing relies on consent, you can withdraw it without affecting earlier lawful use. We may need to verify identity before acting on a request.
If a concern is not resolved, you can complain to the data-protection or privacy regulator that applies in your location. The operator’s complete regulatory contact details will be published before broad onboarding.
Cookies and local storage
The current service uses a strictly necessary signed session cookie for account/admin access and browser storage for search location, country preference, session attribution, PWA support and interface preferences. The pre-launch build does not use advertising cookies. We will update this notice and add any required consent control before introducing non-essential tracking.
Changes
Material changes will be dated here and, where appropriate, communicated in the connected inbox. The operator identity, durable contact details and final domain must be completed before the real-data launch gate can pass.