Privacy Policy

Accounts are handled by Clerk. When you sign up, Clerk stores your login details — your email address, and whatever a social login (for example Google or GitHub) hands over, such as your name and profile picture. We read your identity from Clerk; we do not store your password, and we never see it.

Clerk sets cookies in your browser to keep you signed in. Clearing them signs you out.

Some things that happen on the site result in an email. When one goes out, your email address and the text of the message are handed to Resend, which delivers it. The address comes from your Clerk account, described above.

Today that covers: a note when another member asks to connect with you, a note when a connect request you sent is accepted, and a reminder when a request has waited three days for your answer; a note when someone comments on your post or replies to your comment; once we switch it on, a note right away when someone @mentions you in a post, a comment or a task, or assigns you a task, at most eight of these a day, with a switch for each under Settings, then Notifications; a weekly summary of likes, new posts, updates from your Spaces and comments you missed, sent once a week and only when there is something to report; a section in the weekly email, once we switch it on, listing upcoming events, new courses and new library items gathered from public sources, on by default, the same for every member and using nothing about you, with a switch to turn that part off under Settings, then Notifications; a note to a Space’s owners when someone asks to join, and to you when your request to join is approved; and, in a Space running the Beamy operator, a request to approve something Beamy wants to do. Once we switch it on, a member who launched in the Launch League gets one email on the Monday after, with the likes and rank of their own launch and who won, on by default, with a switch to turn it off under Settings, then Notifications. We also send up to two notes tied to where you have got to: a welcome when you sign up, and then one follow-up at most, either a reminder if three days have passed and you have not finished setting up your profile, or a nudge to take a first step if you finished setting up three days ago and have not done anything on the site since. Each of these is sent once.

Members can also invite someone by email. We send that person an invitation at the address the member typed. That address is stored with the invite and handed to Resend to deliver it, whether or not the person has an account here.

You can turn off the comment, like, new post, Space update, mention, task assignment and connect reminder emails under Email settings, or from the unsubscribe link in those messages. The two notes about joining a Space follow the Space updates setting. The notes about a new or accepted connect request, and the Beamy approval requests, have no off switch yet. The welcome goes out as soon as you sign up, so it cannot be turned off beforehand. The set-up reminder and the first-step nudge can be turned off under Email settings, with the switch “Set-up reminder emails”. Each of the three also carries an unsubscribe link, and using it stops any further ones.

Email is off entirely unless the site is configured with a Resend key.

Your profile, posts, projects, spaces, comments, likes, and challenge completions are stored in a Supabase Postgres database. Anything you post inside the community is visible to other signed-in members. Some things are public to the whole internet only if you opt in — public project pages and public builder profiles are off by default.

Files you upload — avatars, project images, attachments — go to Cloudflare R2. Your browser uploads them straight to R2 using a short-lived signed URL, so the file itself does not pass through our servers. The bucket is served publicly, which means anyone with the file’s URL can open it.

We use PostHog to see which pages and features get used. It records page views and product events. We also record when you create a post, task, comment or note, without its text. This only runs when the site is configured with a PostHog key; where it is not configured, no analytics are sent at all.

PostHog also makes session recordings — a replay of what a page looked like as you used it, so we can see where the product is confusing or broken. These recordings cover the member-facing parts of the site and they are not blurred out: they can include private content that was on your screen at the time, such as the text of a note you were writing, the reason you gave when reporting something, and what you typed into form fields like your name or email address.

Password fields are always excluded. What you type into a password box is never captured in a recording, without exception and regardless of any other setting.

The admin console is never session-recorded. That carve-out exists to protect other members: an admin working in there is looking at other people’s data, and none of it should end up in a replay. Ordinary analytics events (which page was opened, which button was pressed) are still collected on admin screens, the same as everywhere else — it is only the screen recording that is switched off.

To be straight with you, that admin carve-out is a best-effort technical boundary rather than an absolute guarantee. If an admin moves from a normal page into the admin console without a full page reload, a very small amount of screen content from the first moments of the admin page — typically a fraction of a second — can still be included in the recording that was already in progress. This happens because stopping a recording sends the footage it has already buffered rather than throwing it away, and the filter that blocks admin footage can only accept or reject a whole batch at a time. We have not hidden this; it is a known limitation and we would rather state it than over-promise.

We use Sentry to find out when something breaks. When an error happens, in your browser or on our servers, Sentry receives a report of it: the error message, a stack trace showing which code failed, the page or request it happened on, and basic browser or device details. Sentry also times a sample of requests, so we can see what is slow.

Reports are sent through a path on this site rather than straight to Sentry’s own address.

An error message can end up quoting something you typed, when what you typed is part of what went wrong. We have left off the two settings that would widen a report further: Sentry’s own session recording is switched off here, since PostHog does that job as described above, and the option that attaches your account details to every report is left at its off-by-default setting. Error reporting is off entirely unless the site is configured with a Sentry key.

If you use the avatar generator, the prompt is sent from our server to fal.ai, which generates the image and returns it. The resulting picture is stored with your profile like any other upload. This feature is off entirely unless the site is configured with a fal.ai key.

Flower stickers. On the 20/10 page, a signed-in member can turn a flower photo into a sticker. The photo, made smaller in your browser first, is sent from our servers to fal.ai, which draws the flower back as an illustration. We ask fal.ai not to keep the result in its request history, and we do not store the photo or the drawing: the sticker and your bouquet stay in your browser. If you are not signed in, or the site has no fal.ai key, the sticker is made on your device and nothing is sent.

Three features send text to Google’s Gemini API. In each case the text is sent from our servers, not from your browser.

Space suggestions. When you describe a problem you want to work on — on the signup wizard, or on the “Start from a problem” tab of the new Space page — that description is sent to Gemini, which writes back suggested Space names, a tagline, starting tasks, and the kinds of help your problem might need. If you are signing up, what you wrote is saved to your profile; if you create a Space, it becomes that Space’s description. We do not put it in the analytics events we track. The problem box (on the signup wizard and the new Space page) is kept out of session recordings; other form fields, including the profile review, can still appear in them, as described above. This feature is off entirely unless the site is both switched on for it and configured with a Gemini key; while it is off, a built-in template writes the suggestions instead and nothing from this step is sent to Google.

On the signup wizard, after you describe a problem we may ask Gemini up to five short follow-up questions about why it happens; each one sends your problem and the answers you picked so far. Your answers are not saved to your profile. If you create a Space from this step, the last cause you picked is added to that Space's description. The problem box and the answer boxes are kept out of session recordings. If AI suggestions are switched off, built-in questions are used and nothing from these questions is sent to Google.

Practice. The message you type to the Practice tutor is sent to Gemini so it can reply, along with the brief for the task you are working on and the recent messages in that conversation. The practice games work the same way: what you type is sent to be graded, and in the capstone the answers you have already given travel with the next one, so the tutor asks something new instead of repeating itself. This is off entirely unless the site is configured with a Gemini key.

Beamy. A Space can have a Beamy teammate that proposes tasks. When it runs, we send it the material that run needs to make a sensible proposal, which can include: the Space’s name, tagline and description, its task titles and descriptions, the comments on the task it is working on, recent updates posted in the Space, activity from a connected repository, the names of the people in the Space, and its own notes from earlier runs. Beamy is off entirely unless it is configured with a Gemini key, and a Space owner can switch it off.

The live visitor counter on the home page is built to count people without identifying them. Concretely, for each visit we store:

• a random session id, generated in your browser and kept in sessionStorage — it is thrown away when you close the tab;
• a two-letter country code, which our hosting platform derives from your connection (the x-vercel-ip-country header). Country is the finest location detail that exists anywhere in this system;
• the page path you are on, checked against a strict allowlist pattern before it is saved — no query strings.

We do not store your IP address, your user agent, or your referrer. There is no link between a presence row and any user account, and no way to follow one person across separate visits.

Retention: the live table keeps a row for at most 90 seconds after your last heartbeat, and a scheduled job deletes anything older every minute. A second, permanent table keeps one row per session — session id, country, timestamp — purely as the running total behind “N visits since <date>”.

One extra detail, for completeness: to stop one person inflating the live count, a temporary throttling fingerprint is attached to the live row. It is never copied into the permanent ledger, never logged, and disappears with the row inside 90 seconds.

Only the services named above: Clerk, Supabase, Cloudflare R2, PostHog, Sentry, Resend, fal.ai, Google (the Gemini API), and our hosting platform. We do not sell your data and we do not share it with advertisers.

You can edit or clear your profile at any time from your settings. To delete your account and the content attached to it, contact us via the about page.

When these practices change, this page changes with them and the date at the top moves. There is no separate notification.