Privacy Policy
This policy explains what Vibe Coder Playground collects when you join the early-access list, why we collect it, how it's stored, and the control you have over it. Plain language, no surprises.
Who we are
Vibe Coder Playground is operated by Vibe Coder Playground LLC. For any privacy question — including a request to see or delete your data — email contact@vibecoderplayground.ai.
What we collect
Only what you give us through the early-access form: your name and email address, and a few short questions:
- Your phone number, only if you choose to give it
- Where you are with AI, from brand new to having people use what you built
- Whether you have AI-built products people use, and roughly how many
- Your team size
- Whether you're interested in future features (cloud workspace, team collaboration, multi-seat management)
From those answers we sort you into one of three email tracks (free, cloud or enterprise) and pick a few starting suggestions, so the emails you get fit where you are. We also store the date you signed up and which page you came from. We do not collect payment details, we never text you without asking first, and the app itself runs on your own machine. It doesn't send your projects or code to us.
Why we collect it
To email you your download link, to let you know when new builds and features ship, and to understand who our users are so we can build the right things. Nothing more.
Your consent, and confirming it
We only add you to the list because you asked us to. To make sure it's really you, we use double opt-in: after you sign up, we email you a confirmation link, and you're only added once you click it. That confirmation is the legal basis for the email we send you.
How it's stored, and who touches it
Your details are stored in a database on Amazon Web Services (AWS), and our emails are sent through Amazon SES. AWS acts as our data processor; we don't sell, rent, or share your data with anyone else, and we don't use third-party advertising or tracking. The website uses your browser's local storage only for on-page features (like counting page views on your own device) — no cross-site tracking cookies.
Unsubscribing and deletion
Every email we send carries an unsubscribe link — one click and we stop. You can also email us to ask what we hold about you or to have it deleted entirely, and we'll do it. We keep your data only until you unsubscribe or ask us to remove it.
Where you are
If you're in a region with data-protection rules such as the EU/UK (GDPR) or California (CCPA), you have the right to access, correct, or delete your data and to withdraw consent at any time. Email us and we'll honor it.
What people search for on this site
The Coding Guide has a search box. When a search settles — we wait until you've stopped typing, so we don't record every half-finished word — we record the words you searched for, how many articles came back, and which ones. Searches that find nothing are the ones we most want to see: an empty result is somebody telling us which article to write next.
What we record is the search, not the searcher. We do not store your IP address, or anything derived from it, or your browser's user agent, or any session or visitor identifier. We set no cookie for this and store nothing on your device. There is nothing in what we keep that links one search to another, or to you, or to your email address if you happen to be on our list.
Searches are counted, not listed. We keep one row per distinct phrase with a tally next to it — so "42 people searched for dynamodb and got nothing" — rather than a log of individual visits.
Before a search is stored we drop anything shaped like an email address and replace it with the word [email]. People do paste addresses into search boxes by accident. We can't filter everything a search box might be sent, so please don't type anything private into it — but we won't keep an address we can spot.
Search terms are deleted after 90 days, counted from the last time anyone searched that phrase. That deletion is performed by the database itself on a timer, not by us remembering to do it.
When you browse this site
This site measures its own visitors, with the same cookieless collector the Playground gives you for the apps you build. We run on the thing we sell, so what follows is also a fair description of what your visitors would get.
What is recorded. Each page you open, and the host you arrived from (google.com, a newsletter, or nothing at all) rather than the full address. Clicks on links and buttons, with the click's position stored as a fraction of your window rather than in pixels, which is what a heat map is drawn from. When what you clicked was a link, we also record which link it was, by where it was going: the page address on this site with everything after the "?" removed, or, for a link to somewhere else, only the name of the other site. A button has no destination, so nothing is recorded for one. Campaign tags in the address, when a link carries them. Uncaught errors, so a page that breaks tells us instead of you.
What is not recorded. No cookie. Nothing is stored on your device unless you refuse the visitor number below, and then it is one flag and nothing else, with a single exception: on a page that is running a split test, the script also remembers which version you were shown, for that tab only, and your browser discards it when you close the tab. Your IP address and browser user agent are never written down: the collector uses them once, in memory, to work out a visitor hash, and drops them. That hash is mixed with today's date, so you are a different number tomorrow and nothing links your visits across days. We get counts, not a file on you. There is no login here, and nothing we record is joined to your email address if you are on our list.
Where it goes, and for how long. To our own collector on our own Amazon account, not to Google Analytics or any advertising network, and nothing is sold or shared onward. Events are deleted after 90 days by the storage itself, on a timer, rather than by us remembering.
If you would rather not be counted. Turn on your browser's tracking protection, or block vibe-analytics.js with any content blocker. Nothing on this site needs it: every page works exactly the same with it blocked, because it reports and never decides.
If you would rather be counted without a visitor number. Your browser can refuse the number for you and we obey without being asked: if it sends Sec-GPC (Global Privacy Control) or DNT (Do Not Track), the collector works out no visitor hash for your visit at all. There is no setting on our side that can override that, and we did not build one. You can also refuse it yourself, on this device, with the button below or by opening any page here with #vibe-analytics-opt-out on the end of the address. That sets one flag in this browser's local storage, under the name vibe-analytics-no-visitor-id, holding no identifier, and, on a page that is not running a split test, it is the only thing this site stores on your device. It is there so the refusal lasts longer than one page, which is the reason it is the one thing here meant to outlast the tab. Clearing this site's data undoes it, as does the second button.
What that changes, and what it does not. Your page views, clicks and errors are still counted, because a visit is worth counting and a person is not worth identifying. What stops is any figure that needs to recognize one person: the event is stored with no visitor number on it at all, not an empty one and not a shared one, so our reports leave those visits out of unique visitors, single page rate and journeys, and tell us how many were left out instead of folding them into one visitor or reporting them as none.
The analytics pixel, and the visitors of apps you publish
If you use the Playground's analytics on an app you publish, what it records is not about you. It is about your visitors. So this section is about their data, and the first thing to say about it is where it goes.
It does not come to us. The tracker script and the pixel post to a collector you deploy, and the events land in your storage: a local file store out of the box, or a database you connect. A generated snippet carries no default address and no fallback host on purpose, because a snippet pointing somewhere you did not choose would send your visitors' page views to a stranger. We hold none of it and cannot read it. You are the controller of that data, and the site you publish needs its own privacy notice; ours cannot stand in for it.
The ad pixel is first-party and cookieless. It is a 1x1 transparent GIF with an id of its own (18 random bytes), one per app, so it can be pasted into an ad platform or an email. It sets no cookie, builds no cross-site profile, and is not an ad-network pixel: it reports to no third-party advertising platform, nothing it collects is combined with data from other sites, and none of it is sold onward.
What one hit stores. The event type (a page view, or a conversion, which is recorded as a goal); the time and the UTC day; the page path with the query string stripped and the rest run through the same redactor that scrubs crash reports; the referring host only, and a coarse label for it (direct, search, social, referral, or your own site); your campaign's utm source, medium and name, reduced to plain identifiers; on a conversion, an amount within a sane ceiling and a three-letter currency code or nothing; the site key, which is the storage bucket and the name of the file the events land in (the pixel id when the hit carries one, and otherwise the site name the caller sent); on a click of a link, where that link was going, which is the page path on the same site with the query string stripped, or only the host of another site; and a per-day visitor hash. Free-text fields (an event name, a click label, a clicked link's destination, the site key, custom metadata keys and values alike) are redacted and length-capped, because the pixel is a public URL and anything can be sent to it.
What it does not store. No cookie, on any page, ever. The tracker script puts at most two kinds of thing in a visitor's browser storage, and these are both of them. The first it puts there only if that visitor asks it to: a single flag under the name vibe-analytics-no-visitor-id, holding no identifier, recording that they have refused the per-day visitor number. It is the same flag, and the same button, described for this site above, because your visitors run the same script we do. The second appears only on a page where you are running a split test: the name of the version that visitor was shown, one entry for each test the page is running, kept for that tab only, holding no number and no identifier, so that the page does not change under them while they read it. Their browser discards it when they close the tab, which is why it cannot connect one visit to a later one, and if their browser refuses to let a site store anything the page still works and the version is simply chosen again each time. A visitor who never refuses has nothing stored on their device at all, unless they are on a page running one of your split tests, and the 1x1 GIF pixel is an image and stores nothing either way. The raw IP address and browser user agent are never written down. They are used once, on the server, to compute the visitor hash, and then dropped. That hash is salted with the current UTC date, so the same visitor hashes differently tomorrow and nothing can link them across days. It buys you unique-visitor counts without durable tracking, and it is why cross-day retention is not measurable here, and is never presented as if it were.
What a hit carries only sometimes. Where a site is trying alternative versions of a page to see which works better, a hit also records which test the visitor was in and which version they were shown, and whether that version could be remembered for their tab or had to be chosen again on every page because their browser refuses to let a site store anything. That last one is there so the two groups are never averaged together in a report, because a visitor who saw one version all visit and a visitor who was re-rolled on every page were not in the same test. Where a page hits an error the browser could not handle, the hit records the text of that error and where in the site's code it happened, both run through the same redactor as the rest, so file paths and anything that looks personal are stripped out.
How long. Raw events are deleted after 90 days by a sweep that runs once at start-up and then daily, and that records when it last ran, so an installation that has never swept says so instead of looking clean.
Where that sweep runs matters, so we say it plainly. It runs inside the Playground, over the storage the Playground is pointed at. If you deploy the collector on its own and no Playground is running against that same storage, nothing is purging it: point the Playground at it, or apply the same 90-day window at your own database. The data is yours, and so is that obligation. The standalone collector we publish for Amazon Web Services is the one exception: it hands each event an expiry when it stores it, and the database deletes it when that expiry passes, using the retention window you set at deploy time, which is 90 days unless you change it.
Revoking a pixel, precisely. You can revoke an id on its own without disturbing your site's own pages, and the Playground stops attributing it to your app. The collector is designed to run separately from the Playground and has no access to your pixel registry, because the id is the storage key, so hits carrying a revoked id are still accepted into a bucket named after it. Revoking is not a kill switch at the collector.
Anonymous usage counts in the Playground app
Free use includes anonymous usage counts. The free Playground app counts how often each feature is used: which code block was installed, which audit was run, and when a site was started. One count holds the item, the channel ("playground" from the app, "mcp" from our MCP server), the calendar day and a one-time random number that stops a retried send counting twice. It never holds who you are or anything you wrote. Counts are added to a daily total the moment they arrive, and the one-time numbers are deleted within three days.
Consent or pay. On the free plan the counts cannot be switched off, so the download asks first. The download page releases the app only after you tick an agreement that says so, and we record the terms version you agreed to and the time, with nothing about you. A paid plan can switch the counts off in the app's Admin page. Our MCP server counts its own successful tool calls the same way, and tells your client so when it connects.
Changes to this policy
If we change what we collect or how we use it, we'll update this page and the date at the top. Material changes to how we email you will be opt-in.