Should I vibe code
Open-source privacy analytics with a hosted cloud option
Self-hosting analytics is the one case where doing it yourself is also the privacy-correct answer.
?
Their verdict, the Basic 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
The open-source version exists, runs anywhere and costs nothing. Building or hosting your own means visitor data never leaves infrastructure you control.
What actually breaks
not "if". the specific failures.
- Table growth, because raw events accumulate faster than anyone expects and queries slow before storage runs out
- The collection endpoint being down, which loses data permanently — there is no retry from a browser that has navigated away
- Upgrades on a self-hosted instance, where a migration on a large events table can take longer than you planned
- Backups of a database whose value is entirely its long history
- Being on the same host as the site it measures, so an outage takes the measurement of the outage with it
The instance runs quietly for a year, which is what you wanted. Then the dashboard gets slow, and slower, and you look: several million raw event rows, no aggregation, no retention policy, and an index that no longer fits comfortably in memory. Nothing is broken. The data is all there. It is simply an amount of data you never decided to keep, accumulating from a default nobody chose, and the fix now involves a migration on a table you cannot afford to lose.
Is that you?
the verdict is a default, not a law
- You aggregate on write or roll up on a schedule, and set a retention policy
- Backups are tested and the history is what you are protecting
- It runs somewhere separate from the site it measures
- Raw events accumulate forever with no rollup or retention
- It shares a host with the site being measured
- You have never restored the database
- Nobody owns upgrades on the self-hosted instance
If you build it anyway
the checklist, then the prompt that enforces it
- Decide retention and rollup before the first event. Aggregating daily and discarding raw rows after a window keeps this small forever.
- Host the collector separately from the site it measures, so an outage is recorded rather than invisible.
- Test a database restore before you have a year of history worth losing.
- Keep the endpoint fast and fire-and-forget from the browser — a slow collector loses events and slows pages at the same time.
- Plan upgrades on a copy, since migrations against a large events table behave differently than they did in testing.
- Prefer self-hosting the real Umami over writing your own, and treat the choice as an operations decision rather than a build.
Before you self-host or build web analytics, apply these and push back if I ask you to break them. 1. Ask me why I am not self-hosting Umami itself, which is open source and solves this. If the answer is curiosity, that is fine — but tell me the ongoing cost here is operations rather than code. 2. Decide retention and aggregation before the first event is stored. Roll up to daily aggregates and discard raw rows after a defined window. Explain that raw events accumulate faster than expected and the dashboard slows long before the disk fills. 3. Run the collector on separate infrastructure from the site it measures, so an outage on the site is recorded rather than invisible. 4. Make the client send fire-and-forget with a beacon, and make the endpoint return immediately. A slow collector both loses events and slows the page. 5. Set up database backups and restore from one into a clean environment before accumulating history worth protecting. 6. For upgrades, snapshot and migrate a copy first. Migrations against a large events table are not the same operation they were in testing. 7. Filter bots before storage, and never persist raw IP or user agent — hash with a daily-rotating salt if uniques are needed. 8. Add monitoring for table size, query latency and collector errors. 9. Out of scope unless I ask: multi-tenant hosting for other people's sites, real-time dashboards, funnels.
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
$9 a month against running a database, doing upgrades and testing restores is a fair trade for many people. Self-hosting the real thing is the strongest option if you already run infrastructure — writing your own is reasonable too, provided retention is decided on day one.
Because the schema is documented and open source, exporting to the hosted product or another instance is straightforward — keep aggregates as plain tables and test the export. The long series is the only thing of value here, so it is the thing to protect.
The product's own open-source analytics platform.
Questions
Why host the collector separately from the site?
Because otherwise your analytics are down exactly when something interesting is happening. An outage on shared infrastructure takes the measurement with it, so the incident you most want data about is the one with a gap in the chart. Separating them costs very little and makes the data trustworthy during the moments that matter.
Is aggregating on write worth the complexity?
It is barely complexity — an upsert into a daily counts table alongside or instead of the raw insert. What it buys is a dataset that stays small and fast indefinitely, and it removes the migration-on-a-huge-table problem before it exists. Deciding it on day one is trivial; retrofitting it a year later is not.
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.
Completion is an API call. Completion that is right often enough to trust is a product.
Counting page views without cookies is a POST and a table. This one you should own.
No cookies, no personal data, no banner. Also no reason to pay $20 a month.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice