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 names of the pots and their targets, every deposit, withdrawal and move, their notes and who added them. 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.

Who added it. The budget's settings have a “Who added it” switch, shown once the budget has at least two people with an account. It is off by default, and any household member can turn it on or off. While it is on, everyone in the budget sees who added each entry (“You” or a name), and spending in each category is split between people. For a recurring entry, the author is the person who set up the rule.

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 the week's figures and category names - among them the amount of one, largest expense, but without its date, merchant or note. 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 - the budget's plan, not a single account's: it is enough that someone in the household pays for it. In a budget without Plan BEEZZ 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. A household member who has not yet answered the consent question does not block the report - only a refusal does. Your answer reaches the budget you have open when you give it, and your other budgets when you open them.
• Anything is sent only where a Gemini API key is set in our server configuration. Without it the AI features simply do not run.
• Legal basis: 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 and extend with new versions of the app: banks and payment apps from 14 countries (Poland, the Netherlands, Germany, France, Belgium, the United Kingdom, Ireland, Sweden, Norway, Denmark, Finland, the United States - including PayPal, Venmo and Cash App - Canada and Australia), among them Swish, Vipps, MobilePay and Curve; the card-alert apps CardValet and CardNav, through which many American community banks and credit unions announce card purchases; plus Revolut, Wise, N26, Klarna, Google Wallet and Samsung 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.

A transfer between your own accounts is not an expense, so on such a notification the app asks what to do with it: add it to savings, link it to a deposit already there, or skip it. Each of those choices - skipping included, where no entry is created - we store on the server as a short receipt: the amount, the currency, the date, the note from the card (the same one that would go into an entry), the author and what you chose. That keeps the same transfer from coming back a second time. The receipt is kept for as long as the budget's entries (section 12), and it holds neither the full content of the notification nor the name of the bank.

• 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 nine 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, and the app leaving the screen in the middle of the setup (when you lock the phone or switch to another app, for example) - once for each step on which that happened.
• The first entry: the app opening the window for adding your first entry by itself after the setup. We record only that it opened - not what you type into 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, and from which exact place, which period the plan covers, whether it was available to buy at that moment, whether the button offered free days, whether the plan screen closed after the store had accepted a purchase but before it had settled it, which variant of the forecast was showing, which variant of the summaries screen opened and how it was grouped, at which step the setup was skipped or the app left the screen, which way you left the setup for the first-entry window (straight away, through the tutorial, or by joining someone else's budget with a code), and - when the setup is completed - which group the account belongs to: the one shown the plan offer right after setup, the one shown it once on opening the app on a later day, or the one not shown it. We also add the interface language (Polish, English, Dutch or Swedish) 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 summaries for our internal dashboard. For each account: when it was created, on how many days and when last the app was opened, how many entries, budgets and recurring charges the account has and the most people in any of its budgets, when its first entry was made, whether it is linked to Google or Apple, which plan it is on, where the plan comes from and when it was bought, how many months of history it had at the time of purchase, and the platform, language and market country code. For each budget: when it was created, whether it has been set up and whether it has Plan BEEZZ, how many entries it has, when the first and the last of them were made, how many months the entries span, how many people - and how many of them with an account - belong to it, how many recurring charges, category limits and top-level categories it has, and whether it has a limit for the whole month. Nothing new is collected for them. The summaries are recomputed once a day, overnight, so once an account is deleted it disappears from them by the following night at the latest.

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), Vercel, RevenueCat, Sentry and Resend process it solely on our instructions, under a data processing agreement, and we require each of them to protect that data at least as well as this policy describes. 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.

There is nothing in the app beyond that list: no advertising, analytics, maps, social media, attribution or A/B testing SDK. The only attribution is the Apple Ads token on iPhone, read by the RevenueCat library - described in section 4 and in the RevenueCat row above. 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.

Google, RevenueCat and Vercel process data outside the European Economic Area. Supabase and Sentry store data in the European Union, but both are companies from the United States, so access to that data from outside the EEA is possible. The same goes for Resend, Inc. - a US company through which we send our e-mail reply to a bug report, if you agree to be contacted by e-mail (section 18); the mail goes out from its European region. 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. Data of people in the United Kingdom is transferred on the same footing: to the EEA under the UK's adequacy regulations, and to the United States under the UK Extension to the EU–U.S. Data Privacy Framework or, where that does not apply, under the standard contractual clauses with the UK Addendum.

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, Savings (the pots, their history and their change log) and receipts for transfers between your own accounts (section 8) - until the account is deleted. With one exception: in a shared budget where other household members remain, the entries and what you added in Savings 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. When you delete a pot, its name also leaves the change log; what stays there is a trace of that pot's changes alone - without the name, with the target amount and the due date - for as long as the budget exists.
• 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 the note and merchant name from the result of breaking it down. What stays in the database is the technical row - which model broke it down, how long that took and how much it used - and the bare result of the breakdown: the amount, date, category, person and direction of the entry, 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 - together with the e-mail address for a reply, if you gave one, and with our correspondence about it. 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 at most 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. An anonymous account (not linked to Google or Apple), in whose budgets nothing has ever been recorded - no expense or income (even one deleted later), nothing in Savings and no recurring entry - and which nobody has opened for 30 days, is deleted automatically together with those budgets and their settings. This does not apply to accounts on which a plan has ever been bought, 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.
• Stays: your customer record at RevenueCat, if the app ever checked your plan - the account identifier, the purchase history and the device identifier (section 11). We do not delete it automatically together with the account. If you want it gone, write to privacy@beezz.app - we will delete it.

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, and the consent to be contacted by e-mail about a bug report in section 18, which you withdraw by writing to the address given below.

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.

Automated decisions. We do not profile you. Only two decisions are taken here without a human being involved, and both turn on fixed conditions set out in this policy rather than on any assessment of you: (1) deleting an empty anonymous account - an account in whose budgets nothing has ever been recorded and which nobody has opened for 30 days disappears together with those budgets (the exact conditions are in section 12); (2) the age question at purchase in the US App Store - when the age range declared on your Apple Account points to someone under 18, when you decline to share it or when it cannot be read, there is no purchase (section 15). You may ask for such a decision to be reviewed by a human being, put your point of view and contest it - write to privacy@beezz.app.

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 - in the Netherlands, the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl), and in Sweden, the Integritetsskyddsmyndigheten, IMY (imy.se). If you live in the United Kingdom, you may also complain to the Information Commissioner's Office (ico.org.uk). For people in the United Kingdom we apply the UK GDPR and the Data Protection Act 2018, and the rights in this section are theirs to the same extent.

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.

Today every household member has an account of their own. Older versions of the app let you add a household member by name alone - with no account, no sign-in and no access to the app - and such entries may still exist. That name does sit on our server. If you added a child that way, a first name or a nickname is enough, 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 - and the same happens when that first question cannot be put to Apple. 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 age range cannot be read, the purchase stops and you can try again. When the app cannot read your App Store account's country, the region set on the phone decides. 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 (and, when the account's country cannot be read, outside a phone set to the US region), 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 kind of report (a problem or an idea), 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. Together with a report we keep our correspondence about it - replies and notes. We delete them after 12 months, and together with the account - at once.

You give an e-mail address for a reply only if you want to. Under the description there is a switch, “I agree to be contacted by email about this”. Without it the report goes with no address at all. When you turn it on and your account is linked to Google or Apple, the field suggests that account's address - you can change it or type another - and what reaches us is exactly what the field says. We use it only to reply to that one report, never for a newsletter or advertising, and we delete it together with the report. The basis is your consent (Art. 6(1)(a) GDPR). You withdraw it by writing to privacy@beezz.app - we then remove the address from the report; withdrawal does not change what we have already written back.

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 and colors of household members; budget entries (amount, direction, date, category, merchant name, note, author); receipts for settled transfers between your own accounts (amount, currency, date, note, author, your choice); savings pots, with an optional target, and the money moved in and out of them (name, target, currency, amount, date, author, note), with a log of changes to the pots; the household's budget settings (including its time zone, the forecast settings and the “Who added it” switch), 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, a device identifier assigned by the system and the store's record of a purchase; the weekly report cache; usage statistics; bug reports and our correspondence about them, with an e-mail address for the reply if you choose to give one; 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 Resend, which delivers our e-mail reply to a bug report when you have agreed to one. 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; nothing goes to it without your consent, 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. When the app cannot read your App Store account's country, the region set on the phone decides; when that first question cannot be put to Apple, the purchase goes ahead without one. An adult buys; under 18 there is no purchase and no parental-consent path; a refusal or an age range that cannot be read 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 - November 6, 2026. We give notice of material changes at least 14 days before they take effect (section 19).