Privacy Policy

1. Two different sets of people, two different roles

This policy covers two groups, and the difference decides who is answerable to you.

People with a LaunchBeam account

Founders and their team members. For your account, workspace, billing and usage data we are the data controller. Everything in this policy applies to us directly, and you contact us.

People on a customer's waitlist or contact list

If you gave your email address to a product's waitlist page or received a sequence email sent through LaunchBeam, the founder who runs that product is the controller and we are their processor: we hold and send that data on their instructions and for no purpose of our own. Ask them first — but the unsubscribe link in any marketing email we deliver for them works immediately and without their involvement, and you can always write to us at [PRIVACY CONTACT ADDRESS] and we will route the request and help.

2. Who we are

[LEGAL ENTITY NAME], [REGISTERED ADDRESS], operating LaunchBeam. Privacy contact: [PRIVACY CONTACT ADDRESS]. Data protection contact: [DPO / DATA PROTECTION CONTACT]. The service itself is governed by our Terms of Service, of which this policy forms part.

3. What we collect from account holders, and why

Account

Your email address and a password, handled by Supabase Auth — the password is hashed by Supabase and we never see or store it. Plus sign-in and account timestamps. Basis: performance of our contract with you.

Workspace and team

Workspace name and slug, who is a member, each member's role, and the email address of anyone you invite (we email them the invitation on your instruction). Basis: contract.

Launch content

Product names, descriptions and URLs, campaigns, post drafts and published posts, scheduling times, launch-directory submissions, press-kit content, testimonials, and the images and videos you upload. Basis: contract.

Platform connections

Which platform, the account handle or channel id it points at, and the credential itself — OAuth access and refresh tokens, API keys, app passwords, bot tokens. Credentials are encrypted with AES-256-GCM before they are written to the database, with the key held in the deployment environment and never in the database, and they are redacted from logs. Basis: contract.

Email sending credentials

If you configure sending, the SMTP host, port and username or the provider API key you supply, encrypted the same way, plus your from-name, from-address and reply-to, and the result of the last test send. Basis: contract.

Billing

Your Stripe customer, subscription and price identifiers, plan, billing interval and period end, and invoice metadata. We never receive or store card numbers — card details go directly to Stripe. Basis: contract, and legal obligation for tax and accounting records.

Usage and diagnostics

Counters (AI generations, campaigns created, posts published, emails sent per day), job states, and error messages returned by platforms and mail providers — which sometimes quote the content of the request that failed. Basis: contract for enforcing plan limits; legitimate interests in keeping the service working and preventing abuse.

Support correspondence

What you write to us and what we reply. Basis: legitimate interests in supporting our own product.

Referral programme

If you join LaunchBeam's own referral programme: your referral code, click counts, which accounts signed up through your link, and a commission ledger. Individual click rows record a country, a coarse device type (mobile, tablet, desktop, bot), the origin and path of the referring page with the query string stripped, and the landing path. They deliberately record no IP address, no hashed IP, and no full user-agent. Basis: contract for the programme; legitimate interests in fraud prevention.

4. Cookies and tracking

LaunchBeam sets first-party cookies only. There are no advertising cookies and no ad-network pixels anywhere in the product or on these pages, nothing here is used for advertising, ad targeting or cross-site profiling, and no ad network is given a way to recognise you.

There is product analytics, and it is third-party.We run PostHog across the whole site — the marketing pages, the app, and these legal pages. It records page views (including client-side navigations), automatically captures the elements you click and the fields you focus, and derives a browser, device type and country; it also records session replays, which reconstruct what a page looked like and what you did on it. Once you are signed in your events are attached to the account id Supabase issued you, and your account email address is stored against that person record. All of it goes to PostHog's US cloud.

PostHog runs through our own domain, which changes what your browser shows but not where the data ends up. The SDK is served from this origin and posts to a path on it (/flare/…) which our server forwards to PostHog; your browser never opens a connection to a PostHog hostname, so blocklists keyed on one will not stop it. Because our server makes the onward request, your IP address travels to PostHog in the forwarded-for chain — PostHog geolocates and de-duplicates visitors by it. We say this plainly because a proxy that is invisible to you is not a privacy measure; it exists so the app's own content-security policy does not silently drop the events.

What session replay is not allowed to see.The signed-in dashboard and the internal admin area are wrapped in PostHog's masking class, so the replay recorder replaces the text of every element inside them with asterisks in the browser, before anything is transmitted — a replay of those screens shows layout and clicks but no readable copy. Values typed into form fields are masked everywhere by default. That masking is deliberately broad because most of the personal data on those screens belongs to a customer's subscribers rather than to the person looking at it. It is not applied to the public marketing pages, where a replay does show the text on screen.

One request to a third-party host does exist.The launch-directory screens draw each directory's favicon from Google's icon service (www.google.com/s2/favicons), one image request per row. Your browser therefore tells Google its IP address, its user-agent, the domain of the directory whose icon it is fetching, and whatever google.comcookies it already holds. We receive nothing back except the icon, and this is the only origin outside our own and our database host's that any page here reaches directly — but it is a request to a third party, and claiming the product makes none would be untrue.

lp_sid — attribution and click analytics, 180 days

Set when a visitor follows a link LaunchBeam rewrote for tracking — a campaign link (/r/…), a launch-directory link (/d/…), an affiliate link (/a/…) or a referral link (/join/…). It holds a random 16-character id, is HTTP-only, is scoped SameSite=Lax, and lives 180 daysso that a click during launch week can still be credited when the person signs up weeks later. It lets the same visitor's clicks on several tracked links be recognised as one session. The same id can be passed onward to the founder's own website as an lp_sid URL parameter so their application can report a conversion back to us and credit the channel that earned it. This cookie is not strictly necessary to run the site.

lp_ref — referral attribution, 60 days

Set when someone arrives through a LaunchBeam referral link. Holds the referral code that claimed the visit, HTTP-only, SameSite=Lax, and expires after exactly the 60-day window the referral programme promises — when it expires the attribution is simply gone.

ph_…_posthog — PostHog product analytics, 365 days

Set by PostHog's script on our own domain, named after our PostHog project id. It holds the random id PostHog knows your browser by, the current session id, and the feature-flag values evaluated for you, and the same values are mirrored into the browser's local storage — so clearing cookies alone does not clear it. Unlike the cookies above it is written by JavaScript rather than by us, so it is not HTTP-only and the page can read it. When you sign in, the random id is replaced by your LaunchBeam account id, which is what joins your visits before and after sign-in into one person in PostHog; signing out resets it to a fresh random one. It is analytics, not strictly necessary.

lp_active_org — which workspace you last had open, 365 days

Purely functional. It remembers a preference and identifies nothing about you.

Supabase Auth session cookies (sb-…)

Strictly necessary to keep you signed in and to refresh your session on each request.

What the tracked-link redirects record. When a tracked link is followed we write an analytics event containing: the time, which post, campaign or directory the link belonged to, the referring URL sent by the browser, the full user-agent string, and a two-letter country code derived from a header added by the network edge. We do not store the visitor's IP address in the database. IP addresses are used transiently to enforce rate limits, held in a short-lived cache key, and not written to the database or to application logs; where a rate limit is keyed on an email address, the address is hashed first so it cannot sit in a cache key in the clear. Events are also aggregated into daily per-channel totals.

Consent. The lp_sid, lp_ref and ph_…_posthog cookies are analytics and attribution, not strictly necessary, and in the EU, the UK and other jurisdictions with ePrivacy-style rules they require consent before being set — as does the local storage PostHog writes alongside its cookie, which the same rules cover. LaunchBeam does not yet present a consent mechanism, so nothing here asks before it starts: PostHog initialises on the first page you load, and a compliant launch in those jurisdictions needs a consent mechanism added — one that can also hold PostHog and its session replay off until it is answered — before these pages go live. We would rather say that plainly here than claim a consent flow that does not exist.

5. What we process on behalf of our customers

These records belong to the founder whose workspace holds them. We process them only to deliver the features they enabled, and never for our own marketing, profiling, resale, or model training.

Waitlist entries

Email address; optional name; the referral code issued to that person and which entry referred them; a source label and any utm_source, utm_medium and utm_campaign values from the link they arrived on; a country code; and timestamps for joining, being invited, converting, and unsubscribing. Position in line is computed on demand, not stored.

Email contacts and sends

Email address; optional name; where the contact came from; whether they are still subscribed and when they opted out; and one row per scheduled or attempted send recording which sequence step it was, when it was due, whether it sent, and the error if it failed.

Affiliate and partner records

If a founder tracks launch partners: the partner's name, optional email address, the public URL of their channel, notes the founder wrote, the commission terms agreed, and conversions credited to them.

Delivery and opt-out. Mail to a customer's audience is sent through their credentials, from their domain — never from a shared LaunchBeam sending domain. Their email provider is therefore their sub-processor, chosen by them. Every marketing send carries a visible unsubscribe link and RFC 8058 List-Unsubscribeheaders, so the one-click opt-out in Gmail and Yahoo works; the footer is appended to the outgoing message and a founder cannot remove it. The unsubscribe link is authenticated by a high-entropy random token alone, and the endpoint answers identically for a valid and an invalid token, so nobody can use it to test whether a given address is on somebody's list.

6. Legal bases we rely on

• Contract — to create your account, run your workspace, publish what you ask us to publish, send what you compose, and bill you.
• Legitimate interests — security, abuse and fraud prevention, debugging, enforcing plan limits, and understanding aggregate product usage. We only rely on this where our interest does not override your rights, and you can object (§9).
• Legal obligation — keeping financial records, and responding to lawful requests from authorities.
• Consent — where required for the non-essential cookies in §4, and for any marketing email we send you about LaunchBeam itself (withdrawable at any time, without affecting service email such as billing receipts and security notices).

For subscriber data, the legal basis is the customer's to establish and document, not ours.

7. Who else processes the data

We use these sub-processors. This list is what our code actually talks to; the one third-party your browser contacts on its own is in §4.

Supabase — database, authentication and object storage

Holds essentially everything: accounts and password hashes, workspaces, products, campaigns, posts, encrypted platform credentials, waitlist entries, email contacts and send logs, analytics events, and the images and videos you upload. Hosted at [SUPABASE HOSTING REGION].

Stripe — payments and subscriptions

Receives what you enter in Stripe's own checkout and billing portal, including card details, which never pass through us. We receive back identifiers, plan state and invoice metadata.

OpenAI — draft generation

When you ask for a draft, the product and campaign details in that request plus our prompt are sent to OpenAI's API. No platform credentials, no billing data and no waitlist or contact lists are sent. If you do not use the generation features, nothing goes to OpenAI.

PostHog — product analytics and session replay

Receives what §4 describes: page views, automatically captured clicks and field focus, the browser, device type and country derived from the request, session replays of the pages you visit (masked to asterisks throughout the signed-in dashboard and the admin area), and — when you are signed in — your account id and email address as the person those events belong to. It also receives events raised by our servers with no browser involved, so that outcomes can be measured: checkout and top-up started, subscription changed, invoice paid, payment failed, top-up credited, and whether a scheduled post published or failed. Those server events carry a workspace identifier and plan or job details, never a customer's waitlist or contact data. The data is held in PostHog's United States cloud. Browser traffic reaches it through our own domain, which does not change the destination — see §4.

Resend — LaunchBeam's own transactional email

Used for mail the platform sends about itself, and therefore receives the recipient address and the message body for each: password-reset links (a one-time credential that grants access to the account), team invitations, and publish reminders. Our Resend account is deliberately notused for mail addressed to a customer's audience — though a workspace may separately choose Resend as its own sending provider below, under its own API key and its own agreement with them.

Your own email provider — audience email

The SMTP host or email API you configure receives the recipient address and message content for every waitlist welcome and sequence email your workspace sends. You choose this one.

Redis — queues and rate limiting

Short-lived job state and rate-limit counters. Email addresses are hashed before they appear in a key.

The platforms you connect

When a post publishes, its content and any attached media go to that platform under its own privacy policy and terms. That transfer is the feature.

We will keep this list current; write to [PRIVACY CONTACT ADDRESS] to be notified of changes or to request a data processing agreement.

8. Who else sees the data, and who does not

We do not sell personal data, rent it, share it for cross-context behavioural advertising, or use one customer's data to benefit another. Beyond the sub-processors above, data is disclosed only:

• to a small number of LaunchBeam staff who hold platform-administrator access for support and abuse investigation. That access is granted by explicit account identifier rather than by email address, can read across workspaces, and every grant and revocation is written to an audit table;
• to professional advisers under confidentiality, where we need advice;
• to a buyer or successor in a merger, acquisition, or sale of assets — we will tell account owners before their data moves;
• to authorities where we are legally required to, and we will notify you unless the law forbids it.

9. Your rights, and how to use them

Depending on where you live you have the right to access your data, correct it, delete it, restrict or object to processing, receive it in a portable form, withdraw consent, and complain to a data protection authority. Under US state privacy laws you also have rights to know, delete, correct, and opt out of sale or sharing — we do not sell or share personal data, so there is nothing to opt out of. We do not use your data for automated decision-making that has a legal or similarly significant effect on you; the AI features write drafts and decide nothing.

To exercise a right, email [PRIVACY CONTACT ADDRESS] from the address on your account. We respond within one month and will say so if we need the extra two months the GDPR allows for a complex request. We may need to verify who you are, and we will not use verification data for anything else. Exercising a right never costs you service or money.

If you are on a customer's waitlist or mailing list, see §1: the founder is the controller, but the unsubscribe link works instantly and we will help either way.

10. Getting your data out, and getting it deleted

Honestly, at this stage of the product:

• Export. Waitlist entries and email contacts can be exported to CSV from the dashboard whenever you like. There is no one-click export of an entire account yet — ask us and we will produce one.
• Deletion in the product. You can delete products, contacts, images, videos, connections, and team members yourself, and deleting a record removes its dependent rows with it.
• Deleting an account or workspace. There is no self-serve delete-my-account button yet. Email [PRIVACY CONTACT ADDRESS] and we will delete the workspace and everything hanging off it — products, campaigns, posts, connections and their encrypted credentials, waitlist entries, contacts, send logs and analytics rows.

11. How long we keep things

• Account, workspace and launch data — for as long as the workspace exists. Deleting the workspace cascades through the database and removes its dependent records with it.
• Cookies — exactly the lifetimes in §4.
• Analytics and referral click rows — kept while the workspace exists. Referral visit rows are designed to be prunable at 180 days, and automated pruning of older analytics rows is not yet in place; we will not pretend otherwise.
• Unsubscribed contacts and waitlist entries — kept with an unsubscribed-at marker rather than deleted, so that a later import cannot silently re-add someone who opted out. Suppression is the reason; outright deletion is still available on request.
• Billing records — for as long as tax and accounting law requires, which is [STATUTORY RECORD-KEEPING PERIOD].
• Backups and application logs — until they age out of the retention window our hosting configuration sets. A deletion request is honoured in the live database immediately and in backups as they expire.

12. Security

What we actually do:

• Platform and email credentials are encrypted with AES-256-GCM before storage, with the key held in the deployment environment and never in the database. Raw tokens are never stored and never logged.
• Every tenant table is protected by database row-level security, so one workspace cannot read another's rows even if application code gets it wrong.
• Values that identify a person are kept out of infrastructure that leaks by design: addresses are hashed before appearing in cache keys and masked in log lines, and secrets are redacted from any object we log.
• Passwords are hashed by Supabase Auth; we never receive them. Traffic is served over TLS.
• The ingest secret a customer's own application uses to post contacts to us lives in an isolated table, separate from the records it can write.

We hold no third-party security certification today — no SOC 2, no ISO 27001 — and we will not imply one. No system is perfectly secure; report anything you find to [SECURITY CONTACT ADDRESS] and we will work with you.

13. International transfers

LaunchBeam is a hosted service and its sub-processors operate internationally: Stripe, OpenAI and Resend are United States companies, our PostHog project is on PostHog's US cloud, the database sits at [SUPABASE HOSTING REGION], and the application and worker run at [APP HOSTING PROVIDER AND REGION]. If you are in the EEA, the UK, or Switzerland your data may therefore be processed outside your country. Those transfers rely on [TRANSFER MECHANISM]— such as the European Commission's Standard Contractual Clauses with the UK Addendum where it applies, or a finding of adequacy. Ask at [PRIVACY CONTACT ADDRESS] for the mechanism covering a specific sub-processor.

14. Children

LaunchBeam is a business tool and is not directed at children. You may not create an account if you are under 16, and we do not knowingly collect data from children under 16. If you believe a child's data has reached us, email [PRIVACY CONTACT ADDRESS] and we will delete it. Our customers must not use waitlist pages, contact ingest, or email sequences to collect or market to children.

15. Changes to this policy

When this policy changes, the new version appears at this URL with a new date at the top. We will email account owners before a material change takes effect, and we will never retroactively reduce your rights over data we already hold without asking you.

16. Contact

[LEGAL ENTITY NAME], [REGISTERED ADDRESS]. Privacy: [PRIVACY CONTACT ADDRESS]. Data protection contact: [DPO / DATA PROTECTION CONTACT]. Security: [SECURITY CONTACT ADDRESS]. You also have the right to complain to your local data protection authority.