Should I vibe code
Privacy-first website analytics without cookies or personal tracking
No cookies, no personal data, no banner. Also no reason to pay $20 a month.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A pixel, a counter and a chart. If you resist the temptation to add per-visitor tracking it stays trivially safe and genuinely useful.
What actually breaks
not "if". the specific failures.
- The claim, because 'no personal data' is a statement you have to keep true as the code changes rather than one you make once
- A debug log that writes request headers, which quietly stores the IP addresses your privacy page says you do not collect
- Query strings in page paths, which carry email addresses, tokens and search terms into your analytics table
- Third-party services in the pipeline — a hosting provider's logs, an error tracker — that keep what you deliberately did not
- The banner question, since claiming you need no consent banner is a legal position that depends on the implementation staying honest
The privacy page says no personal data is stored, and it was true when written. Months later you add error logging to debug a spike, and the handler logs the full request — headers included — to a file that gets shipped to a log service. IPs are now retained, in a third-party system, on a site that publicly says they are not. Nobody notices because nothing changed on the dashboard. The statement on your privacy page simply stopped being true, quietly, as a side effect of debugging.
Is that you?
the verdict is a default, not a law
- Every claim on your privacy page is checkable against the code
- Paths are sanitised before storage and query strings are dropped
- You periodically re-read the code against the promise
- Request logs anywhere in the stack retain IPs you claim not to collect
- Full URLs including query strings are stored
- You are making a no-consent-needed claim you have not actually checked
- The privacy statement was written from intent rather than implementation
If you build it anyway
the checklist, then the prompt that enforces it
- Treat the privacy page as a specification and re-check it against the code on a schedule. The claim is the product here, more than the dashboard.
- Sanitise paths on write: strip query strings entirely, or allowlist the parameters you need. URLs carry more personal data than anything else you collect.
- Audit the whole pipeline, not just your handler — web server logs, CDN logs, error trackers and hosting platforms all retain what you did not.
- Never log raw requests, even temporarily. Debug logging is the most common way this promise breaks.
- Write down what a consent-free claim depends on, so a future change that invalidates it is visible.
- Publish your numbers or your method if the honesty is the point, since an unverifiable privacy claim is just marketing.
Before you build analytics that claims to be privacy-first, apply these and push back if I ask you to break them. 1. Treat my privacy statement as a specification. Write it from what the code actually does, and tell me whenever a change I request would make an existing claim untrue. 2. Strip query strings from paths before storage, or allowlist specific parameters. Explain that URLs routinely carry email addresses, reset tokens and search terms, and that storing full URLs is the most likely way personal data enters an analytics table. 3. Never log raw requests or headers, including during debugging. Tell me this is the single most common way a no-personal-data promise quietly breaks. 4. Audit the whole stack for retention I did not choose: web server access logs, CDN logs, error tracking, platform logs. List everything that sees a request and what it keeps. 5. If a daily unique count is needed, hash with a rotating salt and store only the hash. Never persist raw IP or user agent. 6. Document what any consent-free claim depends on, so a future change that invalidates it is obvious rather than silent. 7. Set a retention period for aggregates and implement deletion. 8. Filter bots before storing anything. 9. Out of scope unless I ask: user-level journeys, session recording, any persistent identifier.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
$20 a month is the highest price in this group for the least code, which is why the hot take is blunt. Build it — and spend the saved effort on keeping the privacy claim continuously true, because that is the part with real value and the part that decays silently.
Export aggregates as a plain table and keep the privacy statement in version control next to the code, so the history shows what was claimed and when. If the claim is the product, its provenance is part of the data.
Open-source web analytics platform for privacy-friendly tracking.
Questions
How is this different from the Plausible entry?
Plausible's entry is about measurement honesty — bots, blockers, what the numbers actually mean. This one is about the promise: privacy-first is a claim you publish, and keeping it true across debugging sessions, log configuration and third-party services is ongoing work rather than an initial design decision.
Why are query strings such a common leak?
Because they are part of the path and get stored without anyone thinking about them. Password reset links, email-confirmation links, search queries and shared documents all put identifying information in the URL — so a table of visited URLs frequently contains exactly the personal data the tool was built to avoid collecting.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
Counting page views without cookies is a POST and a table. This one you should own.
Twenty lines of code. But every link you shorten is a permanent promise to keep a server alive.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice