Burge — Privacy Policy

Effective date: September 8, 2026 · Last updated: October 6, 2026
Data controller: Cihan Mert Bayam, individual developer, Türkiye · contact@burge.app

1. What Burge is

Burge is a mobile app for iOS and Android that shows a short, curated list of the best-rated places (cafés, restaurants, bars and similar) around a location you choose. It has two search experiences: the main search, which returns at most five highly-rated places, and Burge It, which surfaces newly opened places that the main search filters out. This policy covers both.

This policy also covers our website, burge.app. What the website handles is described in section 2.7; everything else in this policy is about the app unless it says otherwise.

The app does not use any advertising, attribution, or third-party analytics SDKs.

2. What we collect

2.1 Your account

The first time you open Burge, we create an anonymous account for you automatically. It is a random identifier and nothing else — no name, no email, no device identifier, nothing that points back to you. You do not sign up, and you are not asked to. Everything the app stores about you — your liked places and your daily search allowance — is attached to this identifier, so it can be shown back to you and deleted on request. Search logs are deliberately kept outside this link (section 2.2).

Signing in is entirely optional. Its only purpose is to let your liked places follow you to another phone. If you choose to sign in with Google or Apple, that anonymous account is upgraded — it stays the same account, so nothing is lost — and we then also receive:

We do not receive your Google or Apple password, contacts, calendar, photos, or any other account content. We never post anything anywhere on your behalf.

You can sign out at any time (Profile → Sign out), which returns you to an anonymous account, or delete the whole thing (section 6).

2.2 Search logs (stored on our server)

Each time a search actually runs, we record one row containing:

These rows carry no account identifier at all. They used to, and we removed it: the app never reads this table, and knowing who searched is not needed to answer the only questions we ask of it — which searches return poor results, and which areas have weak coverage.

The practical consequence, stated plainly: because nothing connects these rows to you, we cannot show them to you and we cannot delete them for you — we have no way to tell which ones would be yours. There is nothing personal left in them to delete.

If a search result is served from the app’s local cache, no new row is written.

2.2b Usage events (stored on our server)

To understand how the app is used — which screens people open, whether a search leads to opening a place or Google Maps, and what happens when the daily limit is reached (did the sign-in or subscription screen appear, was it closed or completed) — the app records short usage events. Each event holds only:

• the event type and a few fixed labels, for example screen_viewed · Results, place_opened · rank 2 or paywall_result · dismissed;
• the app version and platform (iOS or Android);
• the country, as a two-letter code derived by our hosting provider from the connection — never your coordinates;
• a random session code that groups the events of one app visit.

These events carry no account identifier and no device identifier. The session code is created in your phone’s memory when the app opens, is never saved to storage, and is replaced every time the app is reopened or returns after 30 minutes in the background — so two visits cannot be linked to each other, or to you. Events never contain what you searched for, the area you searched in, place names or identifiers, or anything you typed; the server rejects any event that does not match a fixed list of types and labels.

To stop the event log from being flooded, the server counts how many events your account sent in the current minute. That counter holds only a number and a time, never the events themselves, is overwritten every minute, and is deleted within a day.

2.3 Abuse-prevention counters (stored on our server)

Because requests to Google now pass through our own server (see section 4.2), that server has to protect itself from being used by someone else at our expense. To do that it keeps a simple daily tally:

These are counters, nothing more: a number per day. They are not linked to what you searched for, where you searched, or what results you saw — those live in separate tables (sections 2.1–2.2) that hold no IP address. We do not use these counters for analytics and we never look at an individual row.

An IP address can count as personal data, so we say so plainly. It is retained for 30 days and then deleted. Our legal basis is legitimate interest in keeping the service running and affordable (GDPR Article 6(1)(f); KVKK Article 5(2)(f)).

Note on “Delete my account”: that button erases your account and everything attached to it. It deliberately does not reset these counters — if it did, anyone could clear their own rate limit by deleting and recreating an account, and the protection would be pointless. The counters expire on their own within 30 days and contain no record of what you searched for.

Free searches on your iPhone (Apple DeviceCheck). Burge gives each iPhone a small number of free searches. So that deleting and reinstalling the app does not reset them, we use Apple’s DeviceCheck service: when you search for free, your phone creates a temporary, encrypted token, our server passes it to Apple, and Apple keeps two bits for your device that mean only one thing — how many free searches have been used (0 to 3). We never see a device identifier and we do not store the token; it cannot be used to identify you and is thrown away after the request. The two bits contain no name, account, location or search, and are kept by Apple for our app only. Our legal basis is legitimate interest in keeping the free tier from being abused (GDPR Article 6(1)(f); KVKK Article 5(2)(f)). Subscribers are not counted this way.

2.4 Location

Location access is optional. You can always type a place name instead. If you tap “Use my location”, your phone asks for permission and the app reads your device’s GPS coordinates. Those coordinates are then sent — through our server, which passes them straight to Google without storing them — to run the search and to look up an approximate area name for display.

Your precise coordinates are never written to our database. Only the approximate area name may appear in a search log. You can withdraw location permission at any time in your phone’s settings (on iOS: Settings → Privacy & Security → Location Services → Burge; on Android: Settings → Apps → Burge → Permissions → Location).

Location suggestions. From version 1.0 (4), the location box can offer matching places as you type — cities, neighbourhoods, streets and well-known places. Once you have typed at least three characters and then paused, the text you have typed so far is sent — again through our server, which does not store it — to Google, which returns a short list of matching places. Nothing is sent while you are still typing, and nothing is sent for one or two characters. If you pick a suggestion, one further request turns it into coordinates. We keep neither the suggestions nor what you typed; the location text you finally search with is kept only on your own phone (section 2.5).

So that those suggestions are places near you rather than anywhere in the world, two hints travel with that request: your phone’s language setting, and a two-letter country code. The country code is worked out from your IP address by the network that sits in front of our server, which reports the country and nothing more precise. We do not store it, and Google receives it as a country code, never as an IP address. Apart from the abuse-prevention counters in section 2.3, this is the only thing your IP address is used for.

Your approximate area. If you have used “Use my location” at least once, a third hint travels with a suggestion request: your approximate last location, rounded to about 1 km, so that for a street name found in many towns the one near you comes first. It is read from your phone’s own storage (section 2.5) — the app does not read your GPS again for this and never asks for location permission for it. Our server passes it to Google without storing it. If you have never shared your location, no area is sent and only the country code is used.

2.5 Data that stays on your device

The following is stored only in the app’s private storage on your phone, is never transmitted to us, and is deleted when you delete the app:

• your sign-in session, so you are not asked to sign in every time,
• whether you have already seen the introduction slides,
• your last few searches, so the home screen can offer them back as shortcuts. Only what you typed is kept — the search term, the location text and the mode. No place names, ratings or addresses, and no GPS coordinates. Deleting your account erases these from the phone too.
• your approximate last location, rounded to about 1 km, saved when you use “Use my location” so that location suggestions can favour places near you (section 2.4). Your precise coordinates are never saved on the phone. This is the one item in this list that ever leaves the phone: it travels with a location-suggestion request, through our server to Google, and neither stores it. Deleting your account erases it from the phone too.

Your liked places and your search counters used to live here. As of August 18, 2026 they are stored on our server instead, attached to your account — that is what lets them follow you to a new phone. Liked places are still only Google place identifiers with a timestamp; names, ratings and addresses are never stored and are fetched fresh from Google each time you open the Liked screen.

2.6 What we do not collect

We do not collect your phone number, contacts, photos, calendar, health data, device identifiers, or advertising identifiers. We never receive your Google or Apple password. The app does not use cookies, advertising SDKs, attribution SDKs, or third-party analytics products. (Our website can receive one security cookie from its hosting provider, and counts visits without cookies or identifiers — section 2.7.) We do not send your data to any artificial intelligence or machine-learning service. We do not track you across apps or websites, and we do not sell or share your data for advertising. The weekly reminder described in section 6 is scheduled by your phone itself, so we use no push-notification service and never receive a device push token.

Your name and email are collected only if you choose to sign in, and only as described in section 2.1. If you never sign in, we hold neither.

2.7 Our website (burge.app)

The website has no accounts, no sign-in, no advertising and no tracking. Apart from the visit statistics described below, it runs no third-party scripts, and we receive nothing about you from it unless you send us one of its two forms:

Each form is sent from your browser directly to Web3Forms (section 4.8), which forwards it as an email to our inbox. That inbox is a Gmail account, so the email is also held by Google under the Google Privacy Policy. Nothing you enter on the website is copied into the app’s database or connected to an app account. The beta invitation is the public TestFlight link sent to you by email; we do not give your email address to Apple. A hidden field on each form filters out automated spam; there is no captcha.

Cookies. The website itself sets no cookies. Cloudflare, which delivers the site (section 4.7), may set a cookie named __cf_bm to tell people apart from bots. It holds an encrypted bot score, not your identity, is needed for that protection to work, and expires after 30 minutes of inactivity. If Cloudflare ever asks your browser to pass a security check, it may also set cf_clearance to remember that you passed. Neither cookie is used for tracking or advertising.

Your IP address. Like any website, the server that delivers a page sees the IP address it is sent to. Cloudflare processes it to deliver the site, to block abuse and to work out the country for the visit statistics below. We do not keep website visitor logs.

Visit statistics. To see how many people visit the website, which pages they read and how they found it, we use Cloudflare Web Analytics. When a page loads, a small script from Cloudflare reports that page view: the page address, the website that linked to it (if any), your browser, operating system and device type (for example “mobile”), and how quickly the page loaded. Cloudflare adds the country. The script sets no cookies, stores nothing in your browser and creates no identifier for you, and Cloudflare states that it does not use your IP address or browser details to follow visitors over time. We see only totals — for example, “40 visits from Germany this week” — never an individual visitor.

3. Why we collect it, and our legal basis

Search logs are used for one purpose: to understand, in aggregate, which searches and which areas produce weak results, so the ranking and filtering can be improved. Usage events (section 2.2b) are used, in aggregate, to see which parts of the app are used and where people give up, so the app can be made simpler. Neither is used to build a profile of you, to target advertising, or to make any decision about you.

Account data (section 2.1) is processed on a different basis: it exists because you asked for it by signing in, so that the feature you requested — your liked places on more than one device — can work. In GDPR terms that is performance of a contract (Article 6(1)(b)); under the KVKK it is Article 5(2)(c). If you never sign in, none of it applies to you.

Website forms (section 2.7) are processed because you sent them. For the beta list the basis is your consent (GDPR Article 6(1)(a); KVKK Article 5(1)), which you can withdraw at any time by emailing us — we then delete your entry. For support messages it is answering the request you made (GDPR Article 6(1)(b); KVKK Article 5(2)(c)). Cloudflare’s handling of IP addresses, its security cookie and the visit statistics rest on our legitimate interest in keeping the website available and safe and in understanding, in aggregate, how it is used (GDPR Article 6(1)(f); KVKK Article 5(2)(f)).

Burge is available worldwide, so more than one privacy law may apply to you. Whichever one does, the treatment is the same: we keep the minimum, tied to your account, and you can erase all of it yourself at any time.

• Türkiye (KVKK, Law No. 6698). The data controller is the developer named above. Search logs and usage events are processed under Article 5(2)(f) — the controller’s legitimate interests — as the processing is necessary to operate and improve the service and does not harm your fundamental rights. Location is processed on the basis of your explicit consent.
• European Economic Area and the United Kingdom (GDPR). Our legal basis for search logs and usage events is legitimate interest (Article 6(1)(f)) in operating and improving the app. Location is processed on the basis of your consent (Article 6(1)(a)), which you give through your phone’s location permission prompt (iOS or Android) and can withdraw at any time in your phone’s settings.
• California (CCPA/CPRA). We do not “sell” or “share” your personal information as those terms are defined, we do not use it for cross-context behavioural advertising, and we do not knowingly collect personal information from anyone under 16.

4. Who else is involved

4.1 Google Maps Platform

Burge uses Google Maps Platform services (the Places API and the Geocoding API) to find places and resolve locations. This application includes Google Maps features and content. Use of Google Maps features and content is subject to the then-current versions of:

• Google Maps/Google Earth Additional Terms of Service
• Google Privacy Policy

When a request reaches Google, Google receives data such as the search term and the coordinates or area being searched, as described in the Google Privacy Policy. We do not send Google your account identifier, your email, or your name.

Google no longer sees your IP address. Since the change described in section 4.2, requests arrive at Google from our server, so the IP address Google records is ours, not yours. The one exception is the two-letter country code that travels with a location-suggestion request, together with your phone’s language setting — see section 2.4. A country code is not an IP address and cannot be narrowed back down to one.

4.2 Our own server (and why it exists)

The app does not talk to Google directly. Every request goes first to a small service we run on Supabase, which forwards it to Google and returns the answer unchanged.

The reason is security, not data collection. Calling Google requires a secret key. If that key ships inside the app, anyone can extract it from the installed app file and spend our budget with it. Keeping it on the server means it is never on your device at all.

What this service does with your request: it checks that the request is one of the handful of operations the app is allowed to make, counts it (section 2.3), forwards it, and returns Google’s answer. It does not store the search term, the coordinates, or the results. Photographs are handled the same way — the service asks Google where the photo lives and tells your phone to fetch it from there, so the image itself never passes through us.

4.3 Supabase

Search logs, the abuse-prevention counters, and the forwarding service described above all run on Supabase, acting as our data processor. Nothing is shared with anyone else.

4.4 Apple and Google Play

Burge is distributed through Apple’s App Store and TestFlight, and through Google Play. Those stores collect their own installation and crash information under the Apple Privacy Policy and the Google Privacy Policy. We receive crash reports only in aggregated, anonymous form, and only if you have enabled sharing in your device settings.

On iPhone, Apple also provides the DeviceCheck service we use to count free searches per device (section 2.3). Apple stores two bits for your device; no personal information is shared with Apple for this.

4.5 Expo (over-the-air app updates)

Applies to app version 1.0 (4) and later. Earlier versions do not contact Expo at all.

Burge can update its own JavaScript, styles and images without waiting for a new App Store or Google Play release. That service is EAS Update, run by Expo, acting as our data processor.

On each launch the app asks Expo whether a newer version exists. That request carries: a random installation identifier generated the first time the app runs — it identifies the installation, never you, and is gone when you delete the app — the platform (iOS or Android), the version of the app’s native code, the release channel, and, only if the app crashed during its previous launch, a short crash message (truncated to 1,024 characters). Expo’s servers also see the IP address the request arrives from, as any web server does.

The crash message exists so that a broken update can be detected and rolled back automatically. It is a technical error description, not a record of what you did: Burge’s own error messages are fixed strings that never contain your search term, your location, or a place name. This behaviour cannot be switched off on its own without disabling the update mechanism itself, so we disclose it rather than leave it unsaid.

Expo states that it acts as a processor for end-user data handled on behalf of developers, that it does not sell data, and that it is GDPR-, CCPA- and Data Privacy Framework-compliant. Expo does not publish a retention period for update-check data — see the Expo Privacy Policy and the Privacy Explained page. Nothing about your account, your searches, or your liked places is sent to Expo.

4.6 RevenueCat (subscriptions)

Applies to app version 1.0 (4) and later. Earlier versions contain no subscription feature and do not contact RevenueCat.

Burge offers an optional paid tier, Burge Premium, which raises your monthly search allowance. Subscriptions are handled by RevenueCat, acting as our data processor under its Data Processing Addendum.

We never see your payment details. The money is taken by Apple or Google, not by us; no card number, billing address or bank information reaches Burge or RevenueCat through the app.

What RevenueCat holds: your Burge account identifier (the same random identifier described in section 2.1), which product you bought, when it renews or expires, and your device model, operating system and app version. RevenueCat states that it does not collect names, email addresses or IP addresses by default, and we send it none of those.

Your subscription is linked to your Burge account — that is what lets the server know your allowance is higher, and what lets your subscription follow you to another phone when you sign in. If you subscribe without signing in, it stays tied to the anonymous account on this device and to your Apple or Google account, which is how Restore purchases brings it back.

Deleting your Burge account removes what we hold about your entitlement, and the app returns RevenueCat to an anonymous identifier. It does not cancel the subscription itself — only you can do that, from your Apple or Google subscription settings, and you should cancel there before deleting the account if you no longer want to be billed.

4.7 Cloudflare (website hosting, visit statistics and email forwarding)

The website is delivered by Cloudflare, acting as our data processor. Cloudflare sees the IP address and browser details of each visit in order to deliver the page and block attacks, and may set the security cookie described in section 2.7. It also provides the website’s visit statistics (Cloudflare Web Analytics, section 2.7). Email sent to contact@burge.app also passes through Cloudflare, which forwards it to our inbox.

4.8 Web3Forms (website forms)

The two website forms are delivered by Web3Forms (Web3Creative, India), acting as our data processor. It receives what you typed into the form, together with the technical details any web server sees, such as your IP address, and forwards the form to our inbox by email. Web3Forms states that it does not store form submissions, that its servers are in the United States, and that server logs which may contain personal data are deleted periodically (it states about every two months).

4.9 International transfers

Burge is operated from Türkiye and is available worldwide, so your data will normally be processed outside your own country — the service providers above run on infrastructure in the United States and the European Union, and Web3Forms is operated from India. Where a transfer requires a safeguard, it relies on the providers’ own mechanisms, such as the European Commission’s Standard Contractual Clauses. Search logs contain no identifying information, so the practical risk of any such transfer is minimal; website form data is limited to what you chose to send us.

5. How long we keep it

Search logs are kept for no longer than 12 months. A scheduled job on our database deletes anything older, automatically — it is not a manual promise. In practice rows are often removed sooner, once the quality issue they helped diagnose is fixed. They carry no account identifier, so there are no “yours” to single out — and nothing personal in them to delete.

Usage events (section 2.2b) are likewise kept for no longer than 12 months and deleted automatically by the same kind of scheduled job; the per-minute counter that limits them is deleted within one day.

Abuse-prevention counters (section 2.3, including IP addresses) are kept for 30 days and then deleted.

App-update requests (section 4.5) are handled by Expo, which does not publish a retention period for them. They carry a random installation identifier, never an account identifier.

Website forms (section 2.7) live in our email inbox and are deleted by hand on this schedule: beta sign-ups within 30 days after Burge launches on the App Store, once the launch message has been sent; support messages no later than 12 months after the conversation ends. You can ask us to delete either sooner. Web3Forms does not keep form submissions (section 4.8).

Website visit statistics (section 2.7) are totals kept by Cloudflare for its own reporting period. They contain no identifier, so no visitor can be singled out in them.

6. Your choices and your rights

Delete everything, instantly, from inside the app. Open the Profile tab and tap Delete my account. This permanently removes your account itself and, with it, your email and name (if you signed in with Google), your liked places and your daily search counter. It also erases the recent searches and the approximate last location stored on this phone (section 2.5). It does not remove search logs or usage events — not because we keep them from you, but because nothing marks which ones would be yours. It takes effect immediately, requires no approval from us, and cannot be undone — signing in again with the same Google or Apple account will not bring any of it back. You can carry on using Burge straight afterwards; a fresh anonymous account is created for you. (The abuse-prevention counters in section 2.3 are intentionally not reset — the note there explains why. They expire within 30 days and hold no record of what you searched for.)

Sign out without deleting. Profile → Sign out returns you to an anonymous account. Your data stays on our server and comes back when you sign in again.

Turn off location. On iOS: Settings → Privacy & Security → Location Services → Burge. On Android: Settings → Apps → Burge → Permissions → Location. The app keeps working; you type a location instead.

Turn off the weekly reminder. From version 1.0 (4) Burge can show one reminder a week, around midday on a day chosen at random. Your phone schedules it on its own: there is no push server, no device token, and we cannot tell whether a reminder was ever shown or tapped. Turn it off under Profile → Weekly reminder, or in your phone’s notification settings. If you decline the permission, the app never asks again.

Under the KVKK (Article 11), the GDPR, and comparable laws, you also have the right to learn whether your data is processed, to request access to it, its correction, its erasure, a copy in a portable format, and to object to the processing. If you have signed in, write to us from the email address on your account. If you have not, the data is tied only to a random identifier and we need you to send us the ID shown in the app under Profile → Your ID — we cannot find your rows any other way. Email contact@burge.app and we will respond within 30 days.

Website forms. To leave the beta list, or to have a support conversation deleted, email contact@burge.app from the address you used. We delete it and confirm when it is done.

If you are not satisfied with our response, you may complain to your data protection authority — in Türkiye the Personal Data Protection Authority (KVKK), in the EEA or the UK your national supervisory authority.

7. Children

Burge is not directed to children under 13 (or the equivalent minimum age in your country), and we do not knowingly collect data from them.

If you believe a child has used the app, here is exactly what can and cannot be done — stated honestly rather than reassuringly:

• The account can be deleted, and with it everything attached to it — liked places, the daily search counter, and the email and name if the child signed in with Google. This can be done from inside the app (Profile → Delete my account), or you can contact us and we will do it.
• Search logs cannot be singled out and deleted — by us or by anyone. As section 2.2 explains, those rows carry no account identifier, no session identifier and no IP address, so nothing could tell us which of them came from a particular person or device. This is a consequence of collecting less, not of refusing to help: the rows hold a search word, an approximate area name, a count, and Google place identifiers — nothing that identifies a child or anyone else. They are deleted automatically within 12 months (section 5).

We would rather say this plainly than promise a deletion we could not actually carry out.

8. Security

All communication between the app, our server, Google and our database uses encrypted HTTPS connections.

Our database enforces, at the database level, that every row holding account data — your liked places and your search counter — belongs to exactly one account, and that an account can only ever reach its own rows: reading, writing or deleting anyone else’s is refused by the server, not merely hidden by the app. Search logs are the deliberate exception, in the privacy-protecting direction: they belong to no account at all, and the app may add a row but cannot read or delete any — not its own, not anyone else’s. Requests carry a cryptographically verified token; the app cannot claim to be someone else. The abuse-prevention counters are stricter still: the app cannot read or write them at all, only our own server can.

The key used to call Google is held on our server and is never included in the app you install, so it cannot be extracted from your device.

9. Changes to this policy

We may update this policy as the app changes. The current version is always available at this address, with the effective date shown at the top. If a change materially affects how your data is handled, we will update the effective date and highlight the change here.

What changed on 6 October 2026

The website now counts its visits. Nothing changed in the app.

• Visit statistics (sections 2.6, 2.7, 3, 4.7 and 5). burge.app uses Cloudflare Web Analytics to see how many people visit, which pages they read and which websites sent them. It sets no cookies, stores nothing in your browser and creates no identifier; we see only totals, never an individual visitor.

What changed on 5 October 2026

This policy now also covers our website, burge.app. Nothing changed in the app.

• New section 2.7 — the website. It has no accounts, analytics or tracking. Its beta and support forms collect only what you type — your name, email and, for support, a topic and your message — and are used only to send you the beta link and launch news, or to reply to you.
• New sections 4.7 and 4.8 — Cloudflare and Web3Forms. Cloudflare delivers the website and forwards email sent to contact@burge.app; Web3Forms delivers form messages to our inbox. International transfers moved to section 4.9.
• Cookies (sections 2.6 and 2.7). The app still uses none. The website can receive one security cookie from Cloudflare that tells people apart from bots and expires after 30 minutes of inactivity.
• Retention and contact (sections 5, 6 and 10). Beta sign-ups are deleted within 30 days after launch, support messages within 12 months. Our contact address is now contact@burge.app; mail sent to the old address still reaches us.

What changed on 30 September 2026

This reaches the app in a future update; nothing changed for the version you have installed.

• Free searches counted per device (sections 2.3 and 4.4). Free searches will be a small total per iPhone instead of a daily allowance. To stop reinstalling from resetting them, Apple’s DeviceCheck service stores two bits for your device meaning “how many free searches were used”. We receive no device identifier and store nothing new about you.

What changed on 24 September 2026

Location suggestions got better at finding the place you mean, and we describe a new, anonymous usage log. Both reach the app in a future update; nothing changed for the version you have installed.

• More kinds of places (section 2.4). Suggestions now include streets and well-known places, not only cities and neighbourhoods.
• Your approximate area (sections 2.4, 2.5 and 6). After you have used “Use my location” once, your location rounded to about 1 km is kept on your phone and sent with suggestion requests so that nearby places come first. It is never stored on our server, the app does not ask for location permission for it, and deleting your account erases it. Neither of these suggestion changes stores anything new on our server.
• Anonymous usage events (new section 2.2b; sections 3, 5 and 6). The app will record short events such as which screen was opened or whether the subscription screen was closed, with the app version and country. They carry no account or device identifier — only a random code that changes every visit — never contain what you searched for or where, and are deleted after 12 months.

What changed on 19 September 2026

Two features that arrive in version 1.0 (4) are now described. Nothing changed for versions already installed, and nothing new is stored on our server.

• Location suggestions (section 2.4). The location box can now suggest cities and neighbourhoods. What you have typed is sent to Google, through our server, after three characters and a pause. Two hints travel with it so the suggestions are near you: your phone’s language, and a two-letter country code worked out from your IP address. Neither what you typed nor the country code is stored.
• Weekly reminder (sections 2.6 and 6). An optional reminder, at most once a week. Your phone schedules it by itself — there is no push service and no device token, and we do not learn whether it appeared. It can be switched off in the Profile tab.

What changed on 15 September 2026

Clarifications only. No change to what we collect, why, or who receives it.

• Sections 4.5 and 4.6 now say which app versions they apply to. Over-the-air updates and subscriptions arrive in version 1.0 (4); earlier versions do not contact Expo or RevenueCat at all. Without this note the policy described things an older build never does.
• Corrected the paid tier's wording. It raises your monthly search allowance, not your daily one. The free tier's counter is still daily.

What changed on 13 September 2026

Burge gained an optional paid tier. Nothing about the free app changed.

• New section 4.6 — RevenueCat. Subscriptions are handled by RevenueCat. It receives your Burge account identifier, which product you bought and when it renews, plus your device model, OS and app version. It never receives your payment details — Apple or Google take the money.
• Your subscription is linked to your account. That is what lets the server raise your monthly allowance, and what lets the subscription follow you to another phone.
• Deleting your account does not cancel a subscription. Section 4.6 says where to cancel, and says to do it first.

What changed on 12 September 2026

Burge gained the ability to update itself without a new store release. This revision adds one recipient, Expo, and describes exactly what reaches it.

• New section 4.5 — Expo. Every launch now asks Expo whether a newer version of the app exists. The request carries a random installation identifier, the platform, the native version, the release channel, and — after a crash — a short technical error message. No account identifier, no search term, no location.
• Deleting your account now also clears your recent searches from the phone. They are stored on the device, so the server-side deletion never reached them and they survived. Section 2.5 now lists them among what the app keeps on your phone — they were not described there before.
• Crash messages are disclosed, not hidden. The update mechanism sends the previous launch’s fatal error so a broken update can be rolled back. It cannot be disabled separately, and Burge’s own error messages are fixed strings containing no search or location data.

What changed on 8 September 2026

Every change in this revision reduces what we collect. Nothing new was added.

• Sign in with Apple no longer gives us your name or your email address. We stopped asking Apple for them — not even a Hide My Email relay address. Matching you across devices uses an opaque identifier instead. (Google's sign-in SDK still sends both and offers apps no way to turn that off; section 2.1 says so plainly.)
• Search logs are no longer connected to your account. We removed the account identifier from them, so those rows can no longer be traced to you — by us or by anyone else. The practical trade-off is stated in section 2.2: we can no longer show them to you or delete them on request, because nothing marks which ones would be yours.

A review on the same day also corrected three statements that no longer matched how the app works: the location-consent paragraph in section 3 said “iOS” although Burge runs on Android too; section 7 promised to delete a child’s search logs on request, which the change above had made impossible; and section 8 described every row as belonging to an account, which is no longer true of search logs. Section 5’s twelve-month limit is now enforced by a scheduled deletion job rather than left as an intention.

10. Contact

Questions, data requests, or anything else: contact@burge.app