Should I vibe code
Realtime analytics, customer profiles, automation, and messaging
Aggregates are numbers. A live visitor feed is a list of people, and you just put it on the office TV.
?
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
Two thirds of GoSquared is the POST-and-a-table we tell people to build in the other analytics entries, and that part is fine. The third that is not is the live view — the reason anyone opened GoSquared in the first place — and it is a different program: a socket per open dashboard, per-visitor state held in memory, and a screen showing individual people moving through your site right now. That last bit is the trap. Aggregates are numbers. A live feed is a list of humans with a city, a referrer and a page path each, sitting on a screen your whole office leaves open all day.
What actually breaks
not "if". the specific failures.
- The live view under real traffic: one WebSocket per open dashboard, per-visitor state in memory, and a deploy that resets 'now' to zero
- The line between analytics and personal data, the moment the feed shows one visitor's city, referrer and current page
- Bots, which inflate 'currently online' far more than they inflate any other number you display
- An open collection endpoint that accepts whatever anyone posts, so your metrics are only as honest as the internet feels today
- Unlimited retention, which is a promise about your storage bill as much as about your schema
- The identify() call somebody adds in month three, which turns an anonymous counter into a customer database nobody wrote a privacy policy for
Is that you?
the verdict is a default, not a law
- You only need yesterday's numbers, in which case skip the sockets entirely and build the rollup
- The live view is capped, sampled and internal, and nobody has put it on a public dashboard
- Daily rollups are backed up somewhere you have actually restored from
- No cookie, no raw IP, and the privacy page describes what the code does rather than what you meant
- The live feed shows per-visitor detail to anyone who can reach the dashboard URL
- You plan to attach identities to sessions without deciding what that makes the dataset
- There is no bot filtering, so 'currently online' is a number you cannot defend in a meeting
- The collection endpoint takes arbitrary event payloads with no origin check or rate limit
If you build it anyway
the checklist, then the prompt that enforces it
- Build the daily rollup first and the live view last. The rollup is the asset you cannot recreate; the live view is the thing you will watch twice and then ignore.
- Treat the real-time feed as personal data, because a single visitor's city, referrer and path is exactly that. Gate it behind auth, coarsen the geography, and expire the per-session state in minutes.
- Cap the live pipeline: sample above a threshold, limit concurrent dashboard sockets, and make sure a traffic spike degrades the live view rather than the collection endpoint.
- Filter bots before storage and record which filter version produced each rollup, so a change in method is not mistaken for a change in traffic.
- Rate-limit and origin-check the collection endpoint. An open /collect is a free write endpoint on the internet and it will be found.
- Strip query strings from stored paths or allowlist parameters — URLs carry reset tokens, email addresses and search terms into your analytics database.
- If anyone ever calls identify(), stop and re-read the privacy page. That single call moves the whole system from counting to profiling.
I am building real-time web analytics: a collection endpoint, aggregate reports
and a live visitor view. Apply these and push back if I ask you to break them.
1. Build storage and the daily rollup first, the reporting UI second, and the
live view last. Tell me plainly that the historical series is the only part
that cannot be recreated after it is lost.
2. Roll up on write into daily aggregates kept separately from raw events.
Retention applies to raw events; the rollups are permanent and backed up.
3. Treat the live feed as personal data. It is gated behind authentication, it
shows country or region rather than a precise city, session state expires in
minutes, and nothing about it is publicly linkable.
4. Set explicit limits on the real-time path: maximum concurrent dashboard
connections, sampling above a events-per-second threshold, and back-pressure
that degrades the live view before it degrades collection.
5. Never let a live-view failure lose an event. Collection writes durably first
and publishes to subscribers second.
6. Rate-limit the collection endpoint per IP and per site key, check the origin,
and cap payload size. Assume the endpoint will be scripted by strangers.
7. Set no cookies. For daily uniques, hash IP and user agent with a salt that
rotates at midnight and store only the truncated hash, never the inputs.
8. Strip query strings from stored paths unless I allowlist a parameter.
9. Filter bots before storage and stamp each rollup with the filter version.
10. If I ask you to add identify() or per-person profiles, stop and tell me that
this converts an anonymous counter into a customer database, and what that
changes about consent, retention and the privacy page.
11. Out of scope unless I ask: session replay, funnels, cross-site tracking,
and any identifier that outlives the day it was created.
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
£24 a month for the Standard tier — and note the page swaps the symbol to a dollar sign outside the UK and EU without changing the number — buys the real-time pipeline, the storage promise and unlimited retention. If you only ever look at yesterday, don't buy it: build the rollup, it is a POST and a table. If you genuinely watch the live view, price out socket fan-out and per-session state honestly first, because that is the whole bill.
$24/mo is cheaper than your weekend.
Daily rollups — date, path, referrer group, country, count — in a plain table you can export as CSV. That is the entire dataset worth keeping and it is small enough to hold forever. The live view has no exit plan because it has nothing to export: 'now' is not data, it is a feeling, and it is gone a second later either way.
Open-source privacy-focused analytics with the aggregation and rollup design already worked out.
Lightweight self-hosted analytics that is the most practical starting point for a DIY build.
Questions
You rate Plausible and Fathom SHIP IT. Why is this one DEMO ONLY?
Because the real-time half is a different program. A privacy analytics tool is a write endpoint and a daily aggregate — genuinely a weekend. A live visitor view is stateful, connection-oriented and per-person: sockets fanned out to every open dashboard, session state that has to survive a deploy, and a screen full of individuals rather than totals. You will reach a great demo of it in an afternoon and discover the operational cost at your first traffic spike.
The tagline mentions customer profiles and messaging. Is that still GoSquared?
Not on the pricing page. What GoSquared sells today is website analytics priced by pageviews — Starter, Standard, Pro and Scale — and their email product now lives under a separate brand. So the thing you would actually be rebuilding is smaller than the imported description suggests, which is good news for the estimate.
Is a live visitor feed really personal data?
A row that says one person, in this city, arrived from this search and is reading this page is about an identifiable-enough individual for the question to be worth answering before you build it, not after. It also tends to be the screen nobody bothers to put behind authentication, because it looks like a toy.
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.
First-party analytics you host yourself is the version that actually respects the visitor.
A tag manager is a supported way to run arbitrary JavaScript on every page. You are building the auth for that.
Counting page views without cookies is a POST and a table. This one you should own.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice