Should I vibe code
Privacy-focused website analytics with simple dashboards
The dashboard is a weekend. The five-year graph is the product, and you get it only by never losing the table.
?
Their verdict, the Standard 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
Build it. A collection endpoint and an aggregate table is honest work with a small blast radius, and this is one of the few categories where doing it yourself also improves the privacy story. The only thing worth taking seriously is that the value is in the length of the series, and a series is the one asset you cannot recreate after you lose it.
What actually breaks
not "if". the specific failures.
- The series, the first time you change the schema and decide the old rows are not worth migrating
- One server holding one table that nobody has ever restored from a backup
- A tracking script that 404s after a deploy, so the flat week in the graph is a routing change rather than a quiet week
- Bot traffic, which on a small site is a large fraction of raw hits and makes every total wrong until it is filtered
- Where the data physically lives, which is a claim on your privacy page and a fact about your hosting provider
- Timezone and session-boundary changes, which retroactively make last year disagree with this year
Is that you?
the verdict is a default, not a law
- The aggregate table is backed up somewhere you have actually restored from
- You store no cookie and no raw IP, and the privacy page says only what the code does
- It counts your own sites and the numbers are for you
- Every schema change comes with a migration for the history, not a fresh start
- There is one copy of the data and no tested restore
- You keep raw IPs to deduplicate visitors
- The tracker's health is unmonitored, so a broken script looks like a bad month
- You are counting other people's sites without their visitors being told
If you build it anyway
the checklist, then the prompt that enforces it
- Back up the aggregate table on a schedule and restore it into a scratch database at least once. Analytics history cannot be backfilled — a lost table is a lost decade of context.
- Aggregate on write into daily rollups and keep those separate from raw events, so retention on the raw side never costs you the series.
- Version the schema and migrate history forward with every change. The temptation to start clean is how most self-hosted analytics quietly become six-month-old products.
- Monitor that the tracker is firing — alert on zero events for an interval that would be abnormal. A silent collection failure and genuinely low traffic look identical on a chart.
- Filter bots before storage, and record the filter version alongside the rollup, so a change in filtering is visible as a change in method rather than a change in traffic.
- If you need daily uniques, hash IP and user agent with a salt that rotates at midnight and store only the hash. Never persist the raw inputs.
- Write down where the data is hosted and in which jurisdiction, because that is part of what a privacy analytics product is actually selling.
Before you build privacy web analytics I intend to keep for years, apply these and push back if I ask you to break them.
1. Treat the historical series as the asset. Design storage and backups first,
the dashboard last, and tell me plainly that analytics data cannot be
recreated once lost.
2. Separate raw events from daily rollups from the start, and roll up on write.
Retention applies to raw events only; the rollups are permanent.
3. Automate a backup of the rollup table and write me a restore script — then
tell me to run the restore before I trust the system, not after.
4. Version the schema. Every change ships with a migration carrying the history
forward. Refuse to solve a schema problem by truncating.
5. Add a health check that alerts when no events arrive for an interval I set.
A tracker broken by a deploy renders as a quiet week and can go unnoticed
for months.
6. Filter bots before storage, and record which filter version produced each
rollup so a methodology change is distinguishable from a traffic change.
7. Do not set cookies. For daily uniques, hash IP and user agent with a
midnight-rotating salt, store only the truncated hash, never the inputs.
8. Strip query strings from stored paths or allowlist parameters explicitly —
URLs carry reset tokens, email addresses and search terms.
9. Keep the collection endpoint fast and non-blocking and the client script
small.
10. Write the privacy page from the implementation, including which country the
data sits in, and tell me if a change I ask for makes a claim untrue.
11. Out of scope unless I ask: funnels, per-user journeys, session recording,
any identifier that outlives a day.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
$15 a month is the highest entry price among the privacy analytics tools we cover, for a build that is a POST and a table. Build it — but be honest that what you are declining to pay for is durability, and put the effort you saved into a backup you have restored from at least once.
The exit plan and the backup plan are the same document. Keep daily rollups — date, path, referrer group, count — in a plain table you can export as CSV, because that is the entire dataset and it is small enough to keep forever. Anything that only exists as a chart in your app is gone the day the app is.
Open-source privacy-focused analytics platform and the most practical DIY starting point.
Open source and self-hostable, with the aggregation and rollup design already worked out.
Questions
You already rate Plausible and Simple Analytics as SHIP IT. Why another one?
Because each fails differently. Plausible's entry is about measurement honesty — bots, blockers, what the number means. Simple Analytics' is about keeping a published privacy claim true as the code changes. This one is about durability: the reason to pay for analytics at all is that somebody else keeps five years of your history alive, and that is the part a self-hosted instance loses quietly.
How does analytics history actually get lost?
Rarely by a dramatic outage. Usually a schema change where migrating a year of rows looks like more work than starting fresh, or a server rebuild where the database was not in the backup set because it was 'just analytics'. Both are decisions taken in ten minutes that cannot be undone at any price, which is why the rollup table deserves the same treatment as customer data.
Does it matter where I host it?
It matters to the claim. Fathom sells EU-based processing as a feature because for some buyers the jurisdiction is the point. If you self-host, your answer is whatever region you clicked during setup — which is fine, as long as your privacy page says that rather than something more flattering.
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.
No cookies, no personal data, no banner. Also no reason to pay $20 a month.
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
Nobody wants a website builder. They want to change the opening hours on a Sunday without texting you.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice