Klub Kitanda — Privacy Policy

Last updated: 28 August 2026 · Version 2.0

The short version

There are two kinds of people in Klub Kitanda, and this policy covers both.

If you use the app to find events, you have no account. We never ask for your name, your phone number, your email or your address. The only thing we collect is a random number that identifies your installation of the app — not you — attached to a count of which events got tapped. Your saved events, your recent searches and your settings stay on your phone.

If you list events, you have an account. Vendors sign up with an email and a password and give us real business details — including a phone number we will actually call — because a human reviews every vendor before their listings can go live. That is real personal data, we hold it, and section 8 says exactly what it is and what happens to it.

If you are in Kenya, this policy is written against the Data Protection Act, 2019 (No. 24 of 2019) and the regulations made under it.

1. Who we are

Klub Kitanda is a curated events-discovery service for Nairobi. We publish listings in a mobile app and on event pages at klubkitanda.co.ke.

• Data controller: Klub Kitanda, operating from Nairobi, Kenya. Klub Kitanda is the operating name of the business that runs this service, and it is the controller for everything described here.
• Contact for anything in this policy: info@klubkitanda.co.ke
• Instagram: @klub_kitanda

2. If you are here to find events

You have no account and no login. There is nothing to sign up for, and we hold no name, email or phone number for you.

These stay in the app's own storage on your phone. They are not uploaded, not backed up to us, and not readable by us:

• The events you save
• Your recent searches
• Which vibes you tap most, which is how the "for you" row is built
• The cached copy of the events list, so the app opens when the network doesn't
• The reminders you have set, and what the app has already told you about them
• The organizers you have chosen to hide, if you use that option

Deleting the app deletes all of it. There is nothing on our side to delete, because there was never anything on our side.

3. The one identifier we do collect — and what it actually is

When you first open Klub Kitanda, the app generates a random UUID (a 36-character random string) and stores it on your device as your install ID. It looks like f47ac10b-58cc-4372-a567-0e02b2c3d479.

We are calling this what it is: pseudonymous personal data, not anonymous data.

That distinction matters and we would rather over-disclose it than hide behind the word "anonymous". Under the Data Protection Act, 2019, personal data includes data that can identify a person indirectly. A random per-install identifier does not name you, but it does single out one device consistently over time — so Kenyan law treats it as personal data, and so do we. Calling it "anonymous" would be legally wrong, and we would rather say so plainly in our own policy than be corrected later.

What is true about it:

• It is random. It is not derived from your phone, your SIM, your Google or Apple account, or any hardware identifier. It is generated on your device the first time the app runs.
• It is linked to nothing personal. For app users we hold no name, no email, no phone number and no account — there is nothing on our side for it to be joined to.
• It is not an advertising ID. We do not read the Android Advertising ID or Apple's IDFA, and we do not ask for tracking permission, because we do not track you across other companies' apps or websites.
• Reinstalling the app resets it. Delete and reinstall Klub Kitanda and you get a fresh random ID; the old one is orphaned and will never be connected to the new one.

What it is for, honestly: counting people rather than taps. Without it we cannot tell whether 300 booking taps came from 300 people or from one person tapping 300 times — which means we cannot tell a vendor anything trustworthy, and those reports are how a free curated listing service survives. It also caps a single device's contribution to any one event's numbers, so nobody can inflate their own report.

4. What we record alongside it

One table. Every row is one tap, and every row holds six things: what happened, which event it was about, whether it came from the app or from a shared web page, the install ID, the time, and a little context — for example which share sheet you used, or the words you searched for.

The fixed list of things we record: opening the app, viewing an event, tapping Book, tapping through to WhatsApp, tapping Directions, tapping Share, saving or unsaving an event, submitting a search (the words you searched for are recorded, which is how we find out what Nairobi wants that we aren't listing), viewing a shared event page on the web, tapping an app-store badge on that page, restarting the app to apply an update, hiding or un-hiding an organizer (the row records which organizer — the list of who you've hidden stays on your phone, but the tap itself is a tap like any other), and — for vendors only — publishing, drafting, archiving, copying or deleting their own listings and saving their space.

The shared event pages on the web carry no identifier at all. They set no cookies, load nothing from a third party, and the page view they count is not attributed to any install ID or any person. A link opened from a WhatsApp thread on mobile data is the most data-sensitive surface we ship, and it is built accordingly.

Searches: we record the search text. Please don't type anything personal into it — it is a venue-and-vibe search box, and we treat what's in it as a signal about the city, not about you.

5. The permissions the app asks for, and what each one really does

The app asks for three permissions, all of them optional, all of them refusable without losing the app:

• Location, once, when you tap "Nearest first". We take a single coarse fix, use it to sort the list on your phone, and hold it in memory for that session only. Your coordinates are never sent to us and never stored. Say no and the list simply keeps its curated order.
• Notifications, if you want a reminder before an event you saved, or an alert when something you saved is cancelled or moved. These are local notifications: your phone schedules them from data already on your phone. There is no push service, no push token, and nothing about your reminders leaves your device.
• Photos, only in the vendor console, and only when a vendor taps to add a poster or a logo. The images a vendor chooses are uploaded and published with their listing. We never open the photo library on a consumer's phone, because nothing in that half of the app can.

6. What we deliberately do not collect

This list is enforced by those columns not existing in our database, not by a promise:

• No IP addresses in our database. Our hosting providers necessarily see the network address a request comes from, as every web service does, and Vercel's edge logs hold request data briefly — but no IP address is written to, or readable from, anything we run.
• No device fingerprint — no model, OS version, screen size, locale, carrier or timezone.
• No advertising identifiers, no IDFA, no GAID, no tracking prompt.
• No stored location. See section 5: the one location fix never leaves your phone.
• No contacts, camera, microphone or calendar access. "Add to calendar" opens a pre-filled Google Calendar page in your browser — we never read your calendar.
• No third-party analytics SDK. No Google Analytics, no Firebase, no Mixpanel, no Amplitude, no Meta SDK, no attribution SDK, and no third-party crash-reporting service. Nothing on your phone is reporting to anyone but us: the tap table in section 4, and the crash table described just below.
• No data sold, and no data shared for advertising. Ever. Selling user data is explicitly outside the business model.

Crash reporting exists, we run it ourselves, and here is exactly what it receives. When the app crashes, it writes one row to a second write-only table in our own database — no third-party service. The row holds: the error message, the app's own stack trace (which names our code files, nothing of yours), the screen it happened on, the app version, the update version, and the install ID from section 3. It exists so a crash on a mid-range handset reaches us instead of silently costing someone their evening. Crash rows are deleted after 90 days.

7. Consumers and vendors are held apart

The app's public key can read published listings and write taps and reports, and can read nothing else. It cannot read the taps table back, cannot see draft events, cannot see any vendor's contact details, and cannot see our internal notes. That is enforced by database row-level security, not by app code.

A vendor account can read and edit its own row and its own listings, and nothing belonging to anyone else. The approval fields — approved, rejected, suspended — are not writable by a vendor at all: that is a database permission, not a rule in our app that somebody could forget to check.

8. If you list events: the vendor account

This section is about a different set of people, and it is real personal data throughout.

What you give us when you sign up: your email address and a password (the password is handled by our authentication provider and stored only as a hash — we never see it), your name, your company or space name, your phone number, your physical address, your KRA PIN if you have one, and your Instagram handle.

What you can add afterwards in Your space: your venue or space name, its address and area, a Google Maps link and the coordinates we derive from it, your logo, a short bio, and your website.

What you add per listing: everything you type into an event — title, description, dates, venue, prices, ticket link, WhatsApp booking number, age caveats — and the photos you upload for it.

What we generate about you: whether your account is pending, approved, rejected or suspended, the reason if we rejected it, and our own notes about the review.

What it is used for: deciding whether to approve your account, talking to you about your listings, and publishing what you asked us to publish. Nothing else. It is never sold, and never used to market anything unrelated to your listing.

What actually becomes public: your company or space name, your Instagram handle and your logo — the three things you would put on a poster — plus the listings themselves. Your email, phone number, KRA PIN and physical address are never published, are not readable by the app's public key, and are not visible to other vendors. Your phone number is visible to the human reviewing your account, because the review usually involves a phone call.

Why we ask for a KRA PIN. It is optional, and it exists for one reason: it helps us tell a real registered business from someone who typed a plausible name into a form. It is used in the approval decision and nowhere else. We do not file anything with it, and we do not share it with the Kenya Revenue Authority or anyone else.

Deleting your account. In the app: Your space → Delete my account. It is a real delete, not a flag — your account and your vendor record, including your email, phone, address, KRA PIN and our notes about you, are removed. You can also email info@klubkitanda.co.ke and we will do it for you.

Two honest caveats about that delete. Listings you already published stay up, without an owner — a link that has been pasted into a hundred WhatsApp threads should not turn into a dead page for the people who received it. Tell us if you want them taken down too and we will pull them. And images you uploaded are not deleted automatically, because a published listing may still be showing them; ask and we will remove specific ones.

9. Why we're allowed to process this

Under section 30 of the Data Protection Act, 2019:

• The install ID and the taps (sections 3 and 4): legitimate interests. Running and improving a curated listings service, and reporting aggregate interest back to the vendors whose events we list. We think this is proportionate because the data is minimal, it is pseudonymous, it is not used to profile or target you, and the alternative — a consent wall on first open, for a counter — would be worse for you than the processing itself.
• The vendor account (section 8): performance of a contract, plus our legitimate interest in checking that a business is real before we publish it to the city. If you want a listing on Klub Kitanda, we need this data to give you one.
• Location, notifications and photos (section 5): your consent, given at the operating system's own permission prompt, and withdrawable in your phone's settings at any time.

10. Who else touches the data, and that it leaves Kenya

Four service providers, and all of them host data outside Kenya:

• Supabase — our database, vendor authentication and image storage. It holds the events catalogue, the taps table in section 4, the reports, and the vendor records in section 8. Region: eu-central-1, Frankfurt, Germany.
• Resend — transactional email only: confirming a vendor's email address, and telling a vendor their account was approved or rejected. It sees the email address and the message. Region: eu-west-1, Ireland.
• Vercel — hosting for klubkitanda.co.ke, the shared event pages and the legal pages you are reading. It serves pages; its edge logs may briefly hold request data. Global edge network.
• Expo (EAS) — building the app and delivering its over-the-air updates. It sees update requests from installs; none of the data in this policy passes through it.

Sections 48 and 49 of the Data Protection Act, 2019 govern transferring personal data out of Kenya. Our position, stated plainly: the transfer is necessary to provide the service you opened the app to use, or to run the account you asked us for; the data is limited to what is described above; no sensitive personal data is involved; and each of these providers offers contractual data-protection terms that we accept and keep on file.

11. How long we keep it

• Tap records (section 4): 24 months, then deleted. This is enforced by a scheduled job in the database, not by somebody remembering — rows older than 24 months are removed automatically.
• Crash reports (section 6): 90 days, then deleted, the same way.
• Reports about listings: kept while we are acting on them, and afterwards as the record of what was reported and what we did about it.
• On-device data (section 2): until you delete it or delete the app. We can't touch it.
• Vendor records (section 8): while the account exists. Delete the account and the record goes with it, immediately. We keep the record of what was published and when, because that is the record of what the city was told.

12. Your rights under the Data Protection Act, 2019

Whether or not you use the app, if we hold personal data about you, you have the right to:

• be told what we hold and what we're doing with it (section 26 — this policy is our standing answer);
• access a copy of it (sections 26 and 27);
• object to the processing;
• have false or misleading data corrected or deleted (section 26);
• have data erased where the grounds in section 40 apply.

If you have a vendor account, all of this is easy. Email us from the address on the account and we will answer it. Deletion you can do yourself, in the app, in two taps.

If you are an app user, there is a practical difficulty and we would rather state it than dress it up. We hold no name, email or account for you, so we usually cannot find your records from a description of you. The only key is your install ID, and the app does not currently display it.

So, honestly, there are two routes:

1. Delete the app. This is immediate, needs nobody's help, and works: the install ID goes with it, and the orphaned rows can never be re-associated with your new install. They then age out under section 11 in any case.
2. Email us at info@klubkitanda.co.ke. If you can give us the install ID we will delete every row carrying it. If you cannot — because we do not show it to you — then we genuinely cannot identify which rows are yours, which is a consequence of holding so little rather than an excuse for holding it. Tell us anyway; we would rather know that the route matters to people.

We respond to requests within 7 days wherever we can, and in any case within the timeframe the Act requires. There is no charge.

If we get it wrong, you can complain to the Office of the Data Protection Commissioner: complaint@odpc.go.ke · www.odpc.go.ke · Britam Towers, 12th Floor, Hospital Road, Upperhill, Nairobi. You do not need to come to us first, though we would like the chance to fix it.

13. Children, and 18+ listings

Klub Kitanda is a general-audience app. Most of what we list is all-ages and much of it is daytime.

Some listings carry an 18+ caveat, which comes from the organiser's own flyer or message and is displayed on the listing. The app does not verify anyone's age — the venue and the organiser decide who gets in, and they are the ones who check ID at the door.

We do not knowingly collect personal data from children. Under section 33 of the Act, processing a child's data needs the consent of a parent or guardian; since we collect no name, email or account from anyone using the app to find events, there is nothing child-specific for us to collect. Vendor accounts are for businesses and the people who run them, not for children. If you believe a child has been using the app in a way that concerns you, write to us.

14. Security and breaches

Access to everything described here is controlled at the database, not in app code: row-level security decides what each key can see, and column-level permissions decide what a vendor account can write. The one administrative door — approving, rejecting and suspending vendors — runs on a separate credential that the app has never held.

If a breach affecting personal data occurs, we will notify the ODPC in line with section 43 of the Act (within 72 hours where the Act requires it) and tell affected people directly where there is a real risk to them. For vendors that means an email and a phone call the same day.

15. Changes to this policy

We will post the new version here with a new date at the top, and we will not quietly widen what we collect. Any change that adds a new category of data ships after the policy that describes it, not before.

Related: our Terms & Conditions and, if you list events with us, the Listing Policy.

Sources checked while drafting

• Data Protection Act, No. 24 of 2019 — Kenya Law
• Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021 (LN 265/2021) — ODPC copy
• ODPC FAQs and contact details — odpc.go.ke/faqs
• Cross-border transfer, sections 48–49 — CMS, Transfer of Personal Data Outside Kenya