Why cookie banners are our wedge

Users want them out of the way. Developers inherit them at the end of a build. Marketing wants its tools to load. Legal wants the company covered. Almost nobody thinks the result is good.

That shared frustration is useful. We do not have to persuade a team that the problem exists. They can see it sitting over their own homepage.

We first ran into it while building another company. We kept wrapping consent tools, fixing their styles, chasing their scripts, and checking whether a rejection stopped anything from loading. The same work appeared in every product, which made it an unsolved piece of the application stack.

Now you can vibe code a banner before the kettle boils. You get a modal, three buttons, and a cookie. It looks finished because the part you can see is simple.

The button is the smallest part of the consent system. The real work begins after someone clicks it.

The established tools were built around a dashboard for legal or marketing. Installation meant pasting a third-party script into a finished website. “No developer needed” was treated as a feature, even though developers owned the performance, the integration, and the data leakage when it went wrong.

The banner exposed the same gap we now see across privacy. Legal could define the rule, a dashboard could record the configuration, and a performance tool could show that the page was slow. None of that told the team whether a rejection still stopped the new script an engineer shipped that morning.

Nothing felt native to the codebase. There were no useful components, hooks, or typed APIs. Styling the banner to look like the rest of the product was harder than it should have been. Debugging it meant leaving the application and opening a black box somewhere else.

We wanted the logic handled without giving up the product experience. c15t puts consent in the bundle, gives the team real components, and still lets them bring their own design.

A team can spend weeks making a site fast, then lose the result to the scripts added just before launch. The consent tool is often one of them. It arrives through another network request, waits on another service, moves the page when it appears, and then loads more scripts behind it.

That is why we built Cookiebench. General performance tools can show that a page is slow. Cookiebench isolates the banner so a team can see what the consent layer itself costs.

c15t currently leads Cookiebench with a score of 95 out of 100. The benchmark records 63ms for both First Contentful Paint and Largest Contentful Paint, no layout shift, and no separate network payload for the bundled banner. The score reflects a simple standard: the first thing a user sees should not ruin the page.

Slow pages and clumsy interruptions cost the business. A banner that arrives late, shifts the layout, or feels nothing like the website gives a user one more reason to leave. Performance work is conversion work because it protects the experience the rest of the team built.

Consent acceptance is different. Our job is to make the choice fast, clear, and free of dark patterns, not to trick the largest possible number of people into clicking “accept”.

Tracking is different again. If analytics numbers fall because people who rejected tracking are no longer tracked, the consent system did not hurt conversion. It started reporting reality. A good tool has to protect site performance without pretending that a user’s rejection never happened.

The cookie banner gives us a narrow way into a much larger market. Every serious website needs an answer. The problem is visible. The implementation touches code, production, vendors, regions, user choices, and the evidence left behind. That is most of the privacy system in miniature.

We make c15t open source because the first job is to earn developer trust. A team can inspect it, ship it, style it, and see whether it works. We get to prove that privacy software can be fast and pleasant before asking the company to change how it manages privacy everywhere else.

The banner is where the separation between systems becomes obvious. Legal sets the rule. Marketing chooses the vendor. Engineering ships the scripts. Governance records the decision. A user’s browser is where all four have to agree.

c15t handles consent. Inth is the system around the change: what entered the codebase, what appeared in production, which vendor was involved, what the company told users, who reviewed it, and whether the fix held.

The banner is our first surface because it makes the whole problem concrete. The company we are building goes further. We want privacy to move with the product, one change and one piece of evidence at a time.