Table privacy policy

Table plans meals for a real household. That means it holds unusually personal things: the names of the people you feed, their food allergies — often a child's — what is in your fridge, and, when you talk to Sous, the sound of your kitchen. This page says exactly what the app does with all of that, in plain language. Where a promise has a limit, the limit is stated.

The short version

• Work happens on your phone wherever it can. Planning, allergy screening, your shopping list and your pantry all run there with no network at all. Only three things need outside help — holding a conversation with Sous (typed, spoken, or while you cook), reading a photograph, and importing a recipe from a link. Each sends data to servers — ours and our providers' — and this page lists every one of those flows and exactly what each recipient gets.
• Everything about your household lives on your phone. There are no accounts, and we run no database. Nothing about you is stored on our servers today, and if we ever ask to keep something — to teach the app to read your fridge better — it will be opt-in, off until you turn it on, and described before it starts.
• Before anything leaves your phone, identities are stripped. The app never sends a name, an age, a per-person allergy record, a ZIP code or a health goal. What does cross is content — your questions, your pantry, your plan's dish names, your photos, your voice — exactly as you wrote or spoke it, so a name you put in a question yourself does travel.
• Today there are no ads, no analytics, no tracking and no crash reporting, and nothing about how you use the app is reported to anyone. That is a description of the app as it stands, not a promise about every future version — but the limits below are promises: analytics will always be off until you turn them on, and any advertising would be chosen by what is on the screen, never targeted using what this app knows about you.

What does the app know about me?

Whatever you tell it: the people in your household with their names, age bands, allergies, diets, dislikes and favorite cuisines; your ZIP code and health goal if you entered them; your week's meal plan; your pantry; your shopping lists and shops; recipes you save or import; your cook log and streak. All of it is stored only on your phone, in the app's private storage, protected the way iOS protects app data generally (we add no encryption of our own on top).

What leaves my phone, and who gets it?

If the phone can do it, the phone does it. That is the rule the app is built to, not a happy accident: planning your week, building and merging the shopping list, screening every recipe against your allergies, working out what a dish costs, matching what a photo scan found against the ingredient list (the scan itself is one of the three flows below) — all of it runs on your phone, with no network involved. Turn on airplane mode and the app still plans your week, still writes your list, still keeps you safe. The limit is dish photos, which come from the image libraries described below: the app fetches this week's ahead of time, while you have a connection, so the meals you are cooking keep their pictures, and a photo the phone does not already hold shows as a placeholder tile until you are back online.

Three things need outside help, and they are the only reasons anything leaves. Two of them — holding a conversation with Sous (typed, spoken, or while you cook) and understanding a photograph — genuinely cannot be done on the phone: they need models too large to live in an app. The third, importing a recipe from a link, goes through our server so the website sees a request from us rather than from your phone, and a model is involved only when the page carries no machine-readable recipe.

New features are held to the same rule — where the work can be done on the phone, it is, even when sending it away would be easier to build.

Beyond fetching recipe photos (described below), nothing leaves until you use one of them. When you do, the request goes to our own server first (it holds the vendor keys so the app doesn't have to), and from there to the provider doing the work. Our server holds each request in memory only for as long as it takes to answer it; the little that outlives a request — its logs, and a per-install pseudonym — is under "Do you keep any of it?" below.

When you ask Sous a question (typing): your question, your pantry as a list of ingredient names, your plan as dish names and dates, and a stripped summary of your household — how many people, and the combined set of allergies and diets present among them — go to our server and then to Anthropic (the company behind the Claude models) to compose the answer. The summary is deliberately blank about who is who: every member is reduced to "Member 1", "Member 2", with the identical combined allergy list, so there is no per-person record to accumulate anywhere. When Sous's reply mentions "Member 2", your phone swaps the real name back in before you see it; the name itself never travelled. A few kitchen facts (your appliance list, time budget, priorities, avoided cuisines) ride along to our server but are not put into the prompt, so they stop there. Each question is self-contained — no conversation history is kept or re-sent on the text path.

When you cook with the assistant: the cook session — the recipe steps, titles, timers and scaled ingredient lines of the dishes you are cooking — goes to our server and then to Anthropic on each turn. For a recipe you imported yourself, this is where its text leaves your phone — this, and a voice session opened while you cook, which reads the same steps and amounts so Sous can speak them (see the voice section below).

When you photograph your fridge, a dish, or a recipe: see the photo section below.

When you import a recipe from a link: the link goes to our server, which fetches the page on your behalf — so the website sees a request from our server, not from your phone. If the page carries no machine-readable recipe, its text is sent to Anthropic to extract one. For TikTok links, the video's public caption is fetched through TikTok's own embed service.

When you talk to Sous: see the voice section below.

When you browse recipes: the catalog's dish photos are not packed into the app. Your phone fetches each one directly from the image library that hosts it — Unsplash, Pexels, Flickr or Wikimedia — when you look at a recipe, and the current plan's photos ahead of time, as described above. As with any image on any web page, the host sees your IP address and which photos your phone asked for, and nothing else: no name, no household, nothing you typed. Photos are cached on the device after the first fetch, and none of this touches our server.

What each provider is, in one line — each name links to its privacy policy, which governs what it keeps: our relay server runs on Fly.io; Anthropic composes Sous's answers and reads photos; Deepgram turns your speech into text; LiveKit carries the voice call, and its inference service runs the xAI (Grok) voice that speaks Sous's replies; recipe photos come straight from the image libraries that host them, as above. That is the complete list. A grocery-ordering integration (Kroger) exists in the code but is switched off, and no shipped build can switch it on.

Who can hear my kitchen, and when?

The microphone is off until you tap the microphone button. Tapping it asks iOS for permission, then opens a live voice session. While that session is open:

• Deepgram receives your raw audio, continuously, to turn speech into text. We set Deepgram's model-improvement opt-out on every request, so your audio is not used to train their models. An opt-out is not the same as zero retention — Deepgram's own retention policy governs how long they hold audio.
• LiveKit carries the call, so it handles the audio in both directions, the live transcripts, and the data the assistant requests mid-call — your full pantry list when you ask what you have, the steps and ingredient amounts of the dish you are cooking, or what this week's plan still needs bought. Our session tokens grant no recording permission (this is pinned by an automated test), and LiveKit's own session-capture feature is switched off on our project.
• Anthropic receives the conversation transcript to decide what Sous says. Unlike the text path, a voice conversation re-sends what was said so far on each turn — so if you speak a name aloud, it stays in that session's transcript. The app never sends a name; it cannot un-say one you speak.
• xAI (Grok), reached through LiveKit's inference service, receives the text of each reply to synthesize the voice you hear.

The session ends — and all of that stops — when you tap the microphone off, when you leave the screen you started it on (with about a second and a half of grace so Sous can finish her sentence), when the assistant drops, or when the app leaves the foreground: Table requests no background-audio capability, so iOS cuts its microphone access when it is not the app in front of you. Muting stops your audio from being transmitted; on current builds it also shuts off the microphone hardware, and iOS's own orange-dot indicator is the honest signal either way.

One more voice fact worth knowing: the read-aloud toggle on the Ask screen is different — it uses your iPhone's built-in speech, on the device, so a reply containing a real name can be spoken without anything crossing the network.

What happens to a photo of my fridge?

When you photograph your fridge, pantry, a dish, or a recipe page, the photo goes to our server, which converts its format in memory if needed and passes it to Anthropic, whose model reads it. Our server never writes the photo to disk and keeps no copy; its logs record that a photo call happened and how large it was, not the image. Today we have nowhere to keep your photo, and we don't.

Anthropic holds it under its own API data policies — Anthropic does not train on API data by default, and its retention terms, not ours, govern how long the photo exists there. A photo of your fridge is a photo of the inside of your home; if you are not comfortable with it crossing the network, type the items in instead — every photo feature has a typed alternative.

Do you keep any of it?

Today, no. Our server stores nothing about you: no database, no files, no accounts. Two things do outlive a request:

• Server logs. Our server logs that a request happened: which feature, when, how large, how long it took, and a per-install pseudonym (below). When you import a recipe by link, the link itself is logged. When a request fails unexpectedly, the raw error is logged, and a provider's error message can quote fragments of what was being processed. That is the one path by which request content can reach a log. Logs are otherwise text about requests, never the requests themselves: no photos, no audio, no names. They are held by our hosting provider for 7 days — Fly's default — and we have added nothing that would extend it.
• The install pseudonym. On first launch the app makes up a random ID for itself (it looks like inst_…) and sends it with each request so our server can rate-limit one phone without throttling everyone else. It is not your name, is connected to no account, and cannot be resolved to a person. It is a stable identifier for your install, and it appears in our logs. Deleting the app destroys it; a reinstall gets a fresh one.

If we ever ask to keep more

The app is meant to get better at reading your fridge, and the honest way to do that is to learn from where it was wrong. That needs examples, and examples mean keeping something. These are the limits.

Nothing changes without you turning it on. Any such sharing is opt-in and off by default. Not on-by-default with a switch to find; not a prompt worded so that yes is the easy answer.

What we would ask for, specifically. When you photograph a shelf and the app guesses wrong, your correction is already written down on your phone — the app read "oat milk", you changed it to yoghurt. Three fields: the text the app was working from, what it guessed, and what you picked. The last two hundred of them, newest first. That log is the whole ask — nothing else from the confirm card, and no picture: the photograph is not part of it and never leaves your phone.

Photographs would be a separate question with its own switch. If keeping the images ever proved necessary, it would be asked for on its own terms — never folded into a general "help improve Table" toggle.

Turning it off stops it, and what was already shared can be deleted. Ask us and we will remove it; there is no account to hunt through. The log on your phone is capped and self-clearing either way — the oldest entries drop off — and deleting the app destroys it.

It is for making the app work better and for nothing else. Not advertising, not sold, not shared with brokers, not used to build a profile of your household.

Until you see a switch in Settings and choose to turn it on, the paragraphs above this one are the whole truth: nothing is collected, and the only things the server keeps are the two described in the next section.

What our providers keep is governed by their policies, not ours. We have set every no-training and no-logging switch those services offer, but we do not control how long they hold what we send, and their terms change without us. Rather than restate numbers here that could go stale, each provider's name in the one-line list under "What leaves my phone, and who gets it?" links to its policy; what each one receives is described at the flow that sends it.

What never leaves my phone?

Under any configuration of the app, the app never sends any of these — what you type or speak yourself is content, and travels as you said it:

• Real names, and the map that connects "Member 2" back to a person
• Who has which allergy — only the combined, unattributed set leaves
• Age bands, dislikes, and favorite cuisines
• Your ZIP code and your health goal
• Your cook log, streak, declined meals and collections
• The on-device correction log, described above under "If we ever ask to keep more" — capped, local, and uploaded nowhere

What about my child's allergy?

Table is built for a household, and household members are often children. Their information is entered by whoever set the phone up — the app has no child-facing sign-up, no accounts, no messaging and no ads. A child's name, age band and personal allergy record stay on the phone, full stop. What leaves, when you use Sous, is the household's combined allergy list with no name or age attached — because a dinner suggestion that ignores an allergy is unsafe, and one that names your child is a disclosure. The allergy verdicts you see in the app ("contains peanut — not safe for Mia") are computed by rule-based code on the phone; no AI model and no server is asked to make a safety call about a named person.

A guardian gate, on by default in Settings, requires an extra confirmation before actions that leave the app — ordering link-outs and grocery sign-ins — so a teenager cooking alone can use the kitchen features without reaching the parts that spend money or leave the sandbox.

Do you track me?

No. There are no ads, no third-party analytics, no tracking SDKs and no crash reporting in the app you are running. Nothing about your usage — which screens you open, what you cook, how often — is reported to us or to anyone. The analytics layer in the code is switched to "do nothing", and no shipping build contains a vendor that could receive an event. We cannot see how you use Table.

If that ever changes

Table may add optional analytics, and a free tier may one day carry advertising. Neither exists today. If either arrives, it arrives under these rules, and this page will be updated and dated before it does — not after.

Analytics would be opt-in, and off until you turn it on. Not on-by-default with a switch to find, not a prompt that assumes yes. If you never open Settings, nothing about your usage is ever collected. Turning it off later stops collection from that moment.

Advertising would not be targeted at you. If a free tier ever carries ads, they would be chosen by what is on the screen — a recipe, an ingredient — and not by who you are or what we know about you. Nothing this app holds would be used to aim them: not your allergies or your family's, not your photographs, not your voice or anything said in your kitchen, not your pantry, not what you cook, not your children's data. Those exist so the app can cook with you safely.

That rules out behavioural advertising and the ad networks built on it, which is the practical meaning of this promise rather than a caveat to it.

We do not sell your data, and we would not. Not to brokers, not to advertisers, not as part of an "anonymised" dataset — a household's allergies and a fortnight of dinners are not anonymous in any way that survives contact with other data.

If advertising ever involved tracking you across other companies' apps and sites, iOS would ask you first. That is Apple's App Tracking Transparency prompt, it is not ours to skip, and "allow" would be a real question with a real "no".

Nothing here is a plan with a date on it. It is the shape of what we would and would not do.

Can I delete it?

Yes, completely, yourself: delete the app. Everything it knows — household, plan, pantry, recipes, cook log, corrections, any recipe shared into it and its install pseudonym — lives in the app's own storage and its share container, and iOS removes all of it with the app. There is no account to close and no server-side record of you for us to delete; our log lines age out on their own. Copies held by providers (a photo at Anthropic, audio at Deepgram) are subject to their retention policies; if you want help chasing one, contact us and we will make the request to the vendor on your behalf.

Note that "Run setup again" in Settings replays the questions but keeps your data — deletion is deleting the app.

Changes to this policy

The current policy always lives at this address. When the app's data flows change, this text changes in the same release, and the effective date below moves. If a change means something new leaves your phone, we will say so in that release's notes rather than only editing this page quietly.

Contact

Table is built by an independent developer. Questions, concerns, or deletion requests: hello@table-community.com.

Effective 4 September 2026.