Should I vibe code
Privacy-friendly web analytics with simple dashboards and no cookies
Your dashboard is a weekend. A third of the traffic on it is bots, and the bot list is the actual product.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
An endpoint that takes a POST and a table that counts rows is an evening, and the dashboard you get out of it will look extremely convincing. It will also be wrong, because roughly a third to a half of what arrives at a small site is automated, and the thing you did not build is the list of what to throw away. That is the whole difference between a counter and an analytics product, and it is not a list you can write — it is one somebody maintains. Cabin adds a second promise on top: no cookies, no IP retention, no fingerprinting, and therefore no consent banner. Make that claim on your own site and you have to be able to defend how you count a returning visitor without keeping anything that identifies one.
What actually breaks
not "if". the specific failures.
- Bot filtering, which is the product — without a maintained crawler list your traffic graph is a chart of how often uptime monitors and preview bots visit you
- The cookieless unique-visitor count, because the obvious implementation is a hash of IP and user agent, and if the salt does not rotate daily you have built a durable cross-day identifier and lost the claim you were making
- The URL path, which you are storing verbatim, and which on a real site contains password-reset tokens, invite links and occasionally an email address
- The referrer, which leaks the same things in the other direction and arrives from sites you do not control
- The ingest endpoint, unauthenticated by necessity, which anyone who views source can POST to a hundred thousand times
- Retention, since Cabin's paid promise is that the data never expires and yours will be a table you eventually truncate because a query got slow
- The carbon figure, if you copy that feature, because a number you computed yourself and published on your own site is a marketing claim about your business
Is that you?
the verdict is a default, not a law
- It counts page views on sites you own, for your own curiosity
- You store a path, a referrer and a timestamp, and nothing that could identify a person
- A crawler list is applied at ingest and updated from a maintained source rather than by hand
- You would shrug if the whole table were lost tomorrow
- Anybody is making a decision on the numbers that costs money
- You are publishing a privacy claim — no cookies, no tracking, GDPR-compliant — that you have not personally traced through your own schema
- The visitor identifier is a hash that lives longer than a day
- Raw paths and referrers go into the same table you back up, export and hand to an LLM
- You are keeping it for someone else's site as a service
If you build it anyway
the checklist, then the prompt that enforces it
- Apply a maintained bot list at ingest, from a source that updates itself, and record how many events it dropped. If you cannot see the discard rate, you cannot tell an audience from a crawler.
- If you count unique visitors without cookies, derive the identifier from a salt that rotates at least daily and is never stored alongside the events. A stable hash of IP and user agent is a persistent identifier wearing a disguise, and it is the specific thing that breaks the no-consent-banner claim.
- Strip query strings and fragments from paths before storage, with an explicit allowlist for the UTM parameters you actually want. Reset tokens and invite links live in URLs.
- Never store the raw IP address. Derive the country, derive the hash, discard the address in the same request — not in a nightly cleanup job that can fail.
- Rate-limit the collection endpoint per IP and per site key and cap the payload size. It is public by design and it is a free write into your database.
- Decide the retention period before the first event and enforce it with a scheduled deletion you have tested, because the honest version of privacy-first is a table that forgets on time.
- Write your privacy claim down as a checklist against your own schema, column by column, and re-check it whenever you add a field. The claim is the product here, and it degrades quietly.
I am building cookieless web analytics for my own sites. Build it privacy-first
in fact rather than in the README, and challenge me when I ask for a field that
breaks the claim.
1. Start with the schema and tell me, column by column, what each field can
reveal about an individual. Refuse to add a column until I say why I need it.
2. Never persist a raw IP address. Derive country and a daily-rotating salted
hash inside the same request and discard the address before anything is
written. The salt must rotate at least every 24 hours and must not be stored
with the events. Explain to me why a stable hash of IP plus user agent is a
persistent identifier and would cost me the no-consent-banner position.
3. Strip query strings and fragments from paths at ingest, with an explicit
allowlist for UTM parameters. Assume paths and referrers contain reset
tokens, invite links and occasionally an email address.
4. Apply a maintained crawler and bot list at ingest before anything is counted,
pull it from a source that updates, and expose the number of events it
dropped in the dashboard. Tell me the dashboard is not trustworthy without it.
5. Rate-limit the collection endpoint per IP and per site key, cap the payload
size, and reject events for unknown site keys. It is a public write path.
6. Implement retention and deletion before the dashboard: a stated period and a
scheduled, tested delete. Show me the deletion running.
7. Then build aggregation — daily rollups written once — and query the rollups
rather than the raw events, so the raw table can expire without the history
disappearing with it.
8. Backup and restore for the rollup table specifically, and prove the restore.
The multi-year graph is the only part of this that cannot be regenerated.
9. Do not implement session stitching, cross-site identity, or any per-visitor
profile. If I ask, say no once and explain what it does to the claim.
10. Out of scope: carbon estimates, funnels, anything on someone else's site. If
I want to publish an emissions number, say that is a public claim about my
business, not a feature — and that Cabin is $19 a month with a free tier.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
When you start quoting the numbers to somebody else. Nineteen dollars a month buys a bot list somebody maintains full-time, a privacy position their lawyers signed off, and retention that outlives your interest in the project — and the free tier covers a single site, which is enough to check your own figures against theirs. Self-hosting stays perfectly defensible if the numbers are only ever for you.
The script tag is one line, so switching back is genuinely trivial — that is the reassuring half. The half that is not: whatever you did not keep is gone, and there is no backfill for web analytics. Write daily rollups from day one, back up the rollup table rather than the raw events, and export in a shape you could load somewhere else. Whichever tool you end up on, keep both scripts on the page for a fortnight so you can see how far apart the two counts are, because they will not agree and you want to know by how much before you trust either.
Open-source cookieless analytics; the reference implementation for salted-hash visitor counting and a bot list you do not have to write.
Lightweight self-hosted analytics that runs happily on a small box next to the site it measures.
Minimal analytics you deploy to Cloudflare Workers; a good read if you want to see how small the honest version is.
Questions
Plausible and Umami are ship-it here. Why is this one demo-only?
Because those entries are about owning the counter, which is genuinely a good idea, and this one is about the specific thing Cabin sells: accuracy and a privacy position strong enough to skip the consent banner. The counter is a weekend. Being able to say your numbers are visitors rather than crawlers, and that your identifier cannot be reversed, is a maintained commitment rather than a feature — and it is the part that quietly does not survive the second month.
How wrong will my numbers actually be?
Wrong enough to change conclusions rather than wrong in the third decimal place. Uptime monitors, link preview fetchers, feed readers, AI crawlers and security scanners all execute or fetch enough to register, and none of them are your audience. The failure is not that the total is inflated — it is that the inflation is uneven, so one page looks popular because something checks it every five minutes.
Is cookieless really enough to skip the consent banner?
It is the strongest available position and it is why products like Cabin are built this way, but it rests entirely on the identifier being genuinely non-durable. Hash IP and user agent with a fixed salt and you have created a pseudonymous identifier that persists across days, which is exactly the thing the banner exists for. Rotate the salt daily, never store the raw address, and the claim holds. It is a twenty-line difference and it is the whole argument.
What about the carbon reporting?
Leave it. Cabin's emissions estimate is a nice feature for them and a liability for you, because the moment you publish a figure derived from your own model on your own site, it stops being an internal metric and becomes a green claim about your business. If you want the number, the transfer-size measurement is the easy part and the grid-intensity assumption is where every disagreement lives.
- GDPR Art. 5 — principles, including data minimisation and storage limitation
- GDPR Recital 26 — when pseudonymised data is still personal data
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.
Cookieless analytics is one salt away from a permanent visitor ID. Rotate it at midnight and never write it down.
Counting page views without cookies is a POST and a table. This one you should own.
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice