The privacy policy you can write yourself

Founders avoid writing privacy policies because the genre feels intimidating. They reach for a generator like termsfeed.com, plug in their company name, and ship a generic three-page document that says they collect cookies and respect user rights — without ever specifying which cookies, which rights under which laws, or which third parties they share data with.

Generic policies are worse than no policy in three ways:

1. They claim things you don't do. Most templates mention practices (Google Workspace, intercom chat, hotjar tracking) that don't apply, which means the policy is technically misleading.
2. They miss things you actually do. AdSense, OpenAI, Stripe — none of these get listed because templates can't know your stack.
3. GDPR specifically requires accuracy. An inaccurate policy is non-compliance, not partial-compliance.

The good news: writing your own takes thirty minutes if you know the structure. Here it is.

The eight required sections

1. What you collect

List every category of data you collect. Be specific. Not "user data." Specifically:

• Account data: email, name (if you collect it), password hash (if applicable).
• Behavioral data: page views, clicks, time on page (via what tool — Google Analytics? Plausible?).
• User content: anything users type, upload, or generate.
• AI-routed content: anything sent to OpenAI / Anthropic / etc. for processing.
• Payment data: only if you process payments (and if you use Stripe Checkout, this is "processed by Stripe, not us").
• Cookies: list each cookie. Strictly necessary (session cookies) vs analytics vs marketing.

If you have a lib/track.ts or similar event-recording helper, list the event names you currently fire.

2. Why you collect each thing (the legal basis under GDPR)

For EU users (and best practice for everyone), each processing activity needs a legal basis:

• Consent — user explicitly agreed (cookie banner click, marketing checkbox).
• Contract — necessary to deliver the service (storing your account data so you can log in).
• Legal obligation — required by law (tax records, dispute records).
• Legitimate interest — your interest, balanced against the user's rights (security logging, fraud prevention).

For an MVP, most processing is "contract" (account data) plus "legitimate interest" (security, basic analytics). Marketing email is "consent."

Don't claim "legitimate interest" for analytics or marketing — these specifically need consent under modern interpretations.

3. Who you share data with (sub-processors)

List every third party that processes user data on your behalf, by name. Not "third-party providers" — by name.

A typical MVP's list:

• Vercel / AWS — hosting and infrastructure
• OpenAI — AI feature processing
• Resend — transactional email
• Stripe — payment processing (if applicable)
• Google Analytics — site analytics
• Google AdSense — ad serving (if applicable)

For each, link to their privacy policy. This is the sub-processor list under GDPR Art. 28.

4. Data retention

How long do you keep each category of data?

• Account data: until the user deletes the account, plus 30 days for backups.
• Logs / analytics: 90 days (sensible default).
• Behavioral events: 12 months.
• Payment records: 7 years (legal requirement in most jurisdictions).
• Email subscription: until the user unsubscribes.

Be specific. Don't say "as long as necessary." Pick numbers and stick to them.

5. User rights

Explain in plain English what users can do:

• Access: get a copy of their data (you'll need an export endpoint).
• Delete: remove their account and data (you'll need a delete endpoint).
• Correct: fix wrong data (an account settings page).
• Export (data portability): download in a machine-readable format.
• Object to processing: opt out of analytics, marketing, etc.
• Lodge a complaint: with their local data protection authority (you can list a few).

6. How to exercise rights

Give users a single way to contact you for privacy requests. Ask the user what email they want to use — don't invent privacy@<domain>. Many founders prefer to use their existing inbox at MVP stage. Document the contact in the policy.

If you do set up an alias (privacy@<your-domain>), set up email forwarding from that alias to your real inbox. Most domain registrars include this for free.

7. Cookies

If you have any cookies, list them. Separate strictly-necessary (session, CSRF) from analytics (_ga, _ga_XXXX) from marketing (DoubleClick from AdSense).

For each non-essential category, explain how the user can opt out:

• Browser settings to block third-party cookies
• Google Ads opt-out: google.com/settings/ads
• Google Analytics opt-out: the Browser Add-On
• DAA opt-out: aboutads.info

8. Contact and changes

• A contact email for privacy questions.
• A "this policy was last updated on [date]" line.
• A statement that material changes will be notified at least 30 days in advance (in the footer or by email).

CCPA-specific section

For California residents (and de facto for everyone, since AdSense forces it):

A section anchored at #ccpa-rights covering:

• Right to know.
• Right to delete.
• Right to correct.
• Right to opt out of sale or sharing.

Add a "Do Not Sell or Share My Personal Information" link to your footer pointing at this anchor. Even if you don't formally sell data, AdSense personalized ads count as "sharing" under the CPRA.

What to leave out

• Long disclaimers about how you reserve the right to change anything at any time. They don't hold up legally and they make the policy unreadable. Just commit to 30 days' notice for material changes.
• Marketing-speak. "We value your privacy." Of course you do; everyone says that. Skip it.
• Things you don't do. Don't include sections about practices that don't apply.

Example structure

For reference, vibecodersguidetomvp.help/privacy/ follows this structure exactly. You can crib it.

What this is not

A privacy policy is not a substitute for a lawyer. If your product handles regulated data (healthcare, finance, education, children's data), processes serious volumes of EU user data, or is being prepared for an enterprise sale, get a lawyer.

For an MVP with normal data practices, the eight-section structure above is what a lawyer would draft for you. It's also legally adequate for a beta launch.

What the skills do

The skill bundle's compliance skill (sub-skill 08) drafts both Privacy Policy and Terms of Service tailored to your specific product, after the agent asks: what do you collect, who uses it, where do they live, what email should go on the policy, and what URL is the canonical URL for the site.

The result is a policy with your specific stack, your specific sub-processors, and your specific contact email. Not a template. Twenty minutes of dialogue and the agent ships the policy as a static MDX page.

Write it once, update it when material things change, link from your footer. That's the whole job.

← All posts