POPIA applies to your app. Here is the practical version.

What counts, and who is accountable.

Personal information under POPIA is broad: names, email addresses, phone numbers, ID numbers, location data, financial details, health information, even opinions about a person. If your users are South African, your database almost certainly holds it. The Act is enforced by the Information Regulator, and accountability defaults to the head of the organisation, in a startup, that is you, unless an information officer has been designated and registered.

The reason this guide sits next to our security guides is simple: for a vibe-coded app, POPIA's security safeguards requirement and an open database are the same conversation. A publicly readable table of users is not only a technical failure; it is a reportable event with legal duties attached.

The eight conditions, translated into app decisions.

• Accountability. Someone owns privacy. Name them, even informally, and register the information officer with the Regulator when you formalise.
• Processing limitation. Collect the minimum the feature needs. The AI-generated sign-up form that asks for ID number and date of birth "just in case" is a liability generator; delete those fields.
• Purpose specification. Know why you hold each field, and tell users in plain language. If you cannot state the purpose, you should not hold the data.
• Further processing limitation. Data collected for delivery does not silently become marketing data. New purpose, new consent.
• Information quality. Keep it accurate and current; give users a way to correct their own details, which your profile screen probably already does.
• Openness. A privacy notice that is reachable, current, and honest about what you collect, why, and where it is processed.
• Security safeguards. The engineering condition: access rules on the database, secrets managed, encryption in transit, backups, and access limited to who needs it. Our RLS, Firebase rules, and security checklist guides are, in practice, POPIA implementation guides.
• Data subject participation. Users can ask what you hold about them, have it corrected, and have it deleted. Build the deletion path before the first request, not after: know every table and bucket a user's data touches.

The two questions founders actually ask.

Can my data live on Supabase or Firebase overseas?

Yes, subject to POPIA's transborder rules in section 72: broadly, the recipient jurisdiction or contract must provide comparable protection, or you need the data subject's consent, or the transfer must be necessary for the contract with them. In practice for a startup: sign or accept the platform's data processing terms, choose a sensible hosting region, disclose the overseas processing in your privacy notice, and record that reasoning. The platforms are operators in POPIA's terms; you remain the responsible party. Those terms also move under you, so re-read them when a platform announces a data change. Lovable is the current worked example: its notice of 5 August 2026 says that from 9 September 2026 it may use customer content from Free and Pro plans for AI model training unless you opt out, where customer content means your prompts and attached files, code, project files, configurations and generated outputs, and it states that your apps' end-user data is excluded and stays in your project's own database. So the exposure is not your users' table; it is whatever you pasted into a prompt to debug it. Two days after that notice Lovable renamed the control and inverted its label, so read the toggle rather than trusting a remembered setting name. Our guide to builder AI-training clauses covers what each platform says and what to record.

What happens if we leak data?

Section 22: where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, you must notify the Information Regulator and the affected people as soon as reasonably possible, in a form that lets them protect themselves. Practically: fix the exposure, establish what was reachable and when, write the timeline down as you go, and take advice on the notification wording. Discovering your own breach via the checklist is dramatically better than a researcher or an attacker discovering it for you.

The founder's POPIA checklist.

1. Map the personal data. List every table, bucket, log, and third-party tool that holds personal information, and the purpose for each. This one artefact powers everything else.
2. Minimise. Drop the fields with no stated purpose. Less data is less risk, less backup, less breach.
3. Run the security guides. Access rules, secrets, backups; the safeguards condition is the checklist you have already seen.
4. Publish the privacy notice. Plain language: what, why, where it is processed, how to get it corrected or deleted, and who to contact.
5. Build the export and delete paths. Even as an admin-run script. The first data subject request should be routine, not a scramble.
6. Write the one-paragraph breach plan. Who notices, who acts, who informs the Regulator and users. Section 22 is much calmer with a plan.

None of this requires a compliance department. It requires the same discipline as the rest of production readiness, applied to the data you hold about people.