Christopher Burns - creator of c15t: the developer-first cookie banner
In his final interview for a job at Vercel, Chris Burns asked the observability team if they were building a cookie banner internally. They said no — so he decided to raise a seed round and build one instead.
Chris Burns is the creator of c15t and founder of consent.io, an open-source, developer-first provider of privacy infrastructure. He explains why he thinks most cookie banners aren't actually GDPR compliant, why performance became his company's core selling point, and how closing down his last startup led him straight into this one.
We also get into how he found product-market fit by listing every frustration from his old codebase and testing which ones the market still hadn't solved, and end up in a genuinely good debate about London versus San Francisco for European startups.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What are c15t and consent.io, exactly?
We think about it the way we think about Vercel and Next.js — a host and a framework. c15t is the open-source developer cookie banner that sits on your website, in React or WordPress or whatever. But to actually be GDPR compliant you need to store consents in a database, so you need an API and a database too — we built that as c15t as well, fully open source, and you can self-host it. Or you can spin it up much faster on our cloud product, consent.io. If something is purely a developer problem, we make it open-source configuration. If it's more of a marketer's or lawyer's problem — things like observability, generating your legal documents, your privacy policy, your terms and conditions — that's a consent.io thing.
How did you land on this idea?
This is my second startup — my last one, Everfund, was a nonprofit checkout solution, and we closed it down at the end of last year. I started interviewing at Vercel, but something didn't feel right. I'd always been a founder, and I don't think I can be hired. Around then I heard someone on a bootstrapping podcast explain how he found his idea: he looked through his previous product for the things he thought were the biggest problems, wrote them all down, and checked which ones the market still hadn't solved. I did the same thing with my old codebase, and the number one thing on the list was cookie banners and marketing-script management. I checked the market and there was still nothing built for developers, so I built a prototype in about two weeks and put it on Twitter.
What happened with the Vercel interview?
The prototype got a reaction from other SaaS founders straight away — one wanted to hire me to build it fully into their product, which I took as validation. I was still interviewing at Vercel at the time, on the observability team, and Guillermo talks a lot about hating cookie banners on X. In my final interview I asked if they were building this internally. They said no. So I knew I had a green light, and I decided to raise some capital instead of taking the job.
How did you raise that first round?
I went to one of my first-ever investors from my previous company and gave them an honest pitch: I'd just closed down my last company, my whole life had fallen apart, but here's a set of proof points that say there's something here. They agreed to give me six months of runway — if it wasn't working out at the end of that, we'd close it down and call it a bet that didn't pay off; if it was working, they'd support the next round. I raised from them and a few others, hired back one of my previous engineers, and we launched on Product Hunt in May. The most important thing about a Product Hunt launch is not expecting first place — it's getting it out there and then continuing to build and refine after. We're ending the year at around 52% month-on-month growth in npm downloads.
Why did performance become such a big focus?
We realised that building things into the bundle changed the speed and performance characteristics more than we expected, especially once we started experimenting with server-side rendering the cookie banner itself. We couldn't measure that with Lighthouse — it wasn't fine-grained enough — so we built our own benchmarking tool, CookieBench. With server-side rendering, we handle geolocation on the first request: if you're in the UK you see the banner, if you're in the US you don't, and the banner-visibility score we measured was 78 milliseconds from zero to the banner rendering. When we benchmarked competitors, c15t came out seven times faster than the slowest one we tested, and roughly twice as fast as the next closest. We published all of it openly, because the more CMPs that work this way, the better the web is for everybody.
You've argued most cookie banners aren't actually compliant. What's the tell?
I read that something like 70% of cookie banners aren't compliant, and the quickest tell is simple: if you click decline all, you shouldn't still see the Intercom widget, and no YouTube iframe should load, because YouTube tracks you too. Any analytics or marketing script should be disabled the moment someone declines. A lot of tools will say 'this doesn't need a cookie banner, there's no cookie' — but it's not really about cookies, it's about what people are consenting to be tracked by. If someone clicks reject all and a marketer complains their numbers dropped, that's the system working as intended, not a bug.
If giving so much away for free is core to the product, how do you make money?
We see the cookie banner as the loss leader — the wedge into a much bigger ecosystem. You can self-host c15t and never pay us a penny, and that alone could save you real money versus a paid competitor. What you don't get by self-hosting is the legal backing — the indemnification if a court says your cookie banner was wrong. So the paid side is hosting, observability, and indemnification, plus things like AI-assisted legal document generation, which is much cheaper than paying a lawyer $15,000 to write your terms and conditions. Long term, we'd rather be the developer-first option that grows through trust than chase the marketing teams who want tracking-friendly features — that's a different product, and a worse one for users.
You've talked a lot about London versus San Francisco. What's your take?
There's a pattern where a London startup gets into YCombinator, moves to San Francisco, and it's goodbye London. I go out to the Bay for a few weeks and love it, then come back and it feels like normality again. Almost all of our competitors are US companies, and I think that's actually a selling point for staying in Europe — why should a US company own GDPR compliance? I've also seen more UK investors start using US-style valuations over the past couple of years, which used to be a real blocker; it's the European investors, in Germany and Austria for instance, who still push back on valuations that would be normal in the US. I'd like to see London become the strongest tech hub outside of San Francisco, and I think it's happening more than people give it credit for.
Why is regulatory complexity — GDPR, CCPA, and so on — actually a good business for you to be in?
UK GDPR and EU GDPR have already diverged and are heading in different directions, so a UK startup could easily be implementing the wrong specification without knowing it. Then in the US, each state is different: in California any citizen can sue a tech company over a data leak, but in Utah only the district attorney can. California gives you seven days to disclose a breach; other states give you much longer. Founders shouldn't have to know any of this — we want to do for privacy compliance what Stripe did for payments: give developers a component to implement, and abstract the regulation away entirely.