Reach & Do — Privacy Policy
Last updated: 22 October 2026
This is an English translation provided for convenience. The Hebrew version is the binding one; if the two differ, the Hebrew text governs.
1. Who we are, and what this document is
Reach & Do is a voice conversation app with digital characters (the user chooses who to talk to) that carry out real actions on the user's behalf: web search, reading and creating events in Google Calendar, sending email as the user, and inviting contacts to a meeting. This document explains what data the app collects, why, and who it is shared with.
2. Information we collect
- Google account details — name, email address and profile picture, at sign-in (Google Sign-In).
- Apple account details — name and email address, at sign-in (Sign in with Apple). Apple lets users hide their real email address behind a private relay address; such an address, if provided, reaches us and is treated exactly like any other email address.
- Google Calendar access — reading existing events and creating new ones, only at the user's explicit request inside a conversation, and only after an explicit permission grant through Google itself.
- Sending email as the user (Gmail) — sending a message from the user's Gmail address to a recipient the user asked for, only after the character has read the recipient and the full message aloud and received explicit confirmation. The permission is send-only (
gmail.send): we do not read, search, store or delete messages in the mailbox. - Google contacts — when the user asks to email someone or invite them to a meeting by name, the app searches the user's contacts for that name and retrieves name and email address only (no phone numbers, home addresses or any other field). The permission is read-only (
contacts.readonly). The address is used only to send that one message or invitation and is not stored by us. The character itself hears only the contact's name; the address stays on the server. - Email signature — a short text added to the end of emails sent on the user's behalf. By default it is derived from the user's name, and the user can edit or clear it on the account screen.
- Microphone and voice — the user's audio is captured during a live conversation and passed for processing so the character can understand and answer.
- Conversation content — what is said in the conversation (including search queries the user asks for) is processed in order to produce an answer and perform actions.
- Memory ("Characters that know me") — at the end of a conversation, the app writes, from the conversation's transcript, an ongoing summary about the user (who they are, what occupies them, how they like to be spoken to) and short documents about topics that continue (for example planning a trip: where you left off, what was decided). The memory is shared by all the characters and kept separately for each account. The memory writer is instructed to keep only what the user says about themselves and their affairs.
- Transcription of speech — while memory is on, the user's speech is transcribed to text during the conversation so the memory can be written. At the end of the conversation the transcript is sent to our server to write the memory, and our server does not keep it once writing is done.
- Technical usage data — the monthly number of conversations per user, in order to enforce a fair usage quota.
- Billing data — the balance of conversation minutes you have bought and how much of it is left, and, for anyone still holding a subscription bought earlier, whether it is active, its renewal date, and the minutes used in the current cycle. This does not include payment details (card numbers and the like) — those are held solely by Apple or Google (depending on the store you bought from), never by us.
- Launch-list email address — if you left an email address on the marketing page (before actually registering for the app), it is stored solely to notify you when public registration opens. It is not linked to your use of the app unless you later sign in with the same Google account.
- Android tester sign-up — anyone who signs up on the
/testerspage gives a name, a Gmail address and a phone number (to stay in touch during the test and for the testers' WhatsApp group) and, optionally, a phone model. These are emailed to the app's owner only (through Resend), are not stored in the database, and are used only to add the person to the Google Play tester list.
3. Who the information is shared with
Information is processed by external service providers solely in order to operate the app itself. It is not sold and not shared for marketing purposes:
- OpenAI — processes the conversation's voice and text in order to produce the character's answers, and transcribes the user's speech and writes the memory at the end of a conversation.
- Anam — renders the character's face in real time (receives audio only, for lip-sync).
- LiveAvatar (HeyGen) — the face vendor for one of the characters, in place of Anam. It receives only the character's own synthesized speech, for lip-sync, and returns video. Your microphone never reaches it: the app only receives from that channel and publishes nothing to it.
- Fly.io — hosts our relay server, which passes the conversation audio in real time between the app and OpenAI. The relay keeps no copy of the audio.
- Tavily — performs the web searches the user asks for during a conversation.
- Google — for sign-in, calendar access, sending email as the user (Gmail) and contacts search, in accordance with Google's own privacy policy.
- Resend — only if the user takes the explicit "send by email" action, in order to send the conversation summary to that user's own email address — never to any other address. It is also used to send us an internal notification when someone joins the launch list.
- Supabase — stores the memory (section 2), the billing data, and the launch-list addresses, for the relevant user.
- Apple (App Store) — when a purchase is made in the app, the purchase itself is carried out and secured by Apple; we never see or store payment details. See Apple's privacy policy.
- Google (Google Play) — when a purchase is made in the Android app, the purchase itself is carried out and secured by Google Play; we never see or store payment details. See Google's privacy policy.
- RevenueCat — receives the same account identifier already used everywhere else in the app, in order to link an actual purchase to the correct account and to know what you are entitled to.
Beyond the services listed above, the app loads its fonts from Google Fonts. Like any externally hosted asset, that request tells Google the IP address and browser of whoever opens a page. No conversation content is involved.
4. Google data — Limited Use
Reach & Do's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
In practice this means data from Google is used solely to do what the user asked for within the conversation: reading calendar events in response to a question that was asked; creating an event, sending an email or inviting guests — only after explicit spoken confirmation; and searching contacts for a name only to find the recipient or guest the user named. It is not used for advertising, is not sold, and is not transferred to anyone other than the service providers listed in section 3 who operate the feature itself. We do not keep a copy of the calendar, the contacts or the mailbox, and we do not read them in the background.
5. Data retention
The encrypted Google access token, the email signature and the monthly usage counter are stored in an encrypted database (Upstash Redis). Contacts and the content of sent emails are not stored by us. Raw conversation content is not stored long-term on the server — it exists only while the conversation is active, unless the user chooses to download a transcript or summary or to send it by email, in which case it of course exists in the file or email the user created.
The memory (section 2) is different: unlike raw conversation content, it is kept long-term in Supabase so the characters remember between conversations — until the user turns it off, deletes it, or deletes the account. The summary and topics are encrypted with a separate key that exists only on our server. The three previous versions of each are also kept, encrypted, to restore information if a rewrite destroyed it.
6. Data security
These are the protections actually applied to sensitive data, first among them the Google Calendar access:
- Encryption in transit. All traffic between the device and our servers, and between our servers and the external providers, runs over HTTPS/TLS only.
- Encryption at rest, on top of the provider's own. The Google Calendar refresh token is encrypted by us with AES-256-GCM before it is written to the database — so anyone reaching the stored record sees ciphertext, not the token.
- The encryption key is held apart from the data. It lives as a server-side environment secret, not inside the database, and never reaches the browser.
- Calendar content itself is not stored. Events are read in real time to answer the question asked in that conversation, and then discarded. We keep no copy of the calendar and do not read it in the background.
- Per-account access. Every database read is scoped to the signed-in user's own record. Credentials for the external providers are server-side secrets; the browser never receives them.
- Minimum scope. For each capability we request the narrowest permission that allows it: for the calendar,
calendar.events, which allows reading and creating events only; for mail,gmail.send, which allows sending only, with no access to read messages; and for contacts,contacts.readonly, read-only, from which we retrieve name and email address only. We do not request access to calendar settings, to mailbox content, or to any other data in the Google account. - Revocable at any time. The permission can be disconnected from the account screen in the app, and equally from the permissions page of your own Google account.
7. Deleting data
The memory (section 2) can be viewed at any time on the /memory page inside the app. It has one switch, "Characters that know me": turning it off deletes the whole memory and stops it. The "Delete your memory" button deletes everything and starts afresh. You can also ask any character in a conversation to "delete everything you know about me" — the character is instructed to ask once before deleting. A conversation already open goes on as it is; the change applies from the next conversation. To delete the rest of the stored data (Google token, email signature, quota data, billing data, and the launch-list address if you joined it), contact the address in section 9 and ask for deletion, or delete the entire account through the /delete-account page, which deletes the memory as part of deleting the account.
Please note: transaction records of a purchase (what was purchased, when, and at what price) remain with Apple or Google (depending on the store) even after your account is deleted with us. They retain transaction records in accordance with their own policies and regulatory obligations, and we have no ability to delete them. RevenueCat, which manages purchases for us, also keeps its record by default, because it is used to restore purchases and to handle refunds; you can ask us to delete it too, by writing to the address in section 9.
We also keep a transaction record for each minutes pack bought — the account identifier, which pack, when, the store's transaction ID, and how many minutes are left — after the account is deleted. It contains no name, email address or conversation content. It is kept for two reasons: as a record of a financial transaction, and so that if you come back with the same account, your remaining minutes come back to you — and a purchase already used up is not credited twice.
8. Minors
The app is not intended for children, and does not knowingly collect information from minors.
9. Contact
For questions about this policy or data deletion requests: gonenya@gmail.com
10. Updates to this policy
This policy may be updated as the app's capabilities change. The date of the last update appears at the top of the document.