Vibecode Cookiebot
track this build5 phases, 10 steps, beginner friendly0%KINDA · weekend project
The banner, the consent storage and the script gating are a sitting with an open-source library like Klaro. What you cannot vibecode is the legal certainty: the monthly cookie scan that finds the tracker your marketing team added, and the audit trail that a regulator will accept.
the project pack5 files · written for this build, step by step
You are building a lean indie version of Cookiebot. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Cookiebot · indie build A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Estimated effort: **one sitting**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Banner | Vanilla JS under 8 KB, self-hosted | no third-party script to consent to | | Log | A tiny optional endpoint | to show what was agreed, without IPs | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **A terminal and a code editor** · free - Why: Every step below is a command you type or a file you edit. - Get it: VS Code (code.visualstudio.com), Cursor or Zed. Open a folder for the project and use the editor's built-in terminal. - Verify: You can open a folder and run a command in its terminal - [ ] **Git** · free - Why: History for your code, and the way most hosts deploy. - Get it: Install from git-scm.com or with your package manager, then run git init in the project folder once it exists. - Verify: git --version prints a version - [ ] **A list of every third-party script on your site** · free - Why: Phase 1 gates them by category. You cannot gate what you have not listed. - Get it: Open DevTools > Network on a cold load and write down every third-party host and what it does. - [ ] **Do you need a banner at all?** · free - Why: Cookieless analytics and no ad or social scripts means no banner is the correct build. - Get it: Answer honestly from the inventory. - [ ] **Google Tag Manager or gtag (optional)** (optional) · free - Why: Phase 4 sends Consent Mode v2 signals if you use Google tags. - Get it: Your existing container id. ## Quick start Follow Phase 1 in `BUILD_PLAN.md`; it creates the project. Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. - automatic scanning that finds cookies you did not know about - the consent log a regulator will accept - legal text kept current across jurisdictions - Google-certified Consent Mode integration If one of those is essential to you, that is the reason to keep paying for Cookiebot, and the README should say so rather than pretend. ===== BRIEF.md ===== # Build brief · Cookiebot The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me a cookie consent manager like Cookiebot for my own site. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. First question, before any code: do you load anything non-essential at all? If your analytics is cookieless and you have no ad or social scripts, the correct build is no banner, and you should stop here. ### Stack (fixed, do not substitute) - Vanilla JS under 8 kB, inlined or self-hosted. No framework. A tiny optional endpoint for the consent log. ### Phase 1 · Inventory Build: a scripts.json listing every third-party script on the site with its category (necessary, analytics, marketing) and the cookies it sets. Change every non-necessary script tag to type="text/plain" with a data-category attribute so nothing runs before consent. Done when: with the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load. Do not build yet: the banner UI. ### Phase 2 · The banner Build: an accessible banner with Accept all, Reject all, and Preferences with per-category toggles · equal visual weight for accept and reject, no pre-ticked boxes. Store the choice with a version and a timestamp in a first-party cookie and localStorage. Done when: Reject leaves every gated script inert, Accept activates them without a reload, and the choice persists across visits. ### Phase 3 · Preferences and withdrawal Build: a footer link that reopens preferences, and a consent version bump that re-asks when scripts.json changes. Done when: changing scripts.json re-prompts and withdrawing consent stops the scripts on the next load and clears their cookies. ### Phase 4 · Consent Mode and the log Build: Google Consent Mode v2 signals when you use Google tags, and an optional endpoint recording consent id, timestamp, version and choices (no IP) so you can show what was agreed. Done when: the tag manager receives the consent state and the log shows one row per decision. ### Phase 5 · Verify Build: a test page and a checklist: cold load, reject, accept, withdraw, each verified by the network tab. Document it. Done when: someone else runs the checklist and every step passes. ### Out of scope (and why) - Scanning for cookies you do not know about, jurisdiction-specific legal text, an audit trail a regulator has seen before. That is the subscription, and for a business site it may be the right call. ### README must contain - The scripts.json inventory as the source of truth. - The plain sentence that this is engineering, not legal advice. ===== AGENTS.md ===== # Agent instructions · Cookiebot indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: Vanilla JS under 8 KB, self-hosted, A tiny optional endpoint. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan · Cookiebot A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Inventory scripts.json and every non-essential tag inert before consent. ### Steps 1. Write scripts.json with category and cookies per script Files: `scripts.json` 2. Change non-necessary script tags to type=text/plain with data-category ### Done when - [ ] With the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load ## Phase 2 · The banner Accept all, Reject all, Preferences with equal weight; stored with a version and timestamp. ### Steps 1. Build the accessible banner with no pre-ticked boxes 2. Store the choice in a first-party cookie and localStorage; activate gated scripts on accept without a reload ### Done when - [ ] Reject leaves every gated script inert - [ ] Accept activates them without a reload - [ ] The choice persists across visits ## Phase 3 · Preferences and withdrawal Reopen, re-ask on change, stop and clear on withdrawal. ### Steps 1. A footer link reopening preferences; a consent version bump when scripts.json changes 2. On withdrawal, stop scripts on next load and clear their cookies ### Done when - [ ] Changing scripts.json re-prompts - [ ] Withdrawing stops the scripts and clears their cookies ## Phase 4 · Consent Mode and the log Google signals and an optional record without IPs. ### Steps 1. Send Consent Mode v2 defaults and updates when Google tags exist 2. POST consent id, timestamp, version and choices to CONSENT_LOG_ENDPOINT when set ### Done when - [ ] The tag manager receives the consent state - [ ] The log shows one row per decision with no IP ## Phase 5 · Verify A checklist someone else can run. ### Steps 1. A test page and checklist: cold load, reject, accept, withdraw 2. README stating scripts.json is the source of truth and that this is engineering, not legal advice Files: `README.md` ### Done when - [ ] Someone else runs the checklist and every step passes ## Not in this build - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. ## After v1, if you want it - A per-region default (no banner where none is required) ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional. Optional endpoint for consent records. Empty disables logging. CONSENT_LOG_ENDPOINT=https://forms.yourdomain.com/consent
You are building a lean indie version of Cookiebot. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Cookiebot · indie build A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Estimated effort: **one sitting**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Banner | Vanilla JS under 8 KB, self-hosted | no third-party script to consent to | | Log | A tiny optional endpoint | to show what was agreed, without IPs | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **A terminal and a code editor** · free - Why: Every step below is a command you type or a file you edit. - Get it: VS Code (code.visualstudio.com), Cursor or Zed. Open a folder for the project and use the editor's built-in terminal. - Verify: You can open a folder and run a command in its terminal - [ ] **Git** · free - Why: History for your code, and the way most hosts deploy. - Get it: Install from git-scm.com or with your package manager, then run git init in the project folder once it exists. - Verify: git --version prints a version - [ ] **A list of every third-party script on your site** · free - Why: Phase 1 gates them by category. You cannot gate what you have not listed. - Get it: Open DevTools > Network on a cold load and write down every third-party host and what it does. - [ ] **Do you need a banner at all?** · free - Why: Cookieless analytics and no ad or social scripts means no banner is the correct build. - Get it: Answer honestly from the inventory. - [ ] **Google Tag Manager or gtag (optional)** (optional) · free - Why: Phase 4 sends Consent Mode v2 signals if you use Google tags. - Get it: Your existing container id. ## Quick start Follow Phase 1 in `BUILD_PLAN.md`; it creates the project. Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. - automatic scanning that finds cookies you did not know about - the consent log a regulator will accept - legal text kept current across jurisdictions - Google-certified Consent Mode integration If one of those is essential to you, that is the reason to keep paying for Cookiebot, and the README should say so rather than pretend. ===== BRIEF.md ===== # Build brief · Cookiebot The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me a cookie consent manager like Cookiebot for my own site. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. First question, before any code: do you load anything non-essential at all? If your analytics is cookieless and you have no ad or social scripts, the correct build is no banner, and you should stop here. ### Stack (fixed, do not substitute) - Vanilla JS under 8 kB, inlined or self-hosted. No framework. A tiny optional endpoint for the consent log. ### Phase 1 · Inventory Build: a scripts.json listing every third-party script on the site with its category (necessary, analytics, marketing) and the cookies it sets. Change every non-necessary script tag to type="text/plain" with a data-category attribute so nothing runs before consent. Done when: with the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load. Do not build yet: the banner UI. ### Phase 2 · The banner Build: an accessible banner with Accept all, Reject all, and Preferences with per-category toggles · equal visual weight for accept and reject, no pre-ticked boxes. Store the choice with a version and a timestamp in a first-party cookie and localStorage. Done when: Reject leaves every gated script inert, Accept activates them without a reload, and the choice persists across visits. ### Phase 3 · Preferences and withdrawal Build: a footer link that reopens preferences, and a consent version bump that re-asks when scripts.json changes. Done when: changing scripts.json re-prompts and withdrawing consent stops the scripts on the next load and clears their cookies. ### Phase 4 · Consent Mode and the log Build: Google Consent Mode v2 signals when you use Google tags, and an optional endpoint recording consent id, timestamp, version and choices (no IP) so you can show what was agreed. Done when: the tag manager receives the consent state and the log shows one row per decision. ### Phase 5 · Verify Build: a test page and a checklist: cold load, reject, accept, withdraw, each verified by the network tab. Document it. Done when: someone else runs the checklist and every step passes. ### Out of scope (and why) - Scanning for cookies you do not know about, jurisdiction-specific legal text, an audit trail a regulator has seen before. That is the subscription, and for a business site it may be the right call. ### README must contain - The scripts.json inventory as the source of truth. - The plain sentence that this is engineering, not legal advice. ===== AGENTS.md ===== # Agent instructions · Cookiebot indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: Vanilla JS under 8 KB, self-hosted, A tiny optional endpoint. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan · Cookiebot A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Inventory scripts.json and every non-essential tag inert before consent. ### Steps 1. Write scripts.json with category and cookies per script Files: `scripts.json` 2. Change non-necessary script tags to type=text/plain with data-category ### Done when - [ ] With the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load ## Phase 2 · The banner Accept all, Reject all, Preferences with equal weight; stored with a version and timestamp. ### Steps 1. Build the accessible banner with no pre-ticked boxes 2. Store the choice in a first-party cookie and localStorage; activate gated scripts on accept without a reload ### Done when - [ ] Reject leaves every gated script inert - [ ] Accept activates them without a reload - [ ] The choice persists across visits ## Phase 3 · Preferences and withdrawal Reopen, re-ask on change, stop and clear on withdrawal. ### Steps 1. A footer link reopening preferences; a consent version bump when scripts.json changes 2. On withdrawal, stop scripts on next load and clear their cookies ### Done when - [ ] Changing scripts.json re-prompts - [ ] Withdrawing stops the scripts and clears their cookies ## Phase 4 · Consent Mode and the log Google signals and an optional record without IPs. ### Steps 1. Send Consent Mode v2 defaults and updates when Google tags exist 2. POST consent id, timestamp, version and choices to CONSENT_LOG_ENDPOINT when set ### Done when - [ ] The tag manager receives the consent state - [ ] The log shows one row per decision with no IP ## Phase 5 · Verify A checklist someone else can run. ### Steps 1. A test page and checklist: cold load, reject, accept, withdraw 2. README stating scripts.json is the source of truth and that this is engineering, not legal advice Files: `README.md` ### Done when - [ ] Someone else runs the checklist and every step passes ## Not in this build - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. ## After v1, if you want it - A per-region default (no banner where none is required) ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional. Optional endpoint for consent records. Empty disables logging. CONSENT_LOG_ENDPOINT=https://forms.yourdomain.com/consent
You are building a production product version of Cookiebot. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Cookiebot · product brief ## Problem The banner, the consent storage and the script gating are a sitting with an open-source library like Klaro. What you cannot vibecode is the legal certainty: the monthly cookie scan that finds the tracker your marketing team added, and the audit trail that a regulator will accept. ## Product outcome Consent you can explain line by line, with the scanner replaced by a CI check on your own build. ## Target user A builder who needs a maintainable product foundation, not a one-off demo. ## Required capabilities - a list of every script your site loads and its category ## Explicit non-goals for v1 - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. - automatic scanning that finds cookies you did not know about - the consent log a regulator will accept - legal text kept current across jurisdictions - Google-certified Consent Mode integration ## Success criteria - Cold-load network tab clean - Checklist passed by someone else - CI guard in place ===== BRIEF.md ===== # Build brief · Cookiebot The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me a cookie consent manager like Cookiebot for my own site. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. First question, before any code: do you load anything non-essential at all? If your analytics is cookieless and you have no ad or social scripts, the correct build is no banner, and you should stop here. ### Stack (fixed, do not substitute) - Vanilla JS under 8 kB, inlined or self-hosted. No framework. A tiny optional endpoint for the consent log. ### Phase 1 · Inventory Build: a scripts.json listing every third-party script on the site with its category (necessary, analytics, marketing) and the cookies it sets. Change every non-necessary script tag to type="text/plain" with a data-category attribute so nothing runs before consent. Done when: with the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load. Do not build yet: the banner UI. ### Phase 2 · The banner Build: an accessible banner with Accept all, Reject all, and Preferences with per-category toggles · equal visual weight for accept and reject, no pre-ticked boxes. Store the choice with a version and a timestamp in a first-party cookie and localStorage. Done when: Reject leaves every gated script inert, Accept activates them without a reload, and the choice persists across visits. ### Phase 3 · Preferences and withdrawal Build: a footer link that reopens preferences, and a consent version bump that re-asks when scripts.json changes. Done when: changing scripts.json re-prompts and withdrawing consent stops the scripts on the next load and clears their cookies. ### Phase 4 · Consent Mode and the log Build: Google Consent Mode v2 signals when you use Google tags, and an optional endpoint recording consent id, timestamp, version and choices (no IP) so you can show what was agreed. Done when: the tag manager receives the consent state and the log shows one row per decision. ### Phase 5 · Verify Build: a test page and a checklist: cold load, reject, accept, withdraw, each verified by the network tab. Document it. Done when: someone else runs the checklist and every step passes. ### Out of scope (and why) - Scanning for cookies you do not know about, jurisdiction-specific legal text, an audit trail a regulator has seen before. That is the subscription, and for a business site it may be the right call. ### README must contain - The scripts.json inventory as the source of truth. - The plain sentence that this is engineering, not legal advice. ===== ARCHITECTURE.md ===== # Architecture · Cookiebot ## Stack | Part | Choice | Why | | --- | --- | --- | | Banner | Vanilla JS under 8 KB, self-hosted | no third-party script to consent to | | Log | A tiny optional endpoint | to show what was agreed, without IPs | ## Modules Each module has one owner concern and a documented way to replace it. | Module | Owns | How to replace it | | --- | --- | --- | | Inventory | scripts.json | The source of truth | | Gate | type=text/plain activation | Tag-manager triggers | | Banner | UI and storage | Any UI over the same stored choice | | Log | the optional endpoint | Drop it | ## Configuration Every runtime setting is an environment variable documented in `.env.example`, validated at startup, with a safe local default wherever one exists. - `CONSENT_LOG_ENDPOINT` · optional · Optional endpoint for consent records. Empty disables logging. ## Production baseline - Security: least privilege, input validation at every boundary, secret redaction in logs, rate limits on abuse-prone paths, no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore procedures that have been exercised. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, timeouts. - Observability: structured logs with request or operation ids, an error-tracking hook, and health and readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, one end-to-end test of the critical path. ## Decision records For each dependency in the stack table, keep a short note: why it was chosen, its failure mode, and how it is replaced. Do not add infrastructure until a requirement in `PRODUCT.md` justifies it. ===== AGENTS.md ===== # Agent instructions · Cookiebot product build - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. The stack is fixed: Vanilla JS under 8 KB, self-hosted, A tiny optional endpoint. - Implement milestone by milestone from `MILESTONES.md`; keep each change reviewable and leave the application runnable at every commit. - Treat authentication, payments, encryption, imports, webhooks and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a check pass. - Put every external service behind an interface with a deterministic fake for tests. - Add migrations and rollback or recovery notes for every persistent data change. - Log useful operational context without credentials, tokens, passwords or personal data. - Update documentation and run every check before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones · Cookiebot Estimated effort: **one sitting** for the indie phases; the production-only milestones add the trust and operability layer. ## M1 · Inventory scripts.json and every non-essential tag inert before consent. ### Steps 1. Write scripts.json with category and cookies per script Files: `scripts.json` 2. Change non-necessary script tags to type=text/plain with data-category ### Done when - [ ] With the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load ## M2 · The banner Accept all, Reject all, Preferences with equal weight; stored with a version and timestamp. ### Steps 1. Build the accessible banner with no pre-ticked boxes 2. Store the choice in a first-party cookie and localStorage; activate gated scripts on accept without a reload ### Done when - [ ] Reject leaves every gated script inert - [ ] Accept activates them without a reload - [ ] The choice persists across visits ## M3 · Preferences and withdrawal Reopen, re-ask on change, stop and clear on withdrawal. ### Steps 1. A footer link reopening preferences; a consent version bump when scripts.json changes 2. On withdrawal, stop scripts on next load and clear their cookies ### Done when - [ ] Changing scripts.json re-prompts - [ ] Withdrawing stops the scripts and clears their cookies ## M4 · Consent Mode and the log Google signals and an optional record without IPs. ### Steps 1. Send Consent Mode v2 defaults and updates when Google tags exist 2. POST consent id, timestamp, version and choices to CONSENT_LOG_ENDPOINT when set ### Done when - [ ] The tag manager receives the consent state - [ ] The log shows one row per decision with no IP ## M5 · Verify A checklist someone else can run. ### Steps 1. A test page and checklist: cold load, reject, accept, withdraw 2. README stating scripts.json is the source of truth and that this is engineering, not legal advice Files: `README.md` ### Done when - [ ] Someone else runs the checklist and every step passes ## M6 · Keep it honest (production only) Catch the tag someone adds next Tuesday. ### Steps 1. A CI check that fails when a third-party host appears in the built site that is not in scripts.json 2. A monthly review reminder ### Done when - [ ] Adding an unlisted script fails CI ===== OPERATIONS.md ===== # Operations · Cookiebot ## Backup The repo; the log if kept. ## Restore Redeploy. Do a restore drill before the first real user, and write the date here when it passes. ## Monitoring The CI check. ## Incident checklist An unlisted tracker found: remove it, bump the consent version. 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified backup when needed. 5. Document the root cause, the remediation and the regression test. ## Release gate - [ ] Cold-load network tab clean - [ ] Checklist passed by someone else - [ ] CI guard in place ## Launch constraint Do not market omitted Cookiebot capabilities as implemented. The non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered. ===== .env.example ===== # Copy to .env and fill in. Never commit .env; this file documents it. # Optional. Optional endpoint for consent records. Empty disables logging. CONSENT_LOG_ENDPOINT=https://forms.yourdomain.com/consent
README.md
# Cookiebot · indie build A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Estimated effort: **one sitting**. Work `BUILD_PLAN.md` top to bottom · every phase ends in a check that has to pass before the next one starts. ## Stack | Part | Choice | Why | | --- | --- | --- | | Banner | Vanilla JS under 8 KB, self-hosted | no third-party script to consent to | | Log | A tiny optional endpoint | to show what was agreed, without IPs | ## Before you start Have every one of these ready. The plan assumes them from step one. - [ ] **A terminal and a code editor** · free - Why: Every step below is a command you type or a file you edit. - Get it: VS Code (code.visualstudio.com), Cursor or Zed. Open a folder for the project and use the editor's built-in terminal. - Verify: You can open a folder and run a command in its terminal - [ ] **Git** · free - Why: History for your code, and the way most hosts deploy. - Get it: Install from git-scm.com or with your package manager, then run git init in the project folder once it exists. - Verify: git --version prints a version - [ ] **A list of every third-party script on your site** · free - Why: Phase 1 gates them by category. You cannot gate what you have not listed. - Get it: Open DevTools > Network on a cold load and write down every third-party host and what it does. - [ ] **Do you need a banner at all?** · free - Why: Cookieless analytics and no ad or social scripts means no banner is the correct build. - Get it: Answer honestly from the inventory. - [ ] **Google Tag Manager or gtag (optional)** (optional) · free - Why: Phase 4 sends Consent Mode v2 signals if you use Google tags. - Get it: Your existing container id. ## Quick start Follow Phase 1 in `BUILD_PLAN.md`; it creates the project. Then copy `.env.example` to `.env` and fill in the values it documents. ## Honest limits This build deliberately does not replace: - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. - automatic scanning that finds cookies you did not know about - the consent log a regulator will accept - legal text kept current across jurisdictions - Google-certified Consent Mode integration If one of those is essential to you, that is the reason to keep paying for Cookiebot, and the README should say so rather than pretend.
BRIEF.md
# Build brief · Cookiebot The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me a cookie consent manager like Cookiebot for my own site. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. First question, before any code: do you load anything non-essential at all? If your analytics is cookieless and you have no ad or social scripts, the correct build is no banner, and you should stop here. ### Stack (fixed, do not substitute) - Vanilla JS under 8 kB, inlined or self-hosted. No framework. A tiny optional endpoint for the consent log. ### Phase 1 · Inventory Build: a scripts.json listing every third-party script on the site with its category (necessary, analytics, marketing) and the cookies it sets. Change every non-necessary script tag to type="text/plain" with a data-category attribute so nothing runs before consent. Done when: with the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load. Do not build yet: the banner UI. ### Phase 2 · The banner Build: an accessible banner with Accept all, Reject all, and Preferences with per-category toggles · equal visual weight for accept and reject, no pre-ticked boxes. Store the choice with a version and a timestamp in a first-party cookie and localStorage. Done when: Reject leaves every gated script inert, Accept activates them without a reload, and the choice persists across visits. ### Phase 3 · Preferences and withdrawal Build: a footer link that reopens preferences, and a consent version bump that re-asks when scripts.json changes. Done when: changing scripts.json re-prompts and withdrawing consent stops the scripts on the next load and clears their cookies. ### Phase 4 · Consent Mode and the log Build: Google Consent Mode v2 signals when you use Google tags, and an optional endpoint recording consent id, timestamp, version and choices (no IP) so you can show what was agreed. Done when: the tag manager receives the consent state and the log shows one row per decision. ### Phase 5 · Verify Build: a test page and a checklist: cold load, reject, accept, withdraw, each verified by the network tab. Document it. Done when: someone else runs the checklist and every step passes. ### Out of scope (and why) - Scanning for cookies you do not know about, jurisdiction-specific legal text, an audit trail a regulator has seen before. That is the subscription, and for a business site it may be the right call. ### README must contain - The scripts.json inventory as the source of truth. - The plain sentence that this is engineering, not legal advice.
AGENTS.md
# Agent instructions · Cookiebot indie build - Read `README.md` and `BUILD_PLAN.md` before writing code. The stack is fixed: Vanilla JS under 8 KB, self-hosted, A tiny optional endpoint. Do not substitute. - Work one phase at a time, in order. Do not start a phase until every "Done when" item of the previous one passes. - Prefer the fewest moving parts that satisfy the step. No frameworks, services or dependencies the plan does not name. - Secrets live in `.env`, never in source or logs. Keep `.env.example` current when a variable is introduced. - Do not invent cryptography, security guarantees, APIs or compliance claims. - Add a focused test for every destructive, security-sensitive or data-loss path the plan names. - Run the project checks before declaring a phase complete, and record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan · Cookiebot A consent manager for your own site: an inventory of every script you load, gating so nothing non-essential runs before consent, an accessible banner with equal-weight accept and reject, withdrawal, Consent Mode signals and an optional consent log. First question: do you load anything non-essential at all? If not, the right build is no banner. Phases are in dependency order. Each ends in a "Done when" list; treat an unticked item as a blocker, not a note. ## Phase 1 · Inventory scripts.json and every non-essential tag inert before consent. ### Steps 1. Write scripts.json with category and cookies per script Files: `scripts.json` 2. Change non-necessary script tags to type=text/plain with data-category ### Done when - [ ] With the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load ## Phase 2 · The banner Accept all, Reject all, Preferences with equal weight; stored with a version and timestamp. ### Steps 1. Build the accessible banner with no pre-ticked boxes 2. Store the choice in a first-party cookie and localStorage; activate gated scripts on accept without a reload ### Done when - [ ] Reject leaves every gated script inert - [ ] Accept activates them without a reload - [ ] The choice persists across visits ## Phase 3 · Preferences and withdrawal Reopen, re-ask on change, stop and clear on withdrawal. ### Steps 1. A footer link reopening preferences; a consent version bump when scripts.json changes 2. On withdrawal, stop scripts on next load and clear their cookies ### Done when - [ ] Changing scripts.json re-prompts - [ ] Withdrawing stops the scripts and clears their cookies ## Phase 4 · Consent Mode and the log Google signals and an optional record without IPs. ### Steps 1. Send Consent Mode v2 defaults and updates when Google tags exist 2. POST consent id, timestamp, version and choices to CONSENT_LOG_ENDPOINT when set ### Done when - [ ] The tag manager receives the consent state - [ ] The log shows one row per decision with no IP ## Phase 5 · Verify A checklist someone else can run. ### Steps 1. A test page and checklist: cold load, reject, accept, withdraw 2. README stating scripts.json is the source of truth and that this is engineering, not legal advice Files: `README.md` ### Done when - [ ] Someone else runs the checklist and every step passes ## Not in this build - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. ## After v1, if you want it - A per-region default (no banner where none is required)
.env.example
# Copy to .env and fill in. Never commit .env; this file documents it. # Optional. Optional endpoint for consent records. Empty disables logging. CONSENT_LOG_ENDPOINT=https://forms.yourdomain.com/consent
PRODUCT.md
# Cookiebot · product brief ## Problem The banner, the consent storage and the script gating are a sitting with an open-source library like Klaro. What you cannot vibecode is the legal certainty: the monthly cookie scan that finds the tracker your marketing team added, and the audit trail that a regulator will accept. ## Product outcome Consent you can explain line by line, with the scanner replaced by a CI check on your own build. ## Target user A builder who needs a maintainable product foundation, not a one-off demo. ## Required capabilities - a list of every script your site loads and its category ## Explicit non-goals for v1 - Scanning for cookies you do not know about, jurisdiction-specific legal text, a regulator-familiar audit trail. - automatic scanning that finds cookies you did not know about - the consent log a regulator will accept - legal text kept current across jurisdictions - Google-certified Consent Mode integration ## Success criteria - Cold-load network tab clean - Checklist passed by someone else - CI guard in place
BRIEF.md
# Build brief · Cookiebot The one-shot brief this plan expands. `BUILD_PLAN.md` (or `MILESTONES.md`) is the same sequence broken into steps and checks; where the two disagree, the plan wins. Build me a cookie consent manager like Cookiebot for my own site. Build it in phases, in the order below. Do not write the whole thing in one pass. Finish a phase, run its "Done when" check, fix what fails, and only then start the next phase. First question, before any code: do you load anything non-essential at all? If your analytics is cookieless and you have no ad or social scripts, the correct build is no banner, and you should stop here. ### Stack (fixed, do not substitute) - Vanilla JS under 8 kB, inlined or self-hosted. No framework. A tiny optional endpoint for the consent log. ### Phase 1 · Inventory Build: a scripts.json listing every third-party script on the site with its category (necessary, analytics, marketing) and the cookies it sets. Change every non-necessary script tag to type="text/plain" with a data-category attribute so nothing runs before consent. Done when: with the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load. Do not build yet: the banner UI. ### Phase 2 · The banner Build: an accessible banner with Accept all, Reject all, and Preferences with per-category toggles · equal visual weight for accept and reject, no pre-ticked boxes. Store the choice with a version and a timestamp in a first-party cookie and localStorage. Done when: Reject leaves every gated script inert, Accept activates them without a reload, and the choice persists across visits. ### Phase 3 · Preferences and withdrawal Build: a footer link that reopens preferences, and a consent version bump that re-asks when scripts.json changes. Done when: changing scripts.json re-prompts and withdrawing consent stops the scripts on the next load and clears their cookies. ### Phase 4 · Consent Mode and the log Build: Google Consent Mode v2 signals when you use Google tags, and an optional endpoint recording consent id, timestamp, version and choices (no IP) so you can show what was agreed. Done when: the tag manager receives the consent state and the log shows one row per decision. ### Phase 5 · Verify Build: a test page and a checklist: cold load, reject, accept, withdraw, each verified by the network tab. Document it. Done when: someone else runs the checklist and every step passes. ### Out of scope (and why) - Scanning for cookies you do not know about, jurisdiction-specific legal text, an audit trail a regulator has seen before. That is the subscription, and for a business site it may be the right call. ### README must contain - The scripts.json inventory as the source of truth. - The plain sentence that this is engineering, not legal advice.
ARCHITECTURE.md
# Architecture · Cookiebot ## Stack | Part | Choice | Why | | --- | --- | --- | | Banner | Vanilla JS under 8 KB, self-hosted | no third-party script to consent to | | Log | A tiny optional endpoint | to show what was agreed, without IPs | ## Modules Each module has one owner concern and a documented way to replace it. | Module | Owns | How to replace it | | --- | --- | --- | | Inventory | scripts.json | The source of truth | | Gate | type=text/plain activation | Tag-manager triggers | | Banner | UI and storage | Any UI over the same stored choice | | Log | the optional endpoint | Drop it | ## Configuration Every runtime setting is an environment variable documented in `.env.example`, validated at startup, with a safe local default wherever one exists. - `CONSENT_LOG_ENDPOINT` · optional · Optional endpoint for consent records. Empty disables logging. ## Production baseline - Security: least privilege, input validation at every boundary, secret redaction in logs, rate limits on abuse-prone paths, no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore procedures that have been exercised. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, timeouts. - Observability: structured logs with request or operation ids, an error-tracking hook, and health and readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, one end-to-end test of the critical path. ## Decision records For each dependency in the stack table, keep a short note: why it was chosen, its failure mode, and how it is replaced. Do not add infrastructure until a requirement in `PRODUCT.md` justifies it.
AGENTS.md
# Agent instructions · Cookiebot product build - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. The stack is fixed: Vanilla JS under 8 KB, self-hosted, A tiny optional endpoint. - Implement milestone by milestone from `MILESTONES.md`; keep each change reviewable and leave the application runnable at every commit. - Treat authentication, payments, encryption, imports, webhooks and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a check pass. - Put every external service behind an interface with a deterministic fake for tests. - Add migrations and rollback or recovery notes for every persistent data change. - Log useful operational context without credentials, tokens, passwords or personal data. - Update documentation and run every check before completing a milestone.
MILESTONES.md
# Delivery milestones · Cookiebot Estimated effort: **one sitting** for the indie phases; the production-only milestones add the trust and operability layer. ## M1 · Inventory scripts.json and every non-essential tag inert before consent. ### Steps 1. Write scripts.json with category and cookies per script Files: `scripts.json` 2. Change non-necessary script tags to type=text/plain with data-category ### Done when - [ ] With the banner unanswered, the network tab shows zero requests to analytics or marketing hosts on a cold load ## M2 · The banner Accept all, Reject all, Preferences with equal weight; stored with a version and timestamp. ### Steps 1. Build the accessible banner with no pre-ticked boxes 2. Store the choice in a first-party cookie and localStorage; activate gated scripts on accept without a reload ### Done when - [ ] Reject leaves every gated script inert - [ ] Accept activates them without a reload - [ ] The choice persists across visits ## M3 · Preferences and withdrawal Reopen, re-ask on change, stop and clear on withdrawal. ### Steps 1. A footer link reopening preferences; a consent version bump when scripts.json changes 2. On withdrawal, stop scripts on next load and clear their cookies ### Done when - [ ] Changing scripts.json re-prompts - [ ] Withdrawing stops the scripts and clears their cookies ## M4 · Consent Mode and the log Google signals and an optional record without IPs. ### Steps 1. Send Consent Mode v2 defaults and updates when Google tags exist 2. POST consent id, timestamp, version and choices to CONSENT_LOG_ENDPOINT when set ### Done when - [ ] The tag manager receives the consent state - [ ] The log shows one row per decision with no IP ## M5 · Verify A checklist someone else can run. ### Steps 1. A test page and checklist: cold load, reject, accept, withdraw 2. README stating scripts.json is the source of truth and that this is engineering, not legal advice Files: `README.md` ### Done when - [ ] Someone else runs the checklist and every step passes ## M6 · Keep it honest (production only) Catch the tag someone adds next Tuesday. ### Steps 1. A CI check that fails when a third-party host appears in the built site that is not in scripts.json 2. A monthly review reminder ### Done when - [ ] Adding an unlisted script fails CI
OPERATIONS.md
# Operations · Cookiebot ## Backup The repo; the log if kept. ## Restore Redeploy. Do a restore drill before the first real user, and write the date here when it passes. ## Monitoring The CI check. ## Incident checklist An unlisted tracker found: remove it, bump the consent version. 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified backup when needed. 5. Document the root cause, the remediation and the regression test. ## Release gate - [ ] Cold-load network tab clean - [ ] Checklist passed by someone else - [ ] CI guard in place ## Launch constraint Do not market omitted Cookiebot capabilities as implemented. The non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
.env.example
# Copy to .env and fill in. Never commit .env; this file documents it. # Optional. Optional endpoint for consent records. Empty disables logging. CONSENT_LOG_ENDPOINT=https://forms.yourdomain.com/consent
$ choose a build depth, inspect the files, then open the complete pack in your agent
Because "we wrote our own banner" is not what you want to say to a data protection authority, and the scanner catches the tag someone added last Tuesday.
xautomatic scanning that finds cookies you did not know about
xthe consent log a regulator will accept
xlegal text kept current across jurisdictions
xGoogle-certified Consent Mode integration
share on X ↗"I just replaced Cookiebot ($8/mo) with one prompt"
Cookiebot pricing
premium lite$8/mo · monthly per domain · $96/yr
free tierThe free plan covers one domain up to 50 subpages with a compliant banner and Consent Mode.
verified 2026-09-04 · source ↗
Is Cookiebot free?
The free plan covers one domain up to 50 subpages with a compliant banner and Consent Mode. Paid is Premium Lite at $8/mo (checked 2026-09-04).
Vibecode Cookiebot
Kinda. The core of Cookiebot is buildable in a weekend with the prompt on this page, but there are real gaps: automatic scanning that finds cookies you did not know about, the consent log a regulator will accept. Read the honest list above before committing.
How much does Cookiebot cost?
Cookiebot costs about $8/month (Premium Lite, checked 2026-09-04), which is $96 per year.
What do I lose by replacing Cookiebot?
Honestly: automatic scanning that finds cookies you did not know about; the consent log a regulator will accept; legal text kept current across jurisdictions; Google-certified Consent Mode integration. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Cookiebot?
Yes: Klaro (open-source consent manager), vanilla-cookieconsent (lightweight consent banner). Using prior art is also vibecoding; the prompt is for when you want it exactly your way.