Version: 1.2.2 Last updated: 24 September 2026 Effective date: 24 September 2026
*1.0.1 corrects one factual claim in §5 about Google Places (see the Google Maps Platform row). 1.0.2 updates §9: vendor account deletion is now available inside the app, so the previous email-only instruction for vendors is withdrawn (the email route remains as an alternative). 1.1.0 adds a new, pseudonymous data class: records of which vendor listings you're shown and what you do next, used to improve vendor recommendations (new §3A row, a new §4 lawful-basis row, §12 rewritten, and a retention carve-out added to §7). It ships together with an in-app notice and a Settings toggle — see §12. Nothing about what we collect, share or keep for any other feature has changed. 1.1.1 is a clarification, not a new data class: it discloses that opening a vendor's listing is recorded against your wedding (never which of you did it) so the vendor can see counts and broad patterns — a practice that predates 1.1.0 and was not described from the couple's side (new §3A row "Vendor listing activity", §3C reworded, one sentence in §5); it also corrects two omissions — the AI concierge's automatic context includes your venue city/province, and inspiration links you save are stored along with the page title, excerpt and preview image we fetch (§3A). Nothing new is collected by 1.1.1; less is — the individual-user reference on those listing-activity records was removed on the same day. 1.1.2 collects nothing new either, and deletes considerably more: an audit found that the automated day-60 erasure reached only 25 of the 47 tables holding wedding data, so your event schedule and venue address, your brief, your supplier shortlist and private notes, your custom RSVP questions and your published wedding site were being retained past the point §7 says they are deleted. They are now erased, and the weddings already purged under the incomplete process were cleaned on the same day. §7.4 additionally spells out three things it previously left to inference — what happens to a review you wrote, a meeting a vendor held with you, and an accommodation booking — in every case the other party's record survives and your name comes off it. 1.2.0 is a material change: the app now includes PostHog's analytics SDK and uses it for product analytics (which screens are opened — names only, never contents) and masked session replay (a visual recording of how the app was used, with everything you type and every image blacked out on your device before anything is sent). Until this version §12 said no such SDK was installed — that was true until this version, and §12 now describes exactly what changed, what is collected, what is not, and the honest limits of the masking. A new §4 lawful-basis row covers it. Nothing about what we collect for any other feature has changed. 1.2.1 collects nothing new and deletes more: an audit on 13 September 2026 found that the automated day-60 erasure left two things behind. Your gift registry banking details stayed in the encrypted store they live in, because deleting the wedding-website brief destroyed the pointer to them rather than the details themselves; and a guest's name could survive inside the notification we create for you when that guest replies to your invitation. Both are now erased, and §7 names the registry banking details explicitly. §3A additionally describes something the policy had not described before, which you can already do in principle and which is currently switched off in the app: adding a supplier who isn't on planna by typing in their business contact details. 1.2.2 collects nothing new. It says plainly something §7 had not said: a proof of payment you send a vendor (a deposit or balance slip) is kept by that vendor as their payment record after you delete your account, with your name taken off the record around it. The slip itself is not altered (§7, point 4).*
This policy is written in plain language, and it describes what the app actually does — every claim in it is checked against the running product, and when the product changes in a way that matters, this document changes with it (see §13).
This policy explains what personal information planna collects, why, who we share it with, how long we keep it, and what rights you have — in plain language wherever POPIA (the Protection of Personal Information Act) allows, and in precise legal language wherever it doesn't.
Who this policy is for: anyone who uses the planna app or website — couples planning a wedding, guests invited by a couple, and vendors (venues, photographers, caterers and other wedding suppliers) who list on or use planna. Sections 3, 5 and 9–10 are organised by which of these you are, because what we collect and your rights differ meaningfully between them.
planna ("planna", "we", "us") is operated by:
Plan Technologies (Pty) Ltd
Registration number: 2026/417875/07 (CIPC enterprise name: PLAN TECHNOLOGIES)
Registered address: 4 Alexander Street, Paarl, 7646, South Africa
Trading as planna at planna.co.za (marketing site) and app.planna.co.za (the
app and all guest-facing/public pages — RSVP links, invites, wedding websites).
Under POPIA, planna is the Responsible Party for the personal information described in this policy, except where we act as an Operator on a couple's behalf for guest data they've entered (explained in §3B and §10).
Information Officer (POPIA §55–56 requires every responsible party to have one, registered with the Information Regulator):
Igno Ferreira
Founder and Director, Plan Technologies (Pty) Ltd
Email: [email protected]
*Registered with the Information Regulator on 3 August 2026 — registration
number 2026-063635 (organisation: Plan Technologies t/a Planna; verifiable
on the Regulator's eServices portal).*
This policy covers the planna mobile app (iOS, and Android where available) and every public web surface at app.planna.co.za (RSVP pages, wedding websites, partner-invite links). It does not cover third-party sites you may reach by following a link a couple or vendor has added to their own content (for example, an external registry link a couple pastes into their wedding website) — check the third party's own policy there.
What · Where it lives / how it's protected
Account sign-in: email + password (we never see or store your raw password — it's hashed by our authentication provider, Supabase Auth), or an Apple/Google sign-in handshake if you use those instead · auth.users (managed by Supabase Auth); exchanged via Sign in with Apple / Google OAuth — we receive an identity token, never your Apple/Google password
Profile: your name, phone number, avatar photo · profiles table — only you can read or edit it
Wedding details: both partners' names, wedding date, venue city/province, guest count, budget total, style preferences, which vendor categories you're planning · weddings table
Wedding website content: your love story, venue/travel notes, FAQ answers, gift registry link or message — this becomes visible to the public on your own wedding website URL once you switch on the corresponding section and publish · wedding_website_brief table
Gift registry banking details — only if you choose a bank-account-based registry instead of a link/donation option. Kept encrypted, separately from the rest of the table, and only retrievable by you · Stored via Supabase Vault (encrypted secret store), never in plain text in the database
Messages you send to vendors — enquiries, replies, quote conversations · messages table
Budget: your category names, allocations, and payment records (amounts, due/paid dates, notes, receipt photos) — we never share this with any vendor, by design · budget_categories / budget_payments tables
Photos: your profile photo, inspiration-board images, wedding website photos · Supabase Storage, in buckets referenced by your account
Inspiration links: web addresses you save to an inspiration board (Pinterest, Instagram, YouTube or any page), together with the page title, short excerpt and preview image our server fetches from that address so the card has something to show, and which site it came from · inspiration_items table
AI concierge chat: anything you type to the planna AI assistant, plus wedding context (date, guest count, budget total, venue city/province, partner names) that's automatically added so the assistant has context, plus anything the assistant reads back from your vendor conversations when you ask it to · copilot_conversations / copilot_messages tables; processed via OpenRouter (see §5 and §6)
Contacts you import from your phone, if you use "Import contacts" to build your guest list. With your permission, the app reads your device address book on the device only to show you a pickable list. Your address book is never uploaded. Only the entries you actually select — their name, and the phone number or email you picked — are saved, and they are saved as guests · guests / guest_parties tables. The unselected contacts never leave your phone and are never sent to us
Notification preferences, app tour progress, and similar settings · user_preferences table
Co-planner invites: if you invite a partner or helper, we store the email address you invited and their acceptance status · wedding_members table
Suppliers you add yourself: if you (or a planner working with you) add a supplier who isn't on planna, we store the business name and the business contact details you type in for them (an email address, a phone number, or both), so you can keep that supplier in your plan and, if you choose, invite them to claim their own listing. Those details are about a business, entered by you, and they stay private to your wedding: the placeholder isn't published, isn't searchable, and doesn't appear to any other couple · vendors table, on rows marked as unlisted placeholders and linked back to your wedding and to whoever typed them in
Account closure timeline: if you close your account, we record when and when it's due to be permanently purged · weddings / profiles tables
Vendor listing activity: when you open a vendor's profile, or tap through to it from a list, we record that your wedding viewed that listing — the wedding, never which of you did it — so the vendor can see how many couples looked at their listing, how many came back, and broad patterns (province, season, guest-count and budget bands, and only ever in groups of five or more). Vendors see counts and patterns; they cannot see which couple. The link to your wedding is removed when your account is purged (§7) · vendor_events table — carries a wedding reference and a per-app-launch session key, no user reference; not readable by vendors as individual rows, only as totals
Vendor-recommendation activity: pseudonymous records of which vendor listings you're shown across Explore, the vendor grid, search, and the AI concierge — where in the list, whether you viewed or tapped one, and what you did next (enquired, shortlisted) — together with your search context in broad bands (wedding month, province, a budget range, a guest-count range). Never what you typed, never your exact budget. It's not linked to your name or account, except that a listing you enquire about is linked to that enquiry, and through it to the other listings you were browsing at the time, until you delete your account or turn this off. Full detail, retention, and the control to turn it off are in §12 · search_impressions table — carries no name, no account reference. The one exception is described in §12
This is the section that needs your closest attention if you're a guest, because you may never have opened the planna app or agreed to anything — a couple planning their wedding enters your details on your behalf so they can track RSVPs, seating, and dietary needs.
Under POPIA, in this situation the couple is the party who decided to collect your information, and planna holds and processes it on their behalf as an Operator. That doesn't reduce your rights — see §10 for what you can do about it.
What · Where it lives · Note
Your name, email, phone number, and which household/group you're part of · guests table · Entered by the couple, not by you
RSVP status, meal preference, and free-text dietary notes · guests table · The dietary field is genuinely free text — a couple can (and does) write anything here
Household/invitation-unit label (e.g. "The Smith Family") · guest_parties table
Table number and free-text notes about you · guests table · Also unrestricted free text
If you RSVP yourself, on the public RSVP page: your attendance answer, meal choice, dietary text, and answers to any custom questions the couple has written · rsvp_guest_responses / wedding_rsvp_responses tables · This is the one place where you enter data directly, without an account, on an unauthenticated public page
Your phone number, used to open your household's RSVP page (a "who's asking" check rather than a password) · Stored normalised to a standard international format · We are upfront that a phone number is a weak credential — it is a "who's asking" check, not a password, which is why the RSVP page never shows one guest another household's details
We do not ask you to create an account or agree to terms to be included in a couple's guest list — that's inherent to how wedding planning works, and is the reason this section exists separately.
What · Where it lives
Business profile: name, category, location, description, pricing, packages, photos · vendors table
Portal settings: whether you accept quote requests, your booking capacity, timezone, deposit terms · vendor_portal_settings table
Banking details you provide for deposits/invoices (bank name, account holder, account number, branch code) · vendor_portal_settings table. Stored without field-level encryption, protected by database access rules so they are readable only where the app must show them: your own portal, and the payment instructions a couple sees on an invoice you send. Encrypted at rest at the infrastructure level; field-level encryption for these columns is on our roadmap
Your enquiry/lead pipeline: stage, agreed amount, confirmation date, lost/cancelled reasons, the couple's event date, region, a bucketed guest-count range (not an exact number), and the service requested · vendor_leads table
Analytics about activity on your listing (profile views, clicks, enquiries, stage changes, bookings) — as counts, unique and returning couples, and cohort patterns computed for you server-side; you never see which couple viewed · vendor_events table (aggregated for you; the underlying rows are not readable by vendors)
Documents you upload (contracts, consent forms, day-of documents) · Private Supabase Storage buckets (vendor-documents, lead-files) — not publicly accessible
We only collect what a specific feature needs, and only for these purposes:
Purpose · What it covers · POPIA §11 lawful basis
Creating and running your account · Sign-up, sign-in, sync between devices, syncing a couple's shared wedding · Necessary to perform our contract with you (the app's core function)
Planning tools · Budget, guest list, checklist, wedding website builder · Necessary to perform our contract with you
Connecting you with vendors · Enquiries, quotes, messaging, bookings, deposits · Necessary to perform our contract with you, and (for the vendor's side) their legitimate interest in responding to a genuine lead
The couple → vendor "wedding facts" sharing (§5) · Automatically surfacing the wedding date, guest count, ceremony time and a dietary rollup to a confirmed, booked vendor, so you don't have to repeat yourself · Necessary to perform our contract with you (fulfilling a confirmed booking), narrowed by opt-out controls described in §5
Guest data you enter about others · Tracking RSVPs, seating, dietary needs · Your legitimate interest in planning your own wedding, exercised through planna as your Operator — see §3B/§10
AI concierge · Answering your planning questions, reading vendor conversations back to you when asked · Necessary to perform our contract with you (a feature you actively choose to use)
Communicating with you · Transactional emails (enquiry notifications, replies, deposit/invoice confirmations) · Necessary to perform our contract with you
Security and abuse prevention · Rate limiting, fraud/abuse detection · Our legitimate interest in keeping the platform safe and usable
Legal compliance · Responding to lawful requests, retaining vendor business records · Legal obligation / legitimate interest
Improving vendor recommendations · Recording, in pseudonymous form, which listings were shown and what happened next, so future search results can be tuned (§12) · Our legitimate interest in showing better matches (POPIA §11(1)(f)) — you can object at any time via Settings → Privacy → "Help improve vendor recommendations" (POPIA §11(3))
Improving the app itself · Product analytics (screen names, sign-up funnel steps) and masked session replays, tied to a random installation identifier — never your name or account (§12) · Our legitimate interest in finding and fixing product problems (POPIA §11(1)(f)) — you can object via the Information Officer (§14) until the in-app control ships (POPIA §11(3))
We do not sell personal information, and we do not use your data to serve third-party advertising.
Separately from any enquiry, a vendor whose listing you open sees only that *a* couple viewed it — a count, and broad patterns across many couples — never which couple (see "Vendor listing activity" in §3A).
When you enquire with or book a vendor, that vendor can see the enquiry/message content, your event date, region, guest-count band, and the service you requested. Once a vendor has a confirmed booking with you, they additionally and automatically receive a small set of "wedding facts" so you don't have to repeat yourself to every supplier: your wedding date, guest count, ceremony time (if you've entered one), and a rollup of dietary needs across your guest list (counts, plus the raw dietary-note text your guests or you entered — never guest names).
shares only what you actually wrote in your message.
design.
don't want a particular vendor to see the dietary rollup).
receives only the facts relevant to their category — your caterer can receive the dietary rollup; your photographer cannot, and that restriction is applied where the data is served, so it holds even against a modified app. (An earlier version of this system filtered only in the app's interface; that was fixed on 30 July 2026, and we state it because a filter in the interface is not a privacy control.)
If you invite a partner or helper to your wedding, they see everything you see on the shared wedding (this is the point of the feature) — this policy's protections apply to them as an equal user of your account, not as a separate audience.
Provider · What they do for us · What of yours flows through them
Supabase · Our core backend — database, authentication, file storage, and scheduled jobs (like the account-purge process in §7) · Everything described in §3
Resend · Sends transactional emails — vendor-enquiry notifications, reply nudges, and the message relay between you and a vendor · Email addresses and message/enquiry content that's part of an email (subject/body), including deposit and invoice details when relevant. We have not found any path in the current code that sends a guest's email address through this provider — there is no guest-invitation-email feature built yet.
OpenRouter, and the underlying AI model it routes to · Powers the AI planning concierge · Your chat messages, wedding context automatically added for the assistant, and anything a tool call reads back to it from your own vendor conversations
PostHog · Product analytics, masked session replay, and error reporting — all described precisely in §12 · Screen names you open (never their contents), sign-up funnel steps, masked session-replay frames (everything you type and every image is blacked out on your device before sending), error messages with code-level stack traces, and standard technical context (app version, device model, OS version, language). Tied to a random installation identifier, not to your name or account — we never tell PostHog who you are. No advertising identifiers.
Google Maps Platform · Renders the small static map images on vendor profile and vendor-grid screens · When a map image loads, Google receives the vendor's map coordinates and, as with any image request, your device's IP address and user-agent. No couple, guest or budget information is sent. The app does not use Google Places autocomplete, and never sends Google the venue address you type. A Places proxy from earlier development is still deployed on our backend, but no part of the app calls it, so nothing you type reaches it. We name it here rather than leave you to find it, and if that ever changes this section changes with it.
We use processor agreements consistent with POPIA §21 wherever these providers offer them; confirming the specific paperwork with each provider is an open item we track internally and will complete as part of finalising our processor register.
We may disclose personal information where required by law, to protect the rights, safety or property of planna, our users, or the public, or in connection with a merger, sale, or transfer of some or all of planna's assets (in which case you'll be notified as required by law).
POPIA (§72) restricts sending South African personal information to a country whose protections aren't at least as strong, unless a safeguard applies. Here's what we know today, and what still needs confirming (tracked internally until each is verified):
(eu-central-1) for latency reasons. We have not yet confirmed the live project's actual region — this must be verified in the Supabase dashboard before this policy can state a location as fact. If the data is hosted in the EU, that is a cross-border transfer under §72 requiring a documented basis (e.g., an adequacy-equivalent safeguard).
specific data processing terms or hosting region for this policy.
model endpoints with a "Zero Data Retention" guarantee — meaning the provider does not use your conversation to train models and does not retain it beyond serving the response. That is a real, coded safeguard (not just a policy promise). However, the *specific infrastructure region* it resolves to is not pinned to one country — it is whichever ZDR-eligible endpoint is available at the time. This is a cross-border transfer with a technical/contractual safeguard but no fixed jurisdiction, and needs specific legal review.
EU-hosted region (eu.i.posthog.com), to match Supabase's Frankfurt hosting and avoid adding a second cross-border question. The live project's region must still be confirmed — it is set once at project creation and cannot be changed afterwards, so this line must be checked against the project settings before it is stated as fact. What crosses the border here is an error message and a stack trace, not personal information about you, unless one happens to appear inside an error message.
We will update this section once each of the above is confirmed, and will name the actual safeguard relied on for each transfer.
While your account is active, we keep your information for as long as you use planna — there's no automatic expiry on an active account.
If you close your account, here's exactly what happens, honestly:
wedding is blocked and you land on a restore screen. Nothing is deleted yet.
access, exactly as it was.
list and every guest's data, all RSVP responses, your own messages to vendors, your inspiration boards, your wedding website content and brief, your AI concierge conversations, your profile, and your login itself. Your gift registry banking details go with the brief: both the record that a bank-account registry was switched on and the encrypted account holder, account number and branch code themselves, which are deleted from the separate encrypted store they live in rather than left behind once the brief that points at them is gone.
own business record of that relationship — the fact that a booking happened, the amount, the date, and any messages *they* sent you (their quote, their invoice). We anonymise your name out of that surviving record; we do not let a closed account erase a vendor's record of a deposit they were legitimately paid. Vendors with a live relationship are notified when you close your account and again if you restore it.
Proofs of payment you send a vendor are kept by that vendor as their payment record after you delete your account. If you uploaded a deposit or balance slip for a vendor in planna, that file stays with the vendor after the day-60 deletion, because it is their evidence that they were paid. We remove your name from the record around it (who uploaded it, and the file's label), and you lose access to it with your account. We do not alter the file itself, so whatever the slip shows, such as your name or your bank, stays visible to that vendor.
The same rule decides three other things, stated here so you don't have to infer them. A review you wrote about a vendor stays published — other couples rely on it, and it is the vendor's public record — but your name is removed from it: the review is re-attributed to "A planna couple", and your initials and the link to your account are erased. A meeting a vendor held with you stays in that vendor's own diary, with the link to your wedding cut. Accommodation bookings made through planna stay as financial records, with your wedding and the guest they were for both unlinked. In every case what survives is the other party's record of something that really happened; what goes is anything tying it to you.
erases your budget (categories, allocations, payments and the agreement records behind them), any co-planner invitation records (which hold another person's email address), and the stored photo files themselves — not merely the database references to them.
The photo files are deleted through a separate step that runs after the main erasure, because our storage provider deliberately refuses file deletion from the database layer. That step retries until it succeeds rather than being attempted once and forgotten, so a temporary failure delays erasure but does not silently abandon it. Earlier versions of this policy disclosed these three as open gaps; they are closed.
Vendor-recommendation records are the one exception to "permanently deleted" above, and here is exactly why. The pseudonymous records described in §3A/§12 carry no name and no account reference, so closing your account does not delete them — they're kept on their own schedule instead: until 3 months after your wedding month, or 24 months, whichever comes first. What account closure *does* do is sever the one link back to you: if you enquired with a vendor, the connection between that enquiry and your earlier search activity is permanently removed at day 60 — the same removal that happens the moment you turn "Help improve vendor recommendations" off in Settings, whichever comes first. After that, nobody — including us — can tie those rows back to you.
Vendor-side records: your enquiry pipeline, booking history, and messages are retained as your own business records (including for South African tax/SARS retention purposes) even after a couple's account closes, in anonymised form as described above.
registry) are stored in an encrypted secret store (Supabase Vault), retrievable only via a function that checks you own the record — never as plain text in a database column.
database itself — not just the app — enforces that you can only read or write your own wedding's data (or, for a vendor, their own listing and leads).
retrieval) run through narrowly scoped database functions rather than open table access.
that are not publicly readable.
— they're stored in ordinary table columns, protected by access rules (only the vendor's own portal members can read them, and a couple sees them only as the payment instructions on an invoice that vendor sends) and by the infrastructure-level encryption at rest that covers the whole database, but not by separate field-level encryption. We say so plainly rather than imply otherwise; moving them to the encrypted store is on our roadmap.
No system is perfectly secure, and we can't guarantee absolute security of information transmitted to us. If we become aware of a breach affecting your personal information, we will notify you and the Information Regulator as required by POPIA §22.
If you're a couple or vendor with a planna account, you have the right to:
directly in the app — Settings → your profile/wedding details).
that does and doesn't remove, and how long it takes. If you are a vendor, the same in-app control exists for you: your vendor dashboard → Settings (the gear icon) → Delete my account. It follows the same close-now → 60-day restore window → permanent-deletion timeline as §7, with two vendor-specific rules stated plainly: deleting your account removes you (your login and your membership of the business); the business listing itself is closed only if you were its last remaining member — it is unpublished immediately, and after the 60-day window its contact and banking details are permanently erased. The business name survives in anonymised form, because it anchors the booking and invoice records of couples you worked with — the same records-survive rule §7 applies in the other direction. You can also still email the Information Officer (§14) if you prefer a manual route.
processing relies on contract necessity rather than consent, as set out in §4).
How to exercise these rights today: email [email protected]. There is currently no automated self-service export tool inside the app — until one is built, requests are handled manually by the Information Officer. We will confirm a response timeframe here once the manual process is properly resourced, rather than promise a number we can't yet honour.
Complaints: if you're unhappy with how we've handled your information, you have the right to lodge a complaint with South Africa's Information Regulator:
Information Regulator (South Africa)
Email: [email protected]
Complaints portal: https://eservices.inforegulator.org.za/complaints/default.aspx
Tel: 010 023 5200 · Toll-free: 0800 017 160
Address: Woodmead North Office Park, 54 Maxwell Drive, Woodmead, Johannesburg, 2191
You have all the same rights as above (access, correction, objection, deletion) over the information a couple has entered about you — you just exercise them a little differently, because planna isn't the party who decided to collect it.
purpose of planning their own wedding (tracking who's coming, seating, and dietary needs). planna holds it on their behalf.
about you — they can edit or delete a guest record themselves in the app.
go through the couple, or if you believe information about you is being misused. We will work with you to resolve it, which may include contacting the couple.
meal choice, dietary needs, and any custom question answers) directly to us, in which case planna is the Responsible Party for that specific submission, and the rights in §9 apply to it directly.
wedding — never for marketing to you, and never shared with any vendor beyond the anonymised, opted-in rollup described in §5.
planna is not directed at children and our account sign-up is not designed for anyone under 18. If you believe a child has provided us with personal information directly (as opposed to being listed as a guest by an adult planning a wedding, which is a normal and expected use of the guest list feature), please contact us and we will address it.
We do not run advertising trackers and we do not build an advertising profile of you. We do not sell or share your information for third-party advertising (see §4). Three separate things happen behind the scenes, described honestly and separately below, because they go to different places for different reasons.
As of version 1.2.0, the planna app includes PostHog's analytics SDK (an earlier version of this policy said no such SDK was installed — that was true until this version), configured against PostHog's EU-hosted region, and uses it for two things:
screen's name only, never its contents and never anything you typed on it — plus sign-up funnel steps (which step of creating an account was reached or deliberately skipped), and the standard technical context that makes those events comparable (app version, device model, operating system version, language).
landed and how screens flowed into each other — so we can find and fix product problems we would otherwise never see. Masking happens on your device, before anything is sent: everything you type into any field is blacked out, and images (your photos, vendor photos) are blacked out. Only the masked frames reach PostHog.
draws on screen (a label, an amount, a name the app displays back to you) is not covered by the input-and-image masking and can appear in a replay frame. We treat every replay as personal information: it stays inside the same EU-hosted project, is used only for finding and fixing product problems, and is never shared or sold.
call the SDK's identify function — PostHog is not told your name, email, or account id.
Engineering note, kept deliberately visible: there is currently no in-app toggle
to switch product analytics, session replay, or the error reporting below off. Until
there is, email the Information Officer (§14) and we will exclude your account. This
note is removed when the control ships — not before. The vendor-recommendation toggle
described further down is a separate control and does not switch these off.
Alongside the analytics above, the app sends an error report when something breaks:
functions were involved — plus app version and platform. Never the data you were viewing or typing when it happened.
$exception event — through the SDKwhen analytics is enabled (which also lets us see the masked replay of the session that crashed), or as a plain HTTPS request otherwise. The report's content is the same either way.
captured by this system yet.
Starting with this version, we keep pseudonymous records of what the app shows you when you browse vendors, so we can make future recommendations better.
the AI concierge to find vendors.
what you did next — whether you looked at a listing, tapped it, viewed its gallery, or went on to enquire or shortlist it — together with your search context in broad bands (wedding month, province, a budget range, a guest-count range). We never log what you typed, and we never log your exact budget.
account, except that a listing you enquire about is linked to that enquiry, and through it to the other listings you were browsing at the time, until you delete your account or turn this off.** That link exists because it's how we tell whether a recommendation actually led anywhere — we're not going to pretend it doesn't exist, and we describe here exactly what severs it: closing your account (§7) and turning this control off both remove it, permanently.
the bands above — a sparse province, wedding month and guest-count band, together — can in practice be unique enough to narrow a record down to one likely wedding. This is a limit of how well any bucketing scheme can hide a small population, not a second hidden link, and we're noting it here rather than letting broad bands imply every record is anonymous regardless of how rare the combination is.
comes first — see §7 for what happens to these specific records when you close your account (it's different from the day-60 rule that applies to the rest of your data).
§11(1)(f)) — see §4. You can object to this at any time using the control below (POPIA §11(3)).
by default, because most of what it records is unlinked to you and the one linked case is disclosed above — but it's one tap to turn off. Turning it off stops any new recording, stops the app from starting a session for this purpose at all, and immediately severs the one link described above. It does not delete records already written, and turning it back on later does not re-link anything. The first time this started recording, we showed a one-time in-app notice carrying this same control, before anything was written.
If we later change what this records, or add anything beyond it, that is a material change: we will update this policy and tell you inside the app before it takes effect (see §13), and any new control will ship at the same time, the same way this one did.
We may update this policy as planna's features, processors, or legal obligations change. We'll update the "Last updated" date at the top, and for material changes, we'll let you know inside the app before they take effect.
Questions about this policy, or about how we handle your information:
Igno Ferreira — Information Officer
Email: [email protected]
Plan Technologies (Pty) Ltd, registration number 2026/417875/07
Registered address: 4 Alexander Street, Paarl, 7646, South Africa