Privacy Policy Generator

Free — GPL coresize Splanned, not built

Generated from docs/plan/core/privacy-policy-generator/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A core feature that generates GDPR-compliant privacy policy templates auto-filled with the shop’s data practices (GA4, email collection, payment processing, contact form usage). Merchants download a policy ready to publish or customize, reducing legal risk.

The problem

A German merchant’s shop collects customer email, uses GA4, stores customer data, processes payments. She needs a privacy policy for GDPR compliance. Hiring a lawyer costs €1000+. A generic template online is 10 pages and doesn’t match her shop. She wants a ready-to-use policy auto-generated from her shop’s setup.

What it does

• Policy template generation: auto-fill with shop data (company name, email, phone, address, processing purposes)
• Data collection audit: scan shop for GA4, email, payment processing, cookies, contact forms—list all data flows
• GDPR clause generation: auto-generate sections for data subject rights (access, deletion, portability, objection)
• Cookie disclosure: list all cookies used (essential, analytics, marketing) with descriptions
• Third-party services: disclose integrations (GA4, Stripe, email provider, etc.)
• Data retention policy: auto-suggest retention periods (e.g., customer data deleted after 3 years, order data 7 years)
• Export formats: download as PDF, Word, or HTML (ready to publish or edit)
• Localization: templates for EU, US (CCPA), California, etc.
• Updates: when shop configuration changes (e.g., adds new payment provider), generate updated policy
• Admin UI: visual builder to customize policy sections (merchant can edit retention periods, contact info, etc.)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Legal review (policy is template, not lawyer-reviewed)—merchant’s responsibility
• EULA / terms of service generation (separate feature, if needed)
• Regulatory filing (we generate policy, merchant publishes it)—out of scope
• Localization for all 195 countries—EU/US only initially
• Privacy impact assessment (DPIA) generation—too specialized

Data model

New: PrivacyPolicy(id, shopId, generated_at, template_version, customizations_json, export_format). Stored in settings, no core migration.

API

• POST /privacy-policy/generate — auto-generate policy from shop config
• GET /privacy-policy/latest — return most recent generated policy
• POST /privacy-policy/export — download policy as PDF/Word/HTML
• POST /privacy-policy/data-audit — scan shop for data collection points (GA4, forms, integrations)
• PUT /privacy-policy/customize — merchant edits sections (retention periods, contact info, etc.)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Privacy policy builder: auto-generated policy (PDF preview), data audit results (list of data flows detected), customization UI (edit retention periods, contact info, data processing purposes), export button (PDF/Word/HTML), version history (track changes)

The seam — why this is core

Core owns: data audit (scanning for GA4, email, forms), template generation, export. Paid pack owns: legal review/certification, localization for edge cases, regulatory guidance, EULA/ToS generation.

Core owns the interface + honest template generator; legal templates are infrastructure, not a per-country obligation or support commitment.

Dependencies

• GA4 integration (must detect if GA4 is enabled)
• email layer (must detect if email is being collected/sent)
• settings/configuration (must audit which integrations are enabled)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Running privacy policy generator auto-fills with: company name ‘AcmeCorp’, email ‘contact@acme.com’, GA4 enabled, Stripe payment processor
• Generated policy includes sections: data collection (GA4, email, payment), data retention (customer data 3 years, orders 7 years), data subject rights (access, deletion, portability)
• Data audit detects: GA4 enabled, email form on product pages, Stripe payments, no marketing pixels
• Exporting as PDF produces readable document (formatted, not raw HTML)
• Merchant customizes retention period from ‘3 years’ to ‘5 years’; policy is regenerated with change
• Policy is compliant with GDPR (includes required clauses for consent, rights, etc.)
• Adding a new email integration (Mailchimp) triggers suggestion to regenerate policy
• Policy version history shows: v1 (Sept 2025), v2 (Oct 2025 - added Mailchimp)

Risks

Generated policy is too generic (doesn’t match merchant’s actual practices)—merchant publishes it, regulator spots mismatch, fine. Merchant edits policy and removes required sections (e.g., deletes right-to-deletion clause)—we should validate/warn. Data audit misses an integration (e.g., merchant added custom tracking pixel)—policy is incomplete. Retention period recommendation is wrong (e.g., orders must be kept 7 years per tax law, policy says 3 years)—merchant faces compliance issue.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.