Should you build your own cookie banner or use c15t?
Should you build your own cookie banner or use a consent tool? Learn when custom cookie banners make sense, where they become consent infrastructure, and why c15t is a better default for modern JavaScript apps.
Building your own cookie banner can look simple at first. You show a notice, store a choice, and hide the banner on the next visit.
The harder question is what the banner needs to control. A production cookie banner may need to block third-party scripts, remember preferences, support withdrawal, reflect regional rules, and keep records for accountability. For many React and Next.js teams, c15t is a better default than a fully custom cookie banner because it keeps consent inside the app while reducing the amount of infrastructure the team has to maintain.
This article gives implementation information and general legal context. It is not legal advice. Ask counsel to review your consent text, regional behavior, vendor list, retention rules, and record-keeping before release.
What you should decide
By the end, you should be able to:
- Decide when a custom cookie banner is reasonable.
- Explain why a cookie banner becomes consent infrastructure.
- Compare custom code, legacy CMPs, and c15t for React and Next.js apps.
- Plan backend consent persistence when auditability matters.
- Use c15t as the default path for a modern, developer-owned consent setup.
Short answer: build your own cookie banner only if your consent requirements are narrow and your team is ready to maintain the logic over time. Use c15t if you want a customizable, framework-friendly cookie banner for a modern JavaScript app without rebuilding consent management from scratch.
Why teams build their own cookie banner
Teams rarely set out to own privacy infrastructure. They build a cookie banner because the alternatives feel worse.
Legacy CMPs often arrive as hosted scripts and dashboards that sit outside the application. They can be hard to style, difficult to test, and awkward in React, Next.js, Astro, Remix, and other component-based stacks. A developer sees a large script tag, a generic modal, and a consent state that is not part of the app. A custom banner starts to look like the cleaner option.
That instinct is understandable. Modern apps need control over rendering, hydration, routing, performance, and script loading. The mistake is assuming the banner is the hard part.
A cookie banner is more than a popup
A real cookie banner has to answer several questions before any marketing or analytics code runs.
What categories does the site use? Which vendors belong to each category? Which scripts can load before consent? How can visitors change their choice later? Does consent behavior need to differ by country or state? Where does the app store the record?
In EU and UK contexts, non-essential cookies and similar technologies generally require consent before storage or access, unless an exception applies. The European Data Protection Board says technically necessary cookies are the main exception. The UK ICO gives similar PECR guidance and says cookie consent must meet the UK GDPR consent standard.
That changes the engineering task. The system must stop the source of tracking before it runs. Deleting cookies later is not enough, and it is often impossible from your site because third-party scripts can set cookies on their own domains, use httpOnly cookies, or keep state in memory.
c15t handles this at the script and resource boundary. Its cookie management docs make the distinction clear: c15t does not manage every cookie on your site. It controls which scripts, iframes, and network requests are allowed to load. Those third-party resources are usually what set the cookies.
The hidden maintenance cost of a custom cookie banner
A custom cookie banner gives you maximum control. It also gives you maximum responsibility.
At minimum, your team may need to build and maintain:
- Consent state storage.
- Purpose or category preferences.
- Script gating before analytics, ads, pixels, and tag managers load.
- Preference updates and consent withdrawal.
- A way to reopen the preference dialog.
- Accessibility and keyboard behavior.
- Translation and localization.
- Region-aware defaults.
- Consent policy versioning.
- Backend records for accountability or support workflows.
- Tests that prove scripts do not load too early.
Browser storage may be enough for a small site, but it may not be enough when a privacy, support, or legal team needs to understand what a visitor chose, when they chose it, which policy version they saw, and whether the choice changed later.
GDPR accountability does not prescribe one database schema for cookie consent. It does require controllers to be able to demonstrate compliance with data protection principles. See GDPR Article 5(2). In practice, backend persistence and audit logs can become part of the consent design, especially for higher-risk sites, regulated teams, or sites with many third-party vendors.
If you build your own banner, your team owns that record-keeping model too.
Why c15t is a strong default for modern JavaScript apps
c15t reverses the tradeoff that pushed developers toward custom banners. You keep consent inside the app architecture, but you do not start from an empty file.
In Next.js, c15t provides @c15t/nextjs, a ConsentManagerProvider, prebuilt ConsentBanner and ConsentDialog components, App Router setup, hosted mode, offline mode, and server-side startup options. In React, c15t exposes providers, hooks, components, and headless paths. The comparison docs position c15t as a fit for JavaScript, React, and Next.js apps that need policy selection, script control, backend records, and framework support.
A basic Next.js setup looks like this:
'use client';
import { type ReactNode } from 'react';
import {
ConsentBanner,
ConsentDialog,
ConsentManagerProvider,
} from '@c15t/nextjs';
export function ConsentProvider({ children }: { children: ReactNode }) {
return (
<ConsentManagerProvider
options={{
mode: 'hosted',
backendURL: 'https://your-instance.c15t.dev',
consentCategories: ['necessary', 'measurement', 'marketing'],
}}
>
<ConsentBanner />
<ConsentDialog />
{children}
</ConsentManagerProvider>
);
}This initializes c15t, renders the banner and preference dialog, and makes consent state available to the app. It does not automatically discover every tracking script already on your site. You still need to register consent-gated scripts with c15t or remove tracking snippets that bypass the consent layer.
From there, you can customize the UI with props, design tokens, slots, CSS variables, noStyle, or headless components. You can stay close to the default UI or replace the visual layer when your product needs a fully custom consent experience.
That is the important difference from many legacy CMP setups. Developers do not have to choose between a generic hosted widget and a hand-rolled consent system. c15t gives them a consent foundation that fits the framework.
Script gating is where custom banners get risky
Custom banners often fail at the same point: the UI stores a choice, but scripts still load somewhere else.
That can happen when analytics are in app/layout.tsx, a marketing tag is injected by a CMS, a pixel loads through a tag manager, or a product analytics SDK initializes in a client component. If any of those paths bypass the banner, the banner is no longer the source of truth.
c15t's script loader keeps that behavior in one place. You declare scripts in the provider options, assign each script to a consent category, and let c15t manage the script lifecycle based on consent state. That lets the consent layer control analytics, pixels, tag managers, iframes, and vendor scripts without scattering one-off guards across the app.
For deeper implementation guides, see How to integrate Meta Pixel in Next.js with c15t and How to add PostHog to Next.js with GDPR-aware consent.
Consent may need backend persistence
A browser-only banner can remember a visitor's choice on that device. That may be enough for a low-risk site with a small set of scripts and no operational need to inspect consent history.
If the business needs durable records, browser storage is weaker. It can be cleared, it gives support and privacy teams no record to inspect, and it does not create server-side visibility into consent state.
c15t supports backend persistence for this reason. You can use c15t hosted on inth.com, or self-host it on your own infrastructure when you need to keep the consent backend inside your stack. If you do not need backend records, c15t offline mode can keep consent local in the browser while preserving the same framework integration and developer experience.
The engineering point is simple: if auditability matters, backend persistence should be part of the cookie banner decision from the start. You still need legal review for what you store, how long you store it, and how you disclose it.
When another approach may fit
c15t is not the only reasonable answer. An enterprise CMP may fit teams that need privacy-team dashboards, broad vendor scanning workflows, procurement-led controls, or coverage for platforms beyond a JavaScript web app. A custom internal platform may fit companies that already operate privacy infrastructure across many products.
Those cases are different from a React or Next.js product site that needs app-native consent state, script gating, and a choice between hosted, self-hosted, and offline deployment. For that use case, c15t is usually the more practical starting point than a fully custom banner.
A custom cookie banner can still make sense when the scope is small and stable. For example, a static site with no non-essential tracking may need only a short notice or no banner at all, depending on the technologies used and the jurisdictions involved. If your team still chooses custom, treat it like infrastructure: test that non-essential requests do not happen before consent, keep vendor categories under review, and document how visitors can change or withdraw their choices.
Cookie banner build vs buy decision guide
Use c15t when:
- You use React, Next.js, or another modern JavaScript framework.
- You want a custom-looking banner without custom consent infrastructure.
- You need to gate analytics, pixels, tag managers, iframes, or vendor scripts.
- You need backend consent records or audit history, using c15t hosted on inth.com or self-hosted.
- Your consent requirements are simple and browser-only storage is enough, using c15t offline mode.
Consider another approach when:
- You need privacy-team dashboards, scanning workflows, or procurement controls. An enterprise CMP or c15t plus operational tooling may fit better.
- You need broad non-JavaScript platform coverage. An enterprise CMP or internal platform may fit better.
- You have no non-essential cookies, scripts, or similar technologies. Confirm with counsel, because a banner may not be needed.
- You already operate a company-wide privacy platform. Custom or internal platform integration may fit better.
The main question is not whether your team can build a banner. Most teams can. The question is whether they want to maintain consent infrastructure every time the app, vendors, privacy policy, or regulatory requirements change.
For many modern JavaScript teams, the answer is no. They want the control that made custom builds attractive, with a consent layer that was designed for their stack. That is where c15t fits.
What to do next
You can now treat cookie banner build vs buy as an architecture decision, not a UI decision. If you need app-native consent state, script gating, and deployment options that range from offline mode to hosted or self-hosted backends, start with c15t.
Next, read the c15t Next.js quickstart and register your first consent-gated script with the c15t script loader. If you already run marketing or analytics tags, review the Meta Pixel and PostHog implementation guides before adding more vendor code.