丑

Compliance framework

Privacy

Draft framework for Swiss FADP and EU GDPR review. This is not the final legal text; it is the checklist Uglytude must complete before real production data, newsletters, bookings, payments, or external accounts go live.

Controller and contact

  • Name Uglytude / Miaomiao as the data controller before launch.
  • Publish the production contact email for privacy requests.
  • State that the physical space is in Zurich, Switzerland, with the exact address added before opening.

Data categories

  • Account and auth data: email address, login tokens, Google profile details if Google OAuth is enabled.
  • Wish wall data: text-only notes, sticker/color choices, seed coordinates, personal layout coordinates, hide/moderation status, rate-limit attempts.
  • Newsletter data: email address, marketing_consent_at, double_opt_in_at, unsubscribed_at, token hashes, and email delivery metadata.
  • Booking and payment projection data: Cal.com booking identifiers, booking event payloads, Stripe payment event identifiers, reschedule count, local coupon and promo-code status.
  • Technical data: server logs, request timestamps, IP-derived rate-limit keys, health-check status, and UGLY_ observability logs.

Purpose, basis, and consent

  • Explain the purpose for each data category: login, wall posting, personal layout saving, coupon issuance, newsletter delivery, booking support, fraud prevention, and operational debugging.
  • Separate transactional email from marketing email; login, coupon, booking, and workshop-code messages are not newsletter consent.
  • Treat newsletter subscription as explicit consent only after double opt-in, and allow withdrawal through unsubscribe.
  • State the intended FADP/GDPR legal basis for each production purpose before launch.

Processors and transfers

  • List production processors before go-live: Vercel, Neon, Auth.js/Google OAuth if enabled, Resend, Cal.com, Stripe, and any analytics only if added later.
  • Do not add analytics, image upload, or shopping-cart providers without updating this page first.
  • For services outside Switzerland/EU/EEA, document the transfer safeguard or provider data-processing terms before enabling the account.

Retention and deletion

  • Define how long auth records, wall notes/layouts, marketing consent records, booking events, coupons, promo-code rows, and operational logs are retained.
  • Keep consent audit fields even after unsubscribe when needed to prove opt-in and opt-out history.
  • Document how a user can request access, correction, deletion, or consent withdrawal, and what records cannot be deleted immediately for accounting or fraud-prevention reasons.

Launch gates

  • No real newsletter sending until Resend domain verification and double opt-in are tested.
  • No real booking or payment collection until Cal.com, Stripe, webhook secrets, and the legal terms are verified.
  • No real promo-code pool in git; production codes are imported only through the documented operations runbook.
  • Replace this framework with reviewed public copy before the first production visitor can submit personal data.