Privacy policy
Last reviewed
How we collect, use, share and protect your personal information, and what you can do about it. Written for the Protection of Personal Information Act 4 of 2013 (POPIA).
Who is responsible for your information
We are the responsible party for the personal information described in this policy. Our company details and the name of our Information Officer appear at the end of this page.
This policy covers the service you access through this website and applications. It does not cover other companies' websites we link to; when you leave, their policies apply.
What we collect
We collect what we need to run the service and nothing we have no use for. The table below is generated from our actual system configuration rather than written by hand, so it lists the categories our systems really process.
We do not collect special personal information (such as health, religious or biometric data) or the personal information of children, and the service is not offered to people under 18.
| Category | What this means | Shared with |
|---|---|---|
| account-identifiers | Your name, email address and the account identifiers we generate for you. | xneelo Cloud (Johannesburg), Resend, Trigger.dev (self-hosted, Johannesburg), Cloudflare R2, Hetzner Object Storage, PostHog (EU cloud), Sentry (EU org), Paystack, Lemon Squeezy, Meta (WhatsApp Business Cloud API), GitHub, Discord |
| content | What you create, upload or send while using the service, including message bodies and files. | xneelo Cloud (Johannesburg), Resend, Cloudflare R2, Hetzner Object Storage, Anthropic, OpenAI, Groq, Meta (WhatsApp Business Cloud API) |
| payment-metadata | Amounts, currencies, references and subscription state. We never receive or store your card number. | xneelo Cloud (Johannesburg), Paystack, Lemon Squeezy |
| none-pii | Infrastructure that carries traffic or schedules work without seeing information about you. | Cloudflare (DNS/TLS proxy), Upstash QStash |
| delivery-metadata | Whether a message we sent you was delivered, bounced or was opened where that is measured. | Resend, Meta (WhatsApp Business Cloud API) |
| usage-analytics | Pages viewed and product events. Aggregate and pseudonymous unless you opt in to per-person analytics. | Plausible Analytics, PostHog (EU cloud) |
| diagnostics | Error traces and technical logs generated when something goes wrong. | Sentry (EU org) |
Why we process it, and on what basis
To provide the service you signed up for: create and secure your account, deliver the product, process payments and send you the messages the service depends on, such as receipts, password resets and security alerts. This processing is necessary to perform our contract with you.
To keep the service safe and working: detect abuse, investigate incidents, fix errors and meet our own legal obligations, including tax record-keeping.
Where we rely on your consent — direct marketing, optional AI features and per-person analytics — you choose, and you can change your mind. Withdrawing consent stops the processing it covered; it does not undo processing that already happened lawfully.
POPIA s.11 sets out the grounds on which personal information may be processed. Where we rely on a legitimate interest, we have considered whether it is outweighed by your interests, and you may object.
Who else processes your information
We use the operators below to run the service. Each one is named with what it does, where it processes data, and which categories of information it receives. This list is generated from our configuration — if we change a provider, this page changes with it.
Application compute and the primary database run in South Africa. Every offshore sub-processor is named below, justified, and swappable.
| Provider | Purpose | Region | Data shared | Why / safeguards |
|---|---|---|---|---|
| xneelo Cloud (Johannesburg) | Application hosting and primary database | South Africa | account-identifiers, content, payment-metadata | South African company operating a single region and availability zone in Johannesburg, so application compute and the primary database run in-country. Be precise about what that is and is not: the in-country claim rests on that single-region architecture, not on a contractual residency guarantee — xneelo publishes none, and their group includes a non-SA entity. Data-processing terms come via their Terms of Service. No POPIA certification is claimed, because no certification scheme exists. |
| Cloudflare (DNS/TLS proxy) | DNS, TLS termination and DDoS protection | United States | none-pii | Traffic transits JNB/CPT edge POPs; only connection metadata is processed, no stored PII. Covered by DTA schedule (transit clause). |
| Resend | Transactional email delivery | United States | account-identifiers, delivery-metadata, content | All Resend account data, message metadata and logs are US-stored regardless of send region. Necessary for performance of the user relationship (s.72(1)(b)) and contracted via DTA. |
| Trigger.dev (self-hosted, Johannesburg) | Background jobs and scheduled tasks | South Africa | account-identifiers | Self-hosted on the same Johannesburg box; job payloads never leave SA. |
| Upstash QStash(optional) | Pure-cron scheduling alternative (docs/jobs.md) | United States | none-pii | Only receives schedule 'ticks' — endpoints and cron expressions, never payload data (runDueJobs pattern keeps data on-box). |
| Cloudflare R2 | File storage — default adapter (lib/storage/r2.ts, prompt 20) | United States | content, account-identifiers | Cloudflare, Inc. is US-incorporated. A bucket jurisdiction hint constrains where objects rest but NOT who operates them, so US legal process still reaches the operator regardless of the region chosen. Uploads may contain PII; contracted via DTA. Chosen for zero egress fees. |
| Hetzner Object Storage(alternative) | File storage — documented swap adapter (lib/storage/hetzner.ts, prompt 20) | European Union | content, account-identifiers | EU-hosted (Falkenstein/Nuremberg/Helsinki) under a GDPR-adequate regime. It is an unrelated third-party processor with no relationship to the Johannesburg compute, so it adds a processor rather than consolidating one; the only thing it buys over R2 is an EU rather than a US operator. Files still leave South Africa: this reduces the transfer's reach, it does not eliminate the transfer. |
| Plausible Analytics | Web analytics | European Union | usage-analytics | Cookieless and pseudonymous by design (no persistent identifiers); EU-hosted (GDPR-adequate regime). |
| PostHog (EU cloud) | Product analytics, feature flags, session replay | European Union | usage-analytics, account-identifiers | EU-region cloud selected at project creation; US parent company disclosed. Replay masks inputs by default. Contracted via DTA + PostHog DPA. |
| Sentry (EU org) | Error monitoring (optional — inert with no DSN, prompt 36) | European Union | diagnostics, account-identifiers | EU data-storage org — Frankfurt, region code `de`. The location is chosen at ORG CREATION and is irreversible; the only way to change it is to create a new organisation. IMPORTANT CAVEAT: only telemetry (errors, spans, replays, source maps) is EU-stored. User accounts, organisation settings, auth tokens and SSO metadata are stored in the US regardless of the region selected. The kit sends no PII by default (sendDefaultPii: false; URLs are query-stripped before send), so what crosses the border is diagnostics. Browser beacons are proxied first-party via a Cloudflare Worker on SA POPs (JNB/CPT/DUR) — that is ad-blocker and DNS-filter resilience, not a change of destination: the envelope still lands in Frankfurt. US parent disclosed; DPA + DTA. |
| Anthropic | AI inference (primary provider, prompt 21) | United States | content | US inference disclosed to users at the AI feature surface; zero-data-retention configuration documented (prompt 21). Consent-based ground (s.72(1)(a)) for AI features. |
| OpenAI(optional) | AI inference (fallback provider) | United States | content | Same treatment as Anthropic; only active when configured. |
| Groq(optional) | AI inference (fast/cheap fallback) | United States | content | Same treatment as Anthropic; only active when configured. |
| Paystack | Payments (SA default provider) | South Africa | account-identifiers, payment-metadata | SA-licensed acquirer processing rand transactions locally; card data never touches the kit (hosted checkout). |
| Lemon Squeezy(optional) | Global/USD sales via merchant of record (lib/payments/providers/lemonsqueezy.ts, ADR 003) | United States | account-identifiers, payment-metadata | US merchant of record for USD sales: the seller of record for the purchases it processes, while the kit transmits the buyer's email and user id at checkout creation and receives subscription and payment metadata on webhooks. Necessary for performance of the sale (s.72(1)(b)) — Stripe still does not settle to SA entities (ADR 003), and rand sales stay in-country with the SA default provider. |
| Meta (WhatsApp Business Cloud API)(optional) | WhatsApp notifications (prompt 34) | United States | account-identifiers, content, delivery-metadata | Cloud API hosts message processing on Meta infrastructure; opt-in channel — users consent via <WhatsAppOptIn /> (s.72(1)(a)). |
| GitHub(optional) | Licence delivery — organisation team membership grants read on a tier's delivery repository (lib/fulfilment/github.ts, ADR 005 Decision 2) | United States | account-identifiers | GitHub, Inc. (a Microsoft subsidiary) is US-incorporated and stores organisation and membership data in the United States. The buyer supplies a GitHub username at checkout and fulfilment adds it to the team matching their tier, so GitHub holds the mapping between a paying customer and their access — and organisation membership is visible in ways people do not always expect. Necessary for performance of the sale (s.72(1)(b)): the repository cannot be delivered without it, which is also why the ground is contract and not consent. |
| Discord(optional) | Community access — a tier role assigned from the licence record (lib/fulfilment/discord.ts, business/discord-runbook.md §7) | United States | account-identifiers | Discord, Inc. is US-incorporated and stores member data in the United States. A buyer who supplies a Discord handle at checkout has it linked to their licence tier, and the role that results is visible to every other member of the server — so the transfer discloses not just who they are but what they bought. Consent-based (s.72(1)(a)) and not contract, which is the difference from GitHub above and is load-bearing: the handle is OPTIONAL at checkout, the community is a benefit rather than a delivery mechanism, and a buyer who leaves it blank still receives everything they paid for. |
Information that leaves South Africa
Our application and its primary database run in South Africa. Some of the operators above are outside the country, and the table states which and why.
POPIA s.72 restricts transferring personal information out of South Africa. Where we do so, we rely on contractual protections with the recipient that require a comparable level of protection, on the transfer being necessary to perform our contract with you, or on your consent — as indicated for each operator.
Being hosted in a country is not the same as being controlled from one. Where an operator stores data in Europe but is owned by a company elsewhere, we say so rather than implying otherwise.
How long we keep it
POPIA s.14 requires that records are not kept longer than necessary. Our retention periods are configured in one place and enforced by an automated sweep — the table below is that configuration, not a description of it.
When you delete your account we tombstone it immediately, which removes it from the service, and then erase it permanently after the period below. Tax invoices are an exception: we are required to keep them for five years, so they are detached from your account rather than deleted.
| Records | Kept for | Why |
|---|---|---|
| Database backups | 30 days | Disaster recovery only; s.14 requires deletion once the purpose lapses. |
| Deleted accounts (before permanent erasure) | 30 days | Grace window for mistaken deletions; hard delete inside the s.14 'reasonable period'. |
| Message delivery log | 365 days | Delivery-dispute resolution; addresses are scrubbed on account deletion regardless. |
| Security and audit trail | 1 095 days | Security-incident reconstruction (3 years, aligned with breach-response runbook). |
| Tax invoices | 1 825 days | SARS: records supporting tax returns must be kept 5 years. |
| Waitlist and lead-capture addresses | 730 days | Consent to be told about a launch does not survive indefinitely; unconverted entries are erased once the purpose has lapsed (s.14). Not a statutory period — a stated policy. |
| Licence purchases | 1 825 days | SARS: records supporting a tax return are kept 5 years, and a licence is the record of a sale. Not swept — a perpetual licence is the standing answer to who has access; the personal information in it is scrubbed on account deletion instead (s.14 read with s.24). |
| Revoked licences (buyer details) | 730 days | A reversed payment is a dispute record, not a permanent character reference: the sale and the revocation are retained under `licences`, while the buyer's usernames are erased once every dispute window has long closed (s.14). Not a statutory period — a stated policy. |
Marketing email
POPIA s.69 restricts electronic direct marketing. We send marketing email only to people who have opted in, and every marketing message carries a working unsubscribe link.
Your opt-in is recorded with the date and the exact wording you agreed to. If you withdraw it, the withdrawal is recorded too, and our sending system re-checks consent at the moment of sending — not when a campaign was drafted — so a withdrawal takes effect immediately.
Service messages are different. Receipts, security alerts, and notices about your account are part of the service and are not marketing.
Your rights
You may ask what personal information we hold about you and receive a copy. POPIA s.23 gives you this right, and the service provides a self-service export that produces a machine-readable copy immediately.
You may ask us to correct information that is wrong or incomplete, and to delete information we no longer have grounds to keep. Account deletion is self-service; where the law requires us to keep a record, such as a tax invoice, we will tell you what we kept and why.
You may object to processing we base on a legitimate interest, and you may withdraw any consent you have given.
You may also lodge a complaint with the Information Regulator. We would rather you told us first, but you do not have to.
How we protect it
Data is encrypted in transit. Passwords are stored as hashes and never in a form we can read. Access to production systems is limited to people who need it, and administrative actions are recorded in an audit trail.
No system is perfectly secure. If personal information is compromised in a way that creates a real risk to you, we will notify you and the Information Regulator as the law requires.
Children
POPIA s.34 prohibits processing the personal information of children except in limited circumstances. The service is not offered to people under 18 and we ask for confirmation of age at sign-up. If you believe a child has created an account, contact us and we will delete it.
Complaints
Contact our Information Officer first — the details are at the end of this page. If you are not satisfied, you may complain to the Information Regulator (South Africa), which supervises both POPIA and the Promotion of Access to Information Act 2 of 2000 (PAIA).
Our PAIA manual, which explains what records we hold and how to request them, is available on request.
Changes to this policy
We update this policy when what we do changes. The review date at the top tells you when it was last read end to end, and material changes are announced in the product before they take effect.
The English version of this policy governs if a translation differs from it.