You shipped your app. Users are signing up. And then someone asks: "Where's your privacy policy?"
You Google "privacy policy generator," click the first result, and get hit with a $15/month subscription for a document you'll generate once. You try a free one — it produces generic HTML that doesn't mention any of the actual services you use. You briefly consider copying Stripe's privacy policy and changing the name.
I've been there. Multiple times. Here's what I learned about handling privacy policies as a developer in 2026, without hiring a lawyer or paying a monthly subscription.
Why you actually need one
Let's get this out of the way — it's not optional.
Legal requirements:
- GDPR (EU) — applies if you have any EU users, regardless of where your company is based. Fines up to 4% of annual revenue.
- CCPA/CPRA (California) — applies if you collect data from California residents. $7,500 per intentional violation.
- 8 new US state laws took effect in 2025 (Texas, Oregon, Montana, Florida, and more), with 3 more in January 2026. The trend is clear — every state is going to have one.
Platform requirements:
- Apple App Store and Google Play require a privacy policy URL to publish.
- Stripe, Paddle, and Lemon Squeezy ask for one during onboarding.
- Enterprise customers will ask for it during due diligence.
If your side project has users and collects any data (analytics, auth, payments), you need a privacy policy.
What to include
A privacy policy under GDPR Articles 13-14 must disclose:
1. What data you collect
Be specific. Not "we may collect personal information" — list the actual categories:
- Email address (from sign-up)
- Usage data (from analytics)
- Payment information (processed by Stripe — you don't store card numbers, Stripe does)
- IP address (from server logs, analytics)
- Device and browser info (from analytics)
2. Why you collect it
Each piece of data needs a legal basis. For most side projects:
| Data | Purpose | Legal Basis (GDPR) |
|---|---|---|
| Account creation, notifications | Contract performance | |
| Usage analytics | Product improvement | Legitimate interest |
| Payment info | Processing purchases | Contract performance |
| Cookies | Session management, preferences | Consent (for non-essential) |
3. Which third-party services process the data
This is where most generators fail. They ask "do you use analytics?" instead of "which analytics tool?"
It matters because each service has different data practices. PostHog self-hosted processes data on your servers. Google Analytics sends data to Google's servers in the US. These require different disclosures.
Common services you need to mention:
Auth: Clerk, Auth0, Supabase Auth, Firebase Auth, NextAuth
Analytics: PostHog, Vercel Analytics, Plausible, Google Analytics, Mixpanel
Payments: Stripe, Lemon Squeezy, Paddle, Gumroad
Error tracking: Sentry, LogRocket, Bugsnag
Hosting: Vercel, Netlify, AWS, Railway
Email: Resend, SendGrid, Postmark, ConvertKit
For each service, include:
- What data it receives
- Where it's processed (US, EU, etc.)
- Link to their privacy policy or DPA
4. Data retention
How long do you keep the data? Common approach:
- Account data: until the user deletes their account
- Analytics: 12-24 months
- Server logs: 30-90 days
- Payment records: as long as required by tax law (usually 7 years)
5. User rights
Under GDPR, users have the right to:
- Access their data
- Correct inaccurate data
- Delete their data ("right to be forgotten")
- Export their data (portability)
- Object to processing
- Withdraw consent
Under CCPA, California residents can:
- Know what data is collected
- Request deletion
- Opt out of "sale" of personal information
- Not be discriminated against for exercising these rights
Include a contact email where users can submit these requests.
6. International transfers
If you're in the EU and use US-based services (most devs do), you need to mention the legal mechanism for transferring data outside the EU. After the EU-US Data Privacy Framework (2023), US companies on the DPF list have an adequate legal basis. For others, Standard Contractual Clauses (SCCs) apply.
In practice: check if your service providers are on the Data Privacy Framework list.
7. Cookies
If you use non-essential cookies (analytics, marketing), you need:
- A list of cookies and their purpose
- A way for users to opt out (cookie banner for EU users)
- Duration of each cookie
Essential cookies (session, CSRF tokens) don't require consent.
A real example
Here's what a minimal privacy policy section looks like for a typical indie stack (Next.js + Supabase + Stripe + PostHog):
## Analytics
We use PostHog for product analytics. PostHog collects:
- Page views and navigation patterns
- Device type, browser, and operating system
- Country-level location (derived from IP, which is then discarded)
PostHog is configured to respect Do Not Track (DNT) headers.
Data is processed on PostHog's EU servers (Frankfurt).
Privacy policy: https://posthog.com/privacy
Compare this with what a typical generator produces:
We may use third-party analytics services to monitor and
analyze the use of our Service. These services may collect
information sent by your browser as part of a web page
request, such as cookies or your IP address.
The first version is useful. The second is legally questionable because it doesn't name the service or disclose where data is processed.
Common mistakes
1. Copy-pasting another company's policy
Vercel's privacy policy covers Vercel's data practices, not yours. If you copy it, you're making false claims about data you don't collect and missing disclosures about data you do.
2. Using AI to generate it
ChatGPT will produce something that reads well but often omits GDPR-specific required disclosures (data controller identity, legal basis per processing activity, DPO contact). It's non-deterministic — same prompt, different output. For a legal document, you need to know exactly what you're publishing.
3. Forgetting to update it
Added Sentry last month? Your privacy policy should mention it. Changed analytics from Google Analytics to PostHog? Update the policy. Set a reminder to review it quarterly.
4. Not covering all jurisdictions
If you have users globally (and if your app is on the internet, you do), covering only GDPR isn't enough. CCPA has different requirements. The new US state laws add more.
5. HTML-only output
If your docs site uses Markdown or MDX, an HTML privacy policy is a formatting headache. Look for tools that output markdown natively.
The practical approach
For most side projects, here's what I'd recommend:
-
List every third-party service your app uses. Check your
package.json, environment variables, and dashboard logins. - Read each service's DPA (Data Processing Agreement) — specifically what data they collect and where it's processed. This takes 20-30 minutes total.
- Write the policy in Markdown so it lives in your repo alongside your code.
- Cover GDPR + CCPA at minimum — these are the most enforced.
- Include a real contact email for data requests — not a form, an actual email.
- Review quarterly or whenever you add/remove a service.
What I'm building
I ran into this problem enough times that I'm building Pliqo — a privacy policy generator that actually knows what Supabase, PostHog, Vercel Analytics, and Stripe are. You pick your stack, it generates the right disclosures. Markdown output. No account. One-time payment instead of a subscription.
It's still in early development — if this sounds useful, you can join the waitlist and I'll let you know when it's ready.
Have questions about privacy policies for your specific stack? Drop a comment — happy to help.
Top comments (0)