Privacy

1. What LaunchBeam processes

Account holders provide an email address and authentication credentials to Supabase Auth. Project owners add project content, visual settings, publication choices, and optional images. Passwords are handled by Supabase Auth and are not stored in LaunchBeam application tables.

People joining a public waitlist provide an email address and, depending on the project, may provide a name and one custom answer. LaunchBeam stores their waitlist status, position, referral code, referral relationship, campaign parameters, and timestamps.

2. Analytics and referrals

Published waitlists record page views, signups, referral visits, referral signups, and share clicks. Events may include a random first-party session identifier, referring URL, normalized device category, deployment-provided country code, and UTM campaign values. LaunchBeam does not create browser fingerprints or permanently store raw IP addresses in its application database.

A project-specific referral cookie may remember a valid referral for up to 30 days. Authentication cookies keep account holders signed in. These cookies are used for security, sessions, and attribution rather than cross-site advertising.

3. Service providers

• Supabase provides authentication, Postgres database storage, and project asset storage.
• Cloudflare Turnstile helps protect public signup forms from automated abuse.
• Upstash applies privacy-conscious rate limits to public form and analytics requests.
• Resend delivers waitlist confirmation, referral, and unsubscribe messages when email is configured.
• Vercel or the configured host serves the application and may process standard request logs under its own settings.

4. How information is used

Information is used to provide accounts, publish waitlists, prevent abuse, deliver requested email, attribute referrals, show project analytics, export subscriber data for the project owner, investigate failures, and keep the service secure. LaunchBeam does not implement third-party advertising profiles or sell subscriber information.

5. Project owners and subscriber data

Each project owner controls the purpose of their waitlist and is responsible for an appropriate notice, lawful collection, and handling of subscriber exports. Row Level Security and server-side ownership checks are designed to prevent one owner from reading another owner's projects, subscribers, or analytics.

6. Retention and deletion

The starter retains account and project data until the operator or account holder deletes it, subject to backups and legal obligations. Unsubscribing changes the subscriber status and does not automatically delete historical analytics. Project owners can remove subscriber records from their dashboard. A production operator should publish specific backup and deletion timelines before launch.

7. Security and choices

The application validates server inputs, restricts project access, rate-limits public mutations, and keeps service credentials on the server. No system is perfectly secure. Subscribers can use signed links in configured emails to unsubscribe; account holders can unpublish a project without deleting its history.

8. Requests and contact

Before production launch, the operator must replace this paragraph with a monitored privacy contact and jurisdiction-specific request process. Until then, requests should be sent to the contact channel published by the person or business operating this deployment and should identify the relevant waitlist and email address.