Data & Privacy
This page is maintained by the operator of The Solution to explain, in plain language, where each type of your data is stored and how one cafe's data is kept separate from another. It describes current app-visible controls and is not an independent certification.
Where your data lives
All server-side data is stored in Lovable Cloud, a managed Postgres backend. Card details and invoices are held by Stripe, our Merchant of Record. Devices additionally keep a local cache so the POS works offline.
Data map
| Category | Examples | Where it's stored | How it's isolated |
|---|---|---|---|
| Operational business data | Menus, categories, modifiers, inventory items & stock counts, deliveries, stock takes, sales, tickets, held orders, receipts, staff list, timesheets, settings | Lovable Cloud (managed Postgres), in the kops_state table as JSON keyed per cafe (e.g. cafe:<id>:menu, cafe:<id>:inv, cafe:<id>:sales). | Namespaced by cafe id. The active cafe id gates every read/write from the app. A cached copy also lives in the browser's localStorage on each device so the POS keeps working offline, then syncs back. |
| User accounts & authentication | Email, password hash, TOTP 2FA factors, active sessions, trusted-device tokens | Managed Auth service in Lovable Cloud. | Each user only ever sees their own account. Passwords are hashed by the auth service; we never see them. |
| User profile | Display name, email linked to your login | profiles table in Lovable Cloud. | Row-level security: a signed-in user can only read/update their own profile row (auth.uid() = id). |
| 2FA backup codes | Recovery codes generated during 2FA setup | mfa_backup_codes table in Lovable Cloud. | Stored as SHA-256 hashes — never in plain text. Row-level security scopes rows to the owning user. |
| Subscription & billing state | Plan, status, current period, Stripe customer/subscription IDs, environment (live/sandbox) | subscriptions table in Lovable Cloud. | Row-level security scopes each row to the owning user. Card numbers and invoices are held by Stripe (our Merchant of Record) — we do not store card details. |
| Free-access allowlist | Emails granted free access (e.g. the owner account) | free_access_emails table in Lovable Cloud. | A signed-in user can only check whether their own email is on the list; they cannot enumerate other entries. |
| Staff PINs & access levels | Staff, Supervisor, Manager PINs per cafe | Stored inside the cafe's kops_state entry (cafe:<id>:staff) in Lovable Cloud, plus a mirrored copy in the device's localStorage for offline PIN checks. | Scoped to the specific cafe id. Refunds and deletes require an on-device Supervisor/Manager PIN in addition to the signed-in user. |
| Kitchen / Bar screens | Ticket states (ordered → preparing → ready → cleared) | Broadcast in real time through Lovable Cloud realtime channels; ticket rows live in kops_state. | Channels are scoped per cafe id. |
| Supplier invoices & imports | Uploaded invoice/CSV/XLSX files parsed for prices, stock and menu imports | Parsed on the server, results written into the active cafe's inventory/menu entries in kops_state. Raw uploaded files are not permanently stored unless you attach them. | Parsed data lands only in the cafe you were signed into at the time. |
| Weather data | Met Office forecast/observation snapshots used for forecasting | kops_state, keyed by cafe and location. | Read-only reference data attached to the cafe that requested it. |
| Secrets & API keys | Stripe API keys, Met Office API key, service role key, webhook secrets | Server-side secret vault in Lovable Cloud. | Only ever read inside server functions. Never sent to the browser, never embedded in the app bundle. |
| On-device cache | Offline POS queue, last-known menu/inventory, remembered device token, active cafe id | The browser's localStorage on that specific device. | Scoped to the browser + domain. Signing out clears the session; clearing site data removes the offline cache. |
How cafes are kept separate
- Every operational record is written under a key that includes the cafe id (for example
cafe:<id>:sales). - The app reads and writes using the currently-active cafe id, so a device signed into Cafe A can't see Cafe B's tickets, stock or sales.
- Kitchen and Bar screens subscribe to realtime channels scoped per cafe id.
- Multi-location owners see aggregated views in the Owner Console; that view loads each cafe's data separately rather than merging it in the database.
How users are kept separate
- Row-level security is enabled on user-owned tables (profiles, backup codes, subscriptions) — each signed-in user only sees their own rows.
- Passwords are hashed by the managed auth service; we never store or see them.
- 2FA backup codes are stored as SHA-256 hashes and can only be used once.
- Refunds, deletes and other sensitive POS actions require an on-device Supervisor or Manager PIN in addition to the signed-in user.
What we don't store
- Card numbers, CVCs or full PAN — these stay with Stripe.
- Your passwords in readable form — only a hash held by the auth service.
- Plain-text 2FA backup codes — only their hashes.
Your controls
- Export your data any time from Cloud → Advanced settings → Export data (owner account).
- Manage or cancel your subscription from the Billing settings page.
- Manage 2FA factors, trusted devices and backup codes from Billing.
- To delete your account and associated data, contact support from the FAQ page.
This page describes current, app-visible controls. It is not an independent audit, certification or legal notice. See our Privacy Notice and Terms for the legal detail.