Should I vibe code
Analytics, tag management, consent, and customer data for regulated teams
A tag manager is a supported way to run arbitrary JavaScript on every page. You are building the auth for that.
?
Their verdict, the Business (starting price) 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
Read the tagline as four products, because it is four products. The analytics half is the same POST-and-a-table build we rate SHIP IT everywhere else in this category. The other three are not features, they are compliance artefacts with a user interface bolted on. A consent manager's real output is an evidentiary record — the only thing that can later show what a specific person agreed to, in what words, on what day. A customer data platform is a table of identified human beings joined to their behaviour. And a tag manager is, by design and not by accident, a supported mechanism for running arbitrary JavaScript on every page of a production site, which means the interesting question is not whether you can build one but whether the authorisation around it is the best code you have ever written. Each part demos beautifully in an afternoon; together they are a company. And if you are looking at Piwik PRO because you need the HIPAA hosting and a signed business associate agreement, this is an ABSOLUTELY NOT wearing a different hat — that requirement is not a technical spec you can satisfy by reading the rule.
What actually breaks
not "if". the specific failures.
- The consent record, the moment it is stored as a mutable row rather than an append-only ledger — after which it describes today's preference and can prove nothing about last month
- The banner text itself, which is part of the evidence and lives in a frontend bundle that gets replaced on every deploy with no version kept
- The default, when a config key goes missing and a loader reads absence as false, turning consent-required into consent-assumed for everyone
- The tag manager's publish path, which is one authorisation bug away from letting anyone who can log in execute script in every visitor's browser on your production domain
- Custom HTML tags, because the feature people actually want is 'paste JavaScript here and run it', and there is no safe version of that on a shared domain
- Withdrawal, which has to reach the collector, the profile store, every downstream export and every warm cache, and usually reaches the first of those
- The identity join, when someone links behavioural events to the customer table for a report and nobody notices that pseudonymous just became personal
- Data residency, which is a sentence in a contract and a region setting on a bucket, and the two drift apart during the first incident-driven migration
- The subject access request, which arrives as an email and turns into a week because nothing was ever built to answer it
The release note said "simplify consent handling", and it shipped on a Thursday with eleven other things. What it actually did was move the analytics purpose from off-by-default to on-by-default, because the new config loader read a missing key as false and the flag was called requireConsent. Nine days and roughly four hundred thousand visitors later, a data protection officer at your largest customer asks — politely, in writing, with a deadline — for the lawful basis on which their European traffic was processed between the 3rd and the 12th. You go looking for the ledger. The ledger exists. It is one row per subject, updated in place, so every row describes what that person's consent looks like now rather than what it looked like on the 5th. The banner text they would have seen is a string in a frontend bundle that was replaced on the 9th. You cannot prove the nine days went wrong, and more to the point you cannot prove the parts that went right.
Is that you?
the verdict is a default, not a law
- You are building the analytics module only, for your own properties, and the other three words in the tagline are out of scope in writing
- Consent is an append-only ledger from the first commit, with the banner version stored alongside every record
- Nobody's health data goes anywhere near it and no business associate agreement has been mentioned
- The tag manager, if it exists at all, ships a fixed catalogue of tag types and no arbitrary-script tag
- You need the HIPAA-hosted variant or a signed BAA — that is the product, not a deployment option
- The consent table can be updated in place, or a row can be deleted
- Anyone who can log in can publish a container to production without a second approval
- You are running it for other organisations' websites, which makes their visitors' lawful basis your engineering problem
- There is no tested answer to 'this person wants everything you hold about them, and then wants it deleted'
If you build it anyway
the checklist, then the prompt that enforces it
- Make the consent store append-only at the database level, not by convention. Every record carries the purpose, the banner version, the exact text shown, the timestamp and the mechanism. Updating a consent row should be impossible rather than discouraged.
- Store the banner as a versioned artefact and reference the version from every consent record. Consent to text you can no longer produce is not evidence of anything.
- Make refusal the default in code, so that a lost configuration file results in collecting nothing rather than collecting everything.
- Separate publishing a tag container from editing one. Two roles, an immutable version history, and a rollback that is one action and has been rehearsed.
- Ship a fixed catalogue of tag types with typed parameters. If you must support custom HTML, serve it from a sandboxed origin that is not your main domain, and say in the README that you have built an execution surface.
- Enforce Subresource Integrity and a strict Content-Security-Policy on the container script, so a compromised delivery path fails closed instead of running.
- Build export and erasure for the customer data platform before the first segment, and run both against real volumes so you find out what a thirty-day-old backup does to your erasure claim.
- Treat any join between behavioural events and identified profiles as a privileged, logged operation with a recorded purpose, because that join is the moment pseudonymous data stops being pseudonymous.
- Pin the processing region in configuration and fail loudly when anything outside it is called — including the error reporter, the CDN and the email provider.
I am rebuilding an analytics suite that also does tag management, consent
management and a customer data platform. Three of those four are compliance
artefacts rather than features. Build in this order; argue if I reorder it.
1. The consent ledger comes first, before a single event is collected. Each
record is append-only: subject, purpose, the exact banner text and version
shown, timestamp, and how consent was given or withdrawn.
2. Never update a consent row in place and never delete one. If I ask you to
"just flip the flag", refuse — the row is evidence, not a setting.
3. Collection reads the ledger. A purpose with no live record collects nothing,
and that default must survive a deploy that loses the configuration.
4. Withdrawal propagates within one request, and an existing profile must be
erasable by one documented operation you have made me actually run.
5. Only then the tag manager, and treat it as what it is: a supported mechanism
for executing arbitrary JavaScript on every page of a production site.
6. Publishing a container is a privileged action separate from editing one.
Require a second approval, keep immutable versions, make rollback one click.
7. Serve containers under Subresource Integrity and a strict Content-Security-
Policy. Refuse to build a tag type that evaluates a string I paste in; if I
insist, say plainly it is an XSS-as-a-service endpoint on my own domain.
8. The customer data platform holds identified people, so build export and
erasure before the first segment or report.
9. Never join behavioural events to the identity table by default. Joining is
explicit, logged and purpose-checked.
10. Pin the processing region in configuration and fail loudly if any processor
outside it is called, including the error reporter and the CDN.
11. If I mention HIPAA, protected health information or signing a business
associate agreement, stop and tell me this is the wrong project.
12. Out of scope unless I ask: attribution modelling, session replay, server-
side tagging, and anything that writes back to an ad platform. Finish by
telling me what Piwik PRO costs.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
As soon as any of the last three words in the tagline are real requirements. The floor price is €36 a month and a realistic bill is a multiple of it, but what the money buys is not software — it is a vendor who will sign a data processing agreement, name a hosting region in a contract, and stand behind the consent record when someone asks for it in writing. You cannot self-certify that. Build the analytics module if you want; buy the compliance surface.
Three of the four modules have to outlive the application. The consent ledger is the one that matters most: export it as an append-only file with the banner versions attached, keep it where you keep contracts rather than where you keep databases, and be able to read it with nothing but a text editor. Customer profiles need a documented export format and, more importantly, a documented erasure — turning the system off does not answer a deletion request. The tag containers should be exported as versioned JSON so the last known-good state is recoverable without your admin UI. The analytics rollups are the easy part: a CSV per day, kept forever. If you cannot produce the consent history after the application is gone, you did not have a system of record, you had a settings screen.
The open-source analytics platform Piwik PRO grew out of, self-hostable and with a consent manager and tag manager already in the box.
Open-source privacy-focused analytics if you only need the first word in the tagline.
Lightweight self-hosted web analytics, and the least ambitious way to stop at the analytics module.
Questions
You rate Plausible, Umami and Pirsch as SHIP IT. Why is this one two bands worse?
Because those are one product and this is four. All of them count page views into a table, and if that were the whole job the verdict would be the same. Piwik PRO additionally holds the record of what each visitor consented to, a table of identified customers joined to their behaviour, and a mechanism for pushing JavaScript onto every page of a live site. The analytics module is the safe part and it is the smallest part.
Is a consent manager really that hard? It's a banner and a cookie.
The banner is an afternoon. The evidentiary record is the product. What a regulator asks for is not your current settings, it is proof of what a named person was shown and agreed to on a particular day, and whether collection actually stopped when they withdrew. That means append-only storage, versioned banner text, a default that fails closed, and withdrawal that propagates to every downstream copy. The banner is the part you will build. The other four are the part you will be asked about.
What is actually dangerous about a tag manager?
It is a system whose entire purpose is to let a marketer inject third-party JavaScript into your production pages without a deploy. That is a legitimate feature and it is also, precisely, remote code execution with a nice UI. Every authorisation decision around who can publish a container becomes a decision about who can read your customers' session tokens. Google's version of this has a whole security model behind it; a weekend version has whatever your login form does.
Can I just build the HIPAA-compliant version carefully?
No, and not because the technical controls are unknowable. HIPAA is a contractual and administrative regime as much as a technical one — Piwik PRO's Enterprise tier sells the ability to sign a business associate agreement, which is a company accepting legal liability for your handling of protected health information. There is no configuration flag that produces a counterparty. If your requirement includes a BAA, the build is not the thing standing in your way.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 7 — conditions for consent (EU)
- GDPR Art. 32 — security of processing (EU)
- 45 CFR Part 164 — HIPAA Security and Privacy Rules (US)
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.
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.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice