Privacy Policy

1. Who is responsible for your data

The controller of the personal data of users of the Beezz app and of the beezz.app website is AKN Software Kasper Janowski (“we”, “us”). Our full registration details - address and tax number - are in the Terms.

For personal data matters, write to privacy@beezz.app. For everything else - kontakt@beezz.app. We have not appointed a data protection officer; correspondence is read by the owner of the business.

2. The principles this rests on

• We do not connect to your bank. We do not ask for your bank login, we have no access to your bank account and we do not download your transaction history. Beezz is not a financial service.
• We do not show ads. There is no advertising SDK and no ad network in the app.
• We do not track you across apps or websites. We do not use advertising identifiers (IDFA, GAID) and we do not ask for permission to track.
• We do not sell data and we do not pass it on to data brokers.
• We have no third-party analytics. No Firebase, Amplitude or Mixpanel, and no A/B testing.
• Your data sits in the European Union - in a Supabase database in the European Union (Paris) region.

3. Your account: no registration, no password

An account is created automatically and anonymously the first time you open the app. There is no sign-in screen, there is no registration, you give no e-mail address. At the start we know next to nothing about you: an account identifier in the form of a random UUID.

You may - voluntarily - link the account to Google or Apple so that you can reach your data on another phone. Only then do we receive data from that account: your e-mail address and full name, and from Google also the address (link) of your profile photo. There is no e-mail-and-password path at all, so we store no passwords.

4. What data we collect and why

To use Beezz you do not have to provide anything - the account creates itself. Linking to Google or Apple is voluntary. The rest you enter yourself, and without it the app has nothing to count.

5. The shared budget - who sees your entries

A budget in Beezz is shared by up to four people. Everyone who joins it sees every entry in the household - amounts, dates, categories, merchant names and notes. The same goes for Savings: the goal names, every deposit and withdrawal, its note and who added it. Including everything from before they joined. That is how a shared ledger works, and there is no way to keep a separate, private shelf inside it.

By entering a household member's name and assigning spending to them, you are processing another person's data. Give only as much as is needed - a first name or a nickname is quite enough - and tell that person that their spending is being recorded in the app.

6. Dictating entries

You say “I bought bread for 12 dollars” and the app turns it into an entry. Two things happen inside, and they are worth keeping apart, because they concern different companies.

1. Your system's speech engine turns the sound into textOn iOS this is Apple's speech recognition; on Android it is the system's speech recognition, in practice Google's service. We hand it the sound from the microphone, and that engine may process it on its own servers, in line with Apple's or Google's policies and your phone's settings. We have no influence over this and we do not promise that recognition stays on the device.
2. What comes back to us is the text alone - and that we do storeWe do not store a recording and we never send one to Beezz servers. We do store the transcript, that is the whole spoken sentence, word for word, together with what the parser extracted from it. It is the most sensitive thing we keep.

The app asks for the microphone only when you first tap the microphone icon, not at launch. How long we keep transcripts - section 12.

7. Artificial intelligence

In two places we use the Google Gemini API language model (generativelanguage.googleapis.com). We send very little there, and we want to say exactly what.

These are two different portions of data and we deliberately do not glue them into one sentence: what goes out for the dictation breakdown is fragments of text without amounts and dates, and what goes out for the report is aggregate figures alone. The full dictated sentence - with the amount and the date - stays with us and does not reach Google.

• AI is optional. The app works without it - you add entries by hand, and the weekly report has a figures-only version with template sentences composed on the device.
• The AI layer additionally sits behind Plan BEEZZ. On a free account nothing goes out to the model.
• We ask for your consent first. Before anything goes out to the model, the app shows an “AI assistance” sheet that names the recipient (Google Gemini) and says what is sent. You choose “I agree” or “No AI”. Without consent nothing goes to the model: the Beezz dictionary suggests the category on its own, and the weekly report uses its template version.
• You can withdraw consent at any time - in Settings, on the “AI assistance” row. Withdrawal works from that moment on and does not change what was sent before. The answer belongs to the phone on which you gave it, and we also store it with your membership of the budget.
• The weekly report describes the whole budget at once, so its figures go to the model only when the person opening the report has agreed and nobody in the household has refused. One refusal is enough for that budget's report to be written without AI for everyone.
• Anything is sent only where a Gemini API key is set in our server configuration. Without it the AI features simply do not run.
• Versions before 3.0.0 do not know this question. On Plan BEEZZ they send the dictation fragments and report figures described above without asking, as they did before it was introduced - the basis is then the contract (Art. 6(1)(b) GDPR). If you want nothing to go to the model without your consent, update the app.
• Legal basis in version 3.0.0 and later: your consent (Art. 6(1)(a) GDPR).

8. Importing from payment notifications

This feature exists and works on both systems. It is not a connection to your bank - Beezz reads only the content of a notification that your bank has already sent to your phone.

• Android: the app listens to notifications from a list of payment apps that we maintain ourselves - today 79 apps: banks and payment apps from 10 countries (Poland, the Netherlands, Germany, France, Belgium, the United Kingdom, Ireland, the United States - including PayPal, Venmo and Cash App - Canada and Australia), plus Revolut, Wise, N26 and Google Wallet, which work across borders. You grant notification access by hand, on Android's own system screen - all we can do is ask for it.
• iOS 17 and later: you create the automation yourself in Apple Shortcuts, and its trigger is a transaction in Wallet (Apple Pay), not a notification from a bank. On an iPhone, Beezz does not read bank notifications at all and does not ask for access to them.

The principle is the same on both systems: the content of a notification is parsed on your device and never leaves it. We do not send it to our servers, we do not send it to the AI model, and we do not send the name of the bank or of the app the notification came from either. What reaches the server is only the entry you approve - amount, category, date, sometimes a merchant name in the note. Exactly as much as you would have typed by hand.

• The feature is off by default. Nothing happens until you turn it on yourself.
• You turn it off with a single switch in Beezz - and on Android you can additionally revoke notification access in the system settings.
• Notifications other than payment ones are skipped. We do not store them and we do not send them anywhere.

9. Usage statistics

We collect seven named events, into a table of our own in our own database, with no third-party analytics SDK. The list is closed and looks like this:

• First launch: completing the setup, or skipping it.
• The paid plan screen: showing it, tapping the button on it, dismissing it.
• Opening the forecast and opening the summaries screen - so that we know how many people reach the features where the plan screen later appears.

Versions of the app before 3.0.0 may still send one or both of two events that we have since retired: completing a single setup step, and an app rating on a scale of 1 to 5, if somebody answered the rating question. From version 3.0.0 the app collects neither.

To every event we add the account and household identifiers, the app version, the platform, the date and the event's own labels. The full list of those is: where you came to the plan screen from, which period the plan covers, whether it was available to buy at that moment, whether the button offered free days, which variant of the forecast was showing and how the summaries screen was grouped. We also add the interface language (Polish or English) and the market's country code - the country of your store account, or, when the store does not give one, the region from your phone's language settings. This is not location: we ask for no location permission and we do not read GPS or the network. Separately we record one row for each day on which the app was opened. We record no amounts, notes or merchant names here.

Out of data we already hold, we also compute a short per-account summary for our internal dashboard: when the account was created, on how many days the app was opened, how many entries, budgets and recurring charges the account has, when its first entry was made, whether it is linked to Google or Apple, and which plan it is on. Nothing new is collected for it, and the summary is recomputed every 10 minutes, so once an account is deleted it disappears at the next recomputation.

10. What we do not collect

• Audio recordings. We do not save an audio file, we do not keep a buffer for longer than the utterance lasts, and we do not send sound to our servers. What happens to it on the system's side - section 6.
• Location. We do not ask for access and we do not store coordinates. A merchant name in an entry is plain text, not a place on a map.
• Contacts. An invitation works on a code precisely so that we do not have to reach into your address book.
• Photos, videos and files from your device.
• Text messages and the call log.
• The content of notifications - see section 8.
• Payment card details. Payment is handled entirely by Apple or Google; the card number passes neither through the app nor through our servers.
• Advertising identifiers.
• Screenshots. Crash reports, too, go without a screenshot and without a view hierarchy - section 18.
• Push tokens. Notifications in Beezz are scheduled locally on your phone; we have no push server and no FCM or APNs tokens.
• Special categories of data - about health, origin, beliefs, sexual orientation or biometrics. We do not ask about them and there is nowhere for them in the app.

11. Whom we entrust data to

We do not disclose data to anybody other than the providers without which the service does not work. Supabase, Google (Gemini API), RevenueCat and Sentry process it solely on our instructions, under a data processing agreement. Apple and Google additionally appear in a role of their own - as the stores handling payment, as sign-in providers and as the system's speech recognition - and in that respect they answer for the data themselves, under their own policies.

Beyond that list there is nothing: no advertising, analytics, maps, social media, attribution or A/B testing SDK. There are two third-party SDKs in the app that send data of their own accord: RevenueCat for purchases and Sentry for crash reports - both stand in the table above. Telegram is not an SDK in the app: it is a message our server sends so that the owner of the business knows that somebody has bought a plan.

Google and RevenueCat process data outside the European Economic Area. Sentry stores reports in the European Union, but it is run by a company from the United States, so access to them from outside the EEA is possible. In each of these cases the transfer takes place on the basis of the EU-U.S. Data Privacy Framework and, where that does not apply, of the standard contractual clauses approved by the European Commission. We list the Telegram notification separately and explicitly even though it carries none of your data: we would rather name every server that anything of ours goes to than leave a gap in the sentence “beyond that list there is nothing”.

We may also disclose data to authorized public authorities where an obligation to do so follows from the law.

12. How long we keep data

• The account, the budget, the whole history of entries and Savings (goals, deposits and withdrawals) - until the account is deleted. With one exception: in a shared budget where other household members remain, the entries, deposits and withdrawals you added do not disappear with your account. They stay as that household's history, without the information that you added them (section 13), and disappear only together with the household.
• A deleted entry - 7 days. A deleted entry disappears from the app at once and from our servers after 7 days - a nightly job deletes it. If it was a day of a recurring entry that is still running, what stays of it is the amount, the date and the category alone - without the merchant name and the note - until you stop that rule. That is what keeps the day from being entered a second time.
• Transcripts of dictated sentences - 30 days. After that we delete the content of the utterance, and what stays in the database is the technical row alone: which model broke it down, how long that took and how much it used - without what you said. Deleting the budget entry itself does not remove the transcript any sooner; deleting the account removes it at once.
• Category hints (merchant and product names) - until the account is deleted. It is your household's dictionary and it works for exactly as long as the household exists. The shared list of popular stores from section 4 contains none of your data, so there is nothing in it to delete.
• The weekly report cache - 90 days. We delete the week's aggregated figures and the generated sentences after three months; the report itself can then be recomputed from your entries.
• Usage statistics and activity days - 24 months. That is enough to see how a feature behaves over two full years; older rows are deleted by the nightly job. Deleting the account removes them at once. Objecting to this processing is described in section 9.
• Bug reports - 12 months. After a year we delete them regardless of whether the bug was fixed. Deleting the account removes them sooner.
• Crash reports - 90 days. That is how long Sentry keeps them, and then it deletes them itself; we have no longer-lived copy. Deleting the account does not delete them any sooner, but from that moment the identifier in the report no longer leads to any account - details in section 18.
• Invite codes - they expire after 7 days, and the row itself does not wait for the account to be deleted: a code that has been revoked or has expired is deleted the following night at the latest (or sooner, when a new code is issued in that household), and a code somebody has already used stays for 90 days - it is the only trace of the way that person joined.
• Plan BEEZZ entitlements - until the account is deleted. The record of a billing event stays longer: when you buy, renew, cancel or receive a refund, we record one row with what the store said - the type of event, the product, the price, the currency, the country and the date. We keep it in order to settle the sale, handle a refund and answer a complaint, for at least 5 years from the end of the tax year in which the purchase took place - that is what tax law requires. Apple and Google remain the sellers towards you and it is they who issue you the proof of purchase; our row is a record of the transaction, not your invoice.
• Database backups - 7 days. Supabase makes a copy of the whole database every day and keeps each one for 7 days. Deleted data may therefore remain in the backups for at most 7 days, and then it disappears along with them. We use the backups only to restore the database after a failure, never to bring back a single account - for you, deleting the account is immediate and irreversible. Should we ever have to restore the database from a backup, we will again delete the accounts deleted in the meantime.
• An empty anonymous account - 30 days (from October 1, 2026; until that day, 90 days). An anonymous account (not linked to Google or Apple), in whose budgets no expense or income has been recorded and which nobody has opened for 30 days, is deleted automatically together with those budgets, their settings and any Savings goals in them. This does not apply to accounts with a plan bought on them, nor to accounts that are a member of a shared budget with another person. After such a deletion the app will create a new, empty account the next time it is launched.

13. Deleting the account - what goes and what stays

You delete the account yourself in the app: Settings, the deletion tile, press and hold. Step-by-step instructions are on the Deleting your account page.

• Gone: your account, your profile, your household memberships, all your transcripts of dictated sentences, bug reports, usage statistics, activity days and plan entitlements.
• Also gone: every household that no account can enter any more once you have left - together with everything in it.
• Stays for 90 days: crash reports in Sentry (section 18). Once the account is deleted they can no longer be linked to you - the identifier they carry leads to nobody.
• Stays: the record of a billing event, if you ever bought a plan. The row stops being attached to your account, but it does not disappear - it is a record of a transaction with the store, needed for settlement, refunds and complaints, and subject to the five-year tax obligation. What exactly is in such a row is set out in section 4; how long it sits there - section 12.

If you no longer have the app, write to privacy@beezz.app - we will delete the account at your request.

14. Your rights

Under the GDPR you have the right to:

• access your data and obtain a copy of it,
• have inaccurate or incomplete data rectified,
• have your data erased (the “right to be forgotten”),
• restrict processing,
• port your data to another service,
• object to processing based on legitimate interest - in practice this means the usage statistics in section 9 and the bug reports and crash reports in section 18,
• withdraw consent, where the processing was based on consent - in practice this means the AI consent in section 7, which you withdraw in Settings, on the “AI assistance” row.

The specific channels: erasure - in the app (section 13). Rectification - you edit entries, categories, your profile and household members directly in the app. A copy of your data - the app has an export of entries to a CSV file; that is a Plan BEEZZ feature.

Send any other requests to privacy@beezz.app. We answer within 30 days at the latest. To protect your data we may ask you to confirm that the account is yours - for example with a message from the e-mail address of the Google or Apple account linked to Beezz. With an anonymous account, not linked to any provider, we may have no way of verifying you.

If you believe that we are processing data unlawfully, you may lodge a complaint with the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych), ul. Stawki 2, 00-193 Warsaw, Poland, or with the data protection authority of the EU country where you live or work.

15. Children and household members without an account

Beezz is not directed at children. An account is created by an adult - as the Terms provide - and it is that person who answers for the data in their household. We do not knowingly collect data from people who are under 18.

A household member on the list does not have to have an account - in that case it is a name and nothing else, entered by an adult, with no sign-in of their own and no access to the app. But that name does reach our server. If you are adding a child, enter a first name or a nickname, not full details.

If you believe that a child has created an account on their own, write to privacy@beezz.app - we will delete it.

The age question at purchase. When you buy Plan BEEZZ in the US App Store on an Apple device running version 26.2 or later of its operating system, the app first asks Apple, just before payment, whether an age-verification law applies to your account - as one does in Texas, for example. If not, the purchase goes ahead with no question. If so, the app asks Apple for the age range declared on your Apple Account. If you are an adult, the purchase goes ahead. If you are under 18, there is no purchase - and no parental-consent path either. If you decline to share your age, or the answer cannot be read, the purchase stops and you can try again. The answer serves that one purchase only: we do not store it or log it, which is why it is not in the table in section 4. Outside the US App Store, on systems older than 26.2 (where Apple offers no way to check whether such a law applies) and on Android, nobody is asked about age. Section 16 of the Terms has the details.

16. Security

• All communication between the app and our servers goes over an encrypted HTTPS/TLS connection. There is no plain HTTP in the code.
• Access to data is restricted by rules on the database's side: every query sees only the rows of the household you belong to. The database enforces this, not the app's code alone.
• We store no passwords - authentication is handled by Apple's and Google's sign-in systems.
• An incorrect invite code always looks the same, so that codes cannot be guessed.
• The versions published in the stores are obfuscated, and we keep the debugging symbols outside the app - with ourselves and in Sentry, where they serve only to read a crash report.
• Data on the device (the cache and the write queue) sits in the app's sandbox and is protected by the system's encryption - we do not additionally encrypt it with a key of our own. There are no passwords and no card details there.

Data on the server is encrypted at rest on Supabase's disks.

17. The beezz.app website: cookies and logs

This site is an ordinary static website: there are no pixels on it, no analytics tools, no social plugins and no ads. The typeface is bundled with the site, so your browser does not ask Google for it. On its own, the site stores nothing on your device. At most it stores three small things - each only when you click the matching button yourself - to remember that choice:

• Your language choice - a cookie named beezz_lang holding pl or en, when you click the language switch in the footer or a link to the English version of a page. It lasts a year. Your browser sends it back on every visit to beezz.app, and the only thing that reads it is the rule that decides which language the home page opens in.
• Stopping animations - an entry in your browser's local storage, when you click “Stop animations” in the footer. It never leaves your device.
• Closing the note about the English version - an entry in your browser's local storage, when you close it. It never leaves your device.

None of these carries an identifier, none is connected with an account in the app, and none reaches anyone other than beezz.app. You remove them by clearing the site's data in your browser. We also choose the home page's language without storing anything: your browser tells every site you visit which languages you prefer, and the home page opens in Polish when Polish is first on that list and in English otherwise. We do not ask for cookie consent, because we store nothing without your click and only to remember that click - and we write that out plainly, because the duty to inform exists regardless (Art. 399 of the Polish Electronic Communications Law).

Server logs. Like every website on the internet, beezz.app is served by a hosting provider (Vercel), and its servers record technical logs of requests: the IP address, the date and time, the address of the page visited, the browser and system type. The logs arise automatically, they are needed to keep the site running and secure, and we do not connect them with any account in the app. The basis is our legitimate interest (Art. 6(1)(f) GDPR), and the provider stores and deletes them in line with its own schedule - no database of ours arises out of them.

Request logs arise in the same way on Supabase's side, when the app talks to the database. They serve diagnostics and maintenance alone; we do not build profiles out of them and we do not use them for anything else.

18. Bugs and crashes: what you report yourself, and what the app sends on its own

A bug report you send yourself, from Settings in the app. What reaches us then is what you write in the description (up to 2,000 characters), the place in the app it concerns, your display name, your account and household identifiers, the app version, your phone's operating system and its version, the interface language and the market's country code - the same one as in the statistics in section 9. The description is an ordinary text field, so there is exactly as much in it as you write yourself - if you would rather not give amounts or names, simply do not type them in. The reports are read by us and only by us, in order to fix the bug. We delete them after 12 months, and together with the account - at once.

Crash reports the app sends on its own, to the Sentry tool. A report arises when the app hangs, stops responding, is closed by the system for want of memory, or hits an error after which it did carry on but something could not be done - an entry failing to save, for example. On top of that, at every launch and close of the app a short session signal goes out: when it began, when it ended and whether it ended with a crash. Without it there would be no way to work out what proportion of launches runs without an error.

What is in a report. The account identifier and the household identifier - both in the form of a bare UUID. The type of error, its message and the place in the code where it occurred. A trail of the last steps: the screens you passed through (the screen's pattern alone, without what was on it), and the calls to our server - method, address without the values of any parameters, response code and duration. Technical data about the device, in particular: manufacturer and model, system version, app version and build number, language and time zone, screen orientation and resolution, memory and battery state, and whether the phone was online. Finally, the date and time.

What is not in a report. Your e-mail address, your first name or your IP address. Amounts, notes, merchant names, category names or the content of dictated sentences. A screenshot and a view hierarchy - a screenshot of this app is somebody's ledger of spending. The content of requests sent and received, cookies, tokens, keys and invite codes. Labels of what you tap - in Beezz those are category names. A loss of network connection is not a crash and is not reported. Nor do we measure the app's performance: that part of the tool is switched off.

Native crashes bypass the sieve. When the app crashes at the system level (a memory fault, for example), stops responding on Android, or is shut down by iOS, the report is created and sent by the native part of the Sentry library built into the app, without passing through the sieve. Such a report carries native stack frames, technical data about the device, and the account and household identifiers (UUIDs) - nothing outside the list in “What is in a report”. The trail steps the app recorded went through the sieve before they reached such a report, and the block on default personal data applies here too, so such a report also goes without your IP address.

Where and for how long. Reports go to a Sentry project in the European region (Frankfurt) and sit there for 90 days, after which Sentry deletes them itself - we have no longer-lived copy. Deleting the account does not delete them any sooner, but from that moment the identifier in the report no longer leads to any account. The tool is run by Functional Software, Inc. of the United States; the basis for the transfer is the same as for the other providers and is described in section 11. The reports are read by us and only by us, in order to fix what is breaking.

19. Changes to this policy

We may change this policy - for example when a new feature arrives or a provider changes. We will give notice of material changes in the app or by e-mail at least 14 days before they take effect. The date of the last update is always at the top of this page.

We also tell the App Store and Google Play about a material change to this policy, to the Terms or to the way the app charges for anything. In some places - Texas among them - that notice is what lets a Store ask a parent to consent again on behalf of a minor.

20. Additional disclosures for readers in the United States

This section adds nothing to the sections above. It gathers the same facts in the form that California law - the California Online Privacy Protection Act - asks a website operator to state plainly. Beezz is run from Poland by one person and sits below the thresholds at which California's Consumer Privacy Act applies at all; we have written this section as though that did not matter, because the rights it is about are in section 14 and we give them to everyone.

• The categories of personal data we collect. Section 4 lists them in full, with their sources and purposes: an account identifier; an e-mail address and full name (and, from Google, a profile photo address), if you link a Google or Apple account; a display name and app language; the names, colors and emoji of household members; budget entries (amount, direction, date, category, merchant name, note, author); savings goals and the deposits and withdrawals toward them (name, target, currency, amount, date, author, note); the household's budget settings (including its time zone), category limits, custom categories and recurring charges; your answer to the AI consent question; transcripts of dictated sentences and the result of breaking them down; your household's category hints; invite codes; your plan and the store's record of a purchase; the weekly report cache; usage statistics; bug reports; and crash reports.
• Whom it is shared with. Section 11 names every recipient: Supabase, Google (Gemini API), Vercel, RevenueCat, Sentry, Apple and Google in their roles as the stores, as sign-in providers and as the system's speech recognition, and Telegram for a message to the owner of the business. We disclose data to nobody else, other than to authorized public authorities where an obligation to do so follows from the law.
• How you review or change your data. Entries, categories, your profile and household members are edited directly in the app. Entries can be exported to a CSV file, and a copy of your data is issued free of charge on request to privacy@beezz.app. The account - and with it everything listed in section 13 - is deleted from Settings in the app. Section 14 sets out the full list of rights and how to exercise them.
• We do not sell or share personal data. We do not sell it, we do not share it for cross-context behavioral advertising, and we do not pass it on to data brokers. There is no advertising SDK and no advertising identifier in the app (sections 2 and 10).
• Do Not Track. The beezz.app website runs no analytics, sets no cookie except the one that remembers a language you picked yourself, and follows nobody across other websites or over time (section 17), and the app uses no advertising identifiers and does not track you between apps or websites (section 2). There is therefore nothing that a “Do Not Track” signal could switch off, and we do not respond to such signals in any other way. We do not allow third parties to collect personal data about your activity across different websites when you use beezz.app.
• Children under 13. Beezz is not directed at children. An account may be created only by an adult, and we do not knowingly collect personal data from anyone under 18 - which includes children under 13 (section 15). If you believe that a child has created an account, or that a child's data has reached us, write to privacy@beezz.app and we will delete it.
• The rights in section 14 are everyone's. Access to your data, its correction, its erasure, a copy of it in a portable file and a complaint about the way we handle it - we offer every one of them to every person who uses Beezz, whichever country or state they are in, and whether or not a law where they live obliges us to. There is no shorter list for anybody.
• Opt-out preference signals. A Global Privacy Control signal, or any other browser signal of that kind, has nothing here to switch off: we do not sell personal data, we do not share it for cross-context behavioral advertising, and there is no advertising identifier in the app. We do not act on such signals in any other way, because there is no processing they could stop.
• Sensitive personal information. We hold none of the kinds California treats as sensitive. Beezz never connects to a bank - we have no account number, no card number, no banking log-in and no access code to anything of yours (section 8). We collect no precise geolocation, no biometric or health data, nothing about racial or ethnic origin or religion, and we do not read the contents of your mail, e-mail or messages. The credential you sign in with is held by Google or Apple, never by us.
• Nothing here trains a model. Section 7 names the two places an AI model is used; from version 3.0.0 nothing goes to it without your consent (section 7 says how older versions behave), and both run on the paid Gemini plan for exactly one reason: only its terms rule out using what is sent to train or improve Google's models. Nothing you write in Beezz trains anything - ours or anyone else's.
• Age at purchase. In the US App Store, on an Apple device running version 26.2 or later, the app first asks Apple whether an age-verification law applies to your account - as one does in Texas - and only if it does, asks Apple for your declared age range just before a purchase. An adult buys; under 18 there is no purchase and no parental-consent path; a refusal or an unreadable answer stops the purchase, which can be tried again. The answer serves that one purchase: we do not store it or log it, which is why it is not in section 4. Section 15 above and section 16 of the Terms set out the whole of it.
• Effective date. This policy takes effect on the date shown at the top of this page - September 25, 2026. We give notice of material changes at least 14 days before they take effect (section 19).