Event Systems with Christopher Burns

Episode Description

Christopher Burns discusses his startup journey, lessons from Everfund's closure, and demos Better Events, an open-source privacy consent and analytics SDK.

Episode Summary

Anthony Campolo welcomes Christopher Burns, his former FSJam podcast co-host, to discuss what he's been up to since his startup Everfund shut down. Chris reflects on the emotional and practical realities of startup failure, emphasizing the importance of trusting your gut as a founder—particularly around Everfund's delayed pivot from developer-first tooling to enterprise customers. The conversation then shifts to his new open-source project, Better Events, which began as an internal event relay and cookie consent system he built at Everfund. Chris walks through the technical architecture: a framework-agnostic core written in TypeScript using Zustand for state management, with thin React wrappers and shadcn-style copy-paste components for cookie banners and privacy modals. He explains how the tool addresses GDPR, CCPA, and other global privacy regulations by giving developers headless consent management with a built-in developer tool for debugging which scripts render under different consent states. The project also aims to eventually include a server-side event relay that routes analytics to multiple providers without bloating client-side JavaScript. Anthony sees immediate practical value and proposes a follow-up stream to integrate Better Events into his own project, AutoShow.

Chapters

00:00:00 - Catching Up and the End of Everfund

Anthony and Christopher reconnect after a long hiatus from their FSJam podcast. Chris shares that his startup Everfund has closed after nearly seven years, opening up about the mental health toll of being a founder and the difficult decision to wind things down when energy and momentum ran out. He reflects on being 28 and considering his next steps—whether to move to San Francisco, get a job, consult, or start something new.

The conversation touches on the broader reality that most startups fail, and Anthony references Dax's observation that startups don't fail so much as founders eventually give up. Chris mentions he's written a blog post about his journey and has built a new personal website in Next.js, which includes a "hire me" page and a detailed uses page, all put together in about five days as he transitions to whatever comes next.

00:07:05 - Lessons Learned: Trusting Your Gut as a Founder

Chris breaks down the biggest lesson from Everfund: trusting your instincts as a founder. He describes how Everfund initially raised its seed round on a developer-first tooling vision for nonprofits, but developers lacked buying power compared to enterprise customers. Chris saw the need to pivot months before the team committed to it, but felt pressure to fully prove out the original thesis first, especially after taking outside investment.

The product launch confirmed Chris's gut feeling—despite strong developer interest, actual nonprofit sign-ups were minimal, revealing vanity metrics. Once they pivoted to enterprise, real growth followed. Chris notes that after taking a seed round, trusting your gut becomes harder because of competing stakeholder interests. He frames this tension as one of the most valuable lessons he'll carry into future ventures.

00:12:52 - What Are Event Systems and Why They Matter

The conversation shifts to the technical topic of analytical event systems. Chris explains that at Everfund, enterprise customers kept requesting integrations with different analytics platforms like Facebook Conversion API and Google Analytics. Rather than loading heavy third-party scripts onto the donation checkout, he built an internal event relay that collected lightweight frontend events and routed them server-side to multiple analytics providers simultaneously.

Chris distinguishes this from workflow orchestration tools like Temporal, clarifying that he's focused on user behavior analytics—tracking what users click, which features they use, and how they navigate an application. He connects this to the broader concept of product analytics and observability, noting that tools like PostHog operate in this space but rely heavily on client-side JavaScript, which creates performance and ad-blocker issues he wants to avoid.

00:22:08 - The Privacy Consent Problem and Cookie Banners

Chris explains how server-side event handling also addresses GDPR compliance challenges. He walks through the five GDPR privacy consent categories—necessary, marketing, analytics, functionality, and communication—and how cookie banners are really misnomers for broader privacy consent systems. The discussion covers how different countries handle consent differently, from blocking site access until consent is given to treating page interaction as implicit agreement.

Anthony shares that he always clicks "Reject All" and rarely sees fine-grained options upfront. Chris explains the two common implementation paths: marketers using Google Tag Manager to inject scripts freely, which tanks Lighthouse scores, or developers manually embedding SDKs and conditionally running them based on consent state. This sets the stage for why Better Events exists—to give developers clean, headless control over consent management.

00:25:02 - Better Events: Architecture and the Zustand-Powered Core

Chris introduces Better Events, his open-source project at better-events.dev, describing it as the spiritual successor to the consent and event systems he built at Everfund. He walks through the codebase, showing how a framework-agnostic TypeScript core uses Zustand for state management and attaches state to the browser window object so any framework can interact with it. The React layer is kept intentionally thin—just a context provider, country detection, and a useEffect subscription to sync window state changes with React's rendering cycle.

He explains the decision to separate the JS core from framework-specific wrappers, enabling future support for Vue, Svelte, or even jQuery-based WordPress sites. Anthony notes the code is clean and not overengineered, and Chris acknowledges that resisting the urge to bundle everything into the SDK was a deliberate design choice inspired by the shadcn philosophy of giving developers components they own and can customize.

00:34:13 - Developer Tools, Compliance Layers, and the Dev Experience

Chris demos the built-in developer tool that provides real-time observability into consent state, showing which privacy categories are active and which scripts would be conditionally rendered. He walks through the compliance layer system supporting GDPR, CCPA, LGPD, and US state-level privacy laws, explaining how the tool can intelligently detect a user's country to determine whether a cookie banner even needs to appear.

The technical demo shows how consent state persists in local storage across page refreshes, how accepting or rejecting consent updates the store, and how developers can conditionally render marketing scripts based on consent categories. Chris also explains the GDPR requirement to log every consent event with an IP address to a database, which he acknowledges is somewhat ironic given the regulation's privacy goals. This backend consent storage will be the next phase of the project.

00:53:17 - The Shadcn Registry System and Component Distribution

Chris explains his approach to distributing cookie banner components through a shadcn-style registry, where developers copy components directly into their codebases rather than installing an opaque dependency. He shows how shadcn's registry system works under the hood—a JSON schema that defines components, their dependencies, and target file paths—and how he's building an equivalent registry for Better Events' cookie banner, privacy modal, and consent toggle components.

He notes that he happened to be implementing his registry at the exact moment the shadcn maintainer was updating the CLI and build system, causing temporary breakage. Anthony draws a parallel to infrastructure as code for UI and immediately sees the value in the modular, customizable approach. Chris also introduces Fumadocs as his documentation framework, showing how MDX pages render component previews, installation instructions, and prop documentation.

01:17:31 - Practical Applications and Future Plans

Anthony realizes Better Events could solve a real problem for his own project, AutoShow, which will serve a global audience and needs privacy consent handling he hasn't addressed yet. He proposes a follow-up stream to integrate Better Events into AutoShow, which Chris enthusiastically agrees to. The demo shows the consent system working end-to-end in Next.js, with accept/reject flows updating state instantly and persisting across refreshes.

Chris discusses his vision for the project's second phase: a server-side event relay and ClickHouse database for analytics routing. The conversation wraps with a debate about the project's name—Anthony argues "Better Events" is confusing since the current focus is consent management, suggesting alternatives like "Better Cookies" or "Better Privacy." Chris explains he's keeping the name temporary while building in public, and shares that he's open to opportunities, contributions, and potentially turning the project into a company. He closes by expressing his aspiration to move to San Francisco and continue building.

Transcript

00:00:03 - Anthony Campolo

All right, we're live. Welcome back, everyone, to AJC and the Web Devs, featuring very special guest Christopher Burns, my old buddy from FSJam. How've you been, man?

00:00:19 - Christopher Burns

Good. It's been so long since we did FSJam. I don't want to stab you in the heart, but I kind of put it as a past thing on LinkedIn. It was like, do you still do it? And I was like, past.

00:00:35 - Anthony Campolo

Yeah, I've been putting it the same way. If anyone goes and looks, there hasn't been an episode in a year and a half, so people are going to think of it as defunct whether we think of it as not. I'm still thinking about bringing it back at one point, once we both hit a good place in our lives where we could do that.

I know you're currently in flux about whether you're going to start a company or get a job or any of that. So I think once that's settled, we might be able to bring it back. But why don't you tell everyone what you've been up to, how your life is going?

00:01:08 - Christopher Burns

Yeah. So what's really interesting is startups don't always succeed. They say most startups fail.

00:01:19 - Anthony Campolo

I always heard nine out of ten startups fail. So "most startups fail" is really the way people should be thinking about it.

00:01:28 - Christopher Burns

Around the same time, I've seen other startups close down or do hard pivots. It's a long story, the seven-year journey of being a founder and creating a company, going from graduate to founder. And I'm still relatively young, I'm only 28, so I've got a lot of time ahead of me.

We got to a point where we ran out of time and energy, more than anything else. I think that's such a hard thing that a lot of people struggle to talk about, especially as a founder: your mental health, the current state of the business, do you even want to raise another round? There are obviously so many factors that cause startups not to go the way they're expected to.

00:02:39 - Christopher Burns

I learned a lot of lessons on the journey. I'm sad to see it close, and there were customers who were sad to see it close. But I'd say it was the right thing to do at the right time. I'm currently looking at new opportunities—do I want to move to America, to San Francisco? Do I want to stay in the UK long term? Do I want to work at another company? Do I want to consult? Do I want to maybe start another company?

I don't know yet, but there are tons of things I'm playing around with and ideas I just can't seem to drop. I'm happy to speak about one of them today. It is quite early, but I think that's also kind of the fun. It's still ground zero, MVP you could say.

00:03:38 - Anthony Campolo

Yeah, I feel like you have the entrepreneurial spirit, which is one of the reasons I think you'll probably enjoy America a bit more than where you're at right now. It's not that there aren't entrepreneurial people in the UK—obviously you were there and you found a startup partner. But I think you'll find a larger pool of people there and a system set up a little bit more to support it.

What you're saying about running out of energy—Dax actually had a tweet about that where he was basically saying startups don't really fail, founders give up. I don't know exactly how he worded it. But when you're doing it for so long—you did almost a decade, longer than half a decade—if you're not getting the traction you want, there's a certain point where it makes more sense to cut your losses and try something else, especially if you're just not interested in it anymore.

00:04:40 - Anthony Campolo

So I think it's cool that you've decided to move on. I remember when I was first getting into tech, the late 2010s, I feel like there was this trend where everyone had to have a blog post about their startup that failed. People would try a startup, it would fail, then they'd write the story of the whole journey. And I feel like you did this, didn't you? Didn't you write a blog post?

00:05:06 - Christopher Burns

Yeah, I did. We can actually pull up my website and go through it quickly. So this is a new website that I've built since doing the startup. What's really interesting is the framework choices.

00:05:23 - Anthony Campolo

A little bigger.

00:05:24 - Christopher Burns

Yeah. Framework choices are a super interesting thing, because this is built in—yeah, exactly. This is built in Next.js, but there's almost no reason for it to be built in Next.js. There's no server-side rendering, there's no fetching of any content. It's just markdown, just pulling it all together. Part of me was like, it's what I know, and especially with wanting to keep my skills as sharp as possible, I just kept it in Next.js. It's pretty cool.

We have my humble past. Even though I've done a startup for almost seven years, there was a time when I graduated and me and Will actually created Below. This was our first startup, and I actually got a job in McDonald's for a year to take a salary and pay for my way along the journey.

00:06:31 - Anthony Campolo

Uber Eats days.

00:06:33 - Christopher Burns

Yeah. One of my ex-team members was like, "Why do you put that on there?" And it's like, because you've got to be humble to a certain extent. I'm not better than McDonald's. It shows lessons learned along that journey. And yeah, I wrote this article about what I've learned, what I'm looking forward to, what's next.

00:07:05 - Anthony Campolo

People can check it out and read it. I would be curious though—if you want to just break down the key takeaway points, what did you learn? I think that's what people would find most interesting.

00:07:15 - Christopher Burns

Yeah, I think some of the biggest things I learned were very counterintuitive, but trusting your gut nine times out of ten was actually the right thing to do, especially in my time at Everfund. A lot of my time as we grew was very much going against my gut feelings, because of—

00:07:41 - Anthony Campolo

Give a specific example. What was a time where your gut told you one thing, but the data or the experts or whoever told you another thing?

00:07:50 - Christopher Burns

Yeah, that's a perfect example around this. It was our pivot to enterprise-first tooling for Everfund. We spent the first year of our seed round focusing on developer tooling, and it was one of these paradoxical situations where I'd spent so much time on FSJam and being a developer advocate that we got into a position where we were skewing Everfund toward developers.

What we found was developers loved it—they liked how easy it was to integrate, how easy it was to get going. But they didn't have the buying power. It's very different to something like Vercel or Netlify, where it's not even on the table when deciding a choice of platform. So I saw this pivot a few months before Will did, and obviously I discussed it with him.

But we had this concept—and I think it's important to say—we raised our round on an idea: developer-first tooling for nonprofits.

00:09:03 - Christopher Burns

Between me and Will and the rest of the team, we felt like we couldn't pivot until we had 100% proven that we weren't going to make it on developer tooling. It was actually the product launch that was that signal to us. We got a lot of interest, but the actual number of charities signing up was so low. It felt like vanity metrics, if you know what I mean.

That's when we really pivoted to the enterprise-first model. We doubled down on some of our enterprise customers, and that's when we actually started seeing decent growth opportunity in Everfund.

00:09:57 - Anthony Campolo

So you feel like you should have basically started with enterprise instead of going down the whole route of developer-first tools.

00:10:03 - Christopher Burns

Yeah. And what we're going to talk about today is quite paradoxical as well, because it is a developer tool—something I'm building for developers.

00:10:12 - Anthony Campolo

It's your happy place.

00:10:13 - Christopher Burns

It's a really interesting area. And like I said, we never regretted making our developer tooling because it made the enterprises so much easier to get across the line. What made it harder was actually getting somebody to buy—finding the right buyer. It was really much more of a business pivot that did it.

There are always tons of things at play. But I think trusting your founder's gut is maybe one of the biggest lessons I would take away. Up to our angel round, I trusted that well. But after we took a seed round, things got more complicated and it felt harder to trust your gut, because now you had a team, loads of different customers, all of these different things going on. It's much harder to manage. But at the same time, a hell of a lot of lessons learned that I'll be taking on board going forward.

00:11:25 - Christopher Burns

So that's my blog. I also have, if I do go forward with getting a job, a hire me page with things I'm looking for in my next role, what I really want for impact and experience—and a little cow widget. What's really cool is, did you click these buttons here, Anthony?

00:11:56 - Anthony Campolo

No. Change the color?

00:11:59 - Christopher Burns

You are missing out.

00:12:00 - Anthony Campolo

I'm not one to click random buttons. I don't know what they do on websites.

00:12:05 - Christopher Burns

Honestly—

00:12:07 - Anthony Campolo

Some people have that desire. They have to click everything on the screen. I'm usually just looking at the information and what I'm trying to do. I'll miss entire features on websites for years.

00:12:18 - Christopher Burns

I'm massively that kind of person. I would just click everything. I also put together a page of everything I use—podcasting gear, developer tools, design, productivity, all those fun things. This website was really fun to put together. I think it took about four or five days, a fun project before I moved on to my next one.

00:12:52 - Anthony Campolo

Solid. So the name of this episode is "Event Systems." What is an event system—are we talking about events in the colloquial sense, like doing stuff with people, or events in a developer sense?

00:13:08 - Christopher Burns

We're talking about it in a developer sense, in terms of analytical events. To give context for why I'm really interested in this opportunity: when we were building Everfund and scaling with enterprises, the early enterprises that trusted us kept asking for different sets of APIs—can we get the Facebook Conversion API? Can we get the Snapchat API? Can we put our own Google Analytics on the page?

00:13:59 - Anthony Campolo

Is this when you went down that rabbit hole of scripts?

00:14:03 - Christopher Burns

Yes. And we'll come back to that.

00:14:07 - Anthony Campolo

We did the FSJam widgets episode about this.

00:14:11 - Christopher Burns

Yeah. Actually it was a lot later than that—it's something I've thought about for a while. But one of the most important things was that I was very particular about keeping a super-fast donation checkout experience. I didn't want to gunk it up with their Google Tag Manager, their cookie banner, their various integration tools.

So I wanted to find a way where we could take a unified event that would fire on the front end—donation checkout started, checkout finished, checkout canceled, user behavioral events—collect them, then send them off through a relay. That relay would collect the event from the front end and split it to whatever providers you wanted that data to go to.

00:15:22 - Christopher Burns

For us at Everfund, we were using PostHog and the Facebook Conversion API. So that one event on the front end, without including any additional JavaScript, was now sending data to two locations. This is not a new technology—it's been around a long time.

00:15:48 - Anthony Campolo

Is that something like Temporal does?

00:15:50 - Christopher Burns

I don't know Temporal, but I can tell you it's what Segment does.

00:15:56 - Anthony Campolo

Okay. Because Temporal is the one I always hear for event management.

00:16:01 - Christopher Burns

That's a different kind of event.

00:16:07 - Anthony Campolo

That's why I want to be specific about the terminology.

00:16:10 - Christopher Burns

Right. Temporal is far more like this: an order comes in and now there's a list of things you need to do, and you set up a chain of programming actions based on that event. Think of webhooks as that kind of event orchestrator—you get different webhooks requiring different tasks. You hear this often as a way to asynchronously handle tasks, passing events to a queue that churns through them. We're not talking about that kind of event system. We're talking about the analytical system behind user behavior.

00:17:27 - Christopher Burns

What does that mean? The first step to understanding how well your website works is basic analytics—you see who went to the website and when they dropped off. The second stage is understanding which pages they visited. But what about what they actually interacted with on that page? Which buttons they clicked, which user events they triggered. This is very much about tracking all of those user events. When you build something like a dashboard, you track those user analytics—this feature has a lot of behavior behind it, that feature is barely being used—and you can use those metrics to guide what you build next.

00:18:37 - Anthony Campolo

Yeah, I feel like this is what people talk about when they use the term "observability."

00:18:41 - Christopher Burns

Yes, that's a really interesting umbrella term.

00:18:46 - Anthony Campolo

Observability can also get into logging and observing your back end. But what you're talking about is more the front-end side of that.

00:18:57 - Christopher Burns

Yes. Observability is this really big term. There are three pillars: monitoring—think of the lights on your car dashboard telling you to change your battery; logs—what caused an error, what made it happen; and tracing—attaching spans to understand multi-part failures. Those three things are very much analytical tracking of how systems perform. What we're talking about here is tracking that for people—user behavior. And yes, I do think it falls under observability, but it's a much more niche use case, because it's something that normally gets added late stage into an application.

00:20:14 - Christopher Burns

You wouldn't look to add onClick tracking handlers to every single button from day one, or track every page visit. And tracking that is one thing—but you also need a solution to view that data. One of the solutions that's become really popular lately is PostHog. Have you ever used PostHog?

00:20:42 - Anthony Campolo

I haven't. I've heard of it though, and they have "observe" right there in their tagline. So yeah, I get the sense of what it is based on that whole introduction you just gave.

00:20:58 - Christopher Burns

And it covers the different areas. What PostHog calls it is "product analytics."

00:21:07 - Anthony Campolo

And that's Noah's company, Phantom. They're one of the big Web3 companies behind Solana.

00:21:14 - Christopher Burns

That's really cool.

00:21:16 - Anthony Campolo

That's one of the integrations for AutoShow.

00:21:19 - Christopher Burns

There you go. I'm not really checked in with all these Web3 companies. Maybe I should. So yeah, product analytics is what this normally falls into—working out how a feature is used. What's really interesting about PostHog, and why I'm showing it, is that PostHog technically does what I'm discussing building, but they do it in a very client-side JavaScript-heavy way, focusing on a full front-to-back experience where you install the tool and put their click handlers wherever you track events.

00:22:08 - Anthony Campolo

So you want to observe the front end, but through server-side events.

00:22:12 - Christopher Burns

Exactly. And that way you also reduce the risk of ad blockers blocking your traffic and your understanding of usage, because you're not running much client-side logic. You're basically sending these really small fetch requests off to the relay saying, "This event has happened."

What's really interesting about this whole space is there's a massive factor in the EU that affects all of this: GDPR. Cookie banners and such have huge effects on user experience.

00:23:06 - Anthony Campolo

They make every website worse by default is how I would put it.

00:23:10 - Christopher Burns

Exactly. And we're very much used to cookie banners that look something like this. We could say let's fully reset the page, something very ugly, very clunky. It is not native to your application because it normally gets loaded through a script tag.

Customization—say if you wanted to run the underlying logic layer, but you wanted to put your own cookie banner—you get restricted. So it's a really complicated area that I'm actually really excited to talk about and discuss what I've been doing in this area and the learnings I have. Because what I've actually been building is the first part of this idea that I'm calling Better Events.

It's not necessarily a company at this point, but I think it is quite interesting to think about a cloud solution for this.

00:24:14 - Anthony Campolo

For this.

00:24:16 - Christopher Burns

So currently it's better-events.dev.

00:24:20 - Anthony Campolo

That's it. So you had "better" with a hyphen—it wasn't .com, and I was like, what was it? By the way, I see you're still running—what's this browser called again? Have you not heard that Arc is being discontinued?

00:24:39 - Christopher Burns

Yeah, I do have Zen on my computer as well. It's just picking a day to migrate over.

00:24:47 - Anthony Campolo

I was in the same boat. Once I heard that, I had to get off Arc, so I just started using Edge because I don't want to use Chrome.

00:24:56 - Christopher Burns

I went through a phase where I used Edge. It's okay.

00:24:59 - Anthony Campolo

It's okay. Yeah.

00:25:02 - Christopher Burns

So this is obviously still super early. It's open source, and we can go through the repo.

00:25:13 - Anthony Campolo

The repo there too.

00:25:16 - Christopher Burns

It's slash better-events—hyphen better-events—slash hyphen better-events. Pretty golden.

We are still very early on this project, but there's already been a lot of work behind the scenes. This is the spiritual successor to the event system and the cookie management system I built at Everfund as first steps.

So let's actually talk about building a cookie banner. It's something that everybody needs if you're going to be tracking any marketing, even if you're a US company. The legalities are long and we're not really here to talk about that, but let's talk about building a cookie system. Let me load up the SDK demo I've been working on.

00:26:34 - Christopher Burns

Here we go. Let me just reset this.

00:26:40 - Anthony Campolo

Is that where you got the name idea from?

00:26:42 - Christopher Burns

Yeah. It's very unoriginal at this stage, but I just wanted to stick a name on it and start moving forward, instead of going on some spiritual journey to find the perfect name. Does the name actually matter? I don't know right now, but that's what it's called currently.

So let's talk about event cookie systems and how they work. We're speaking in terms of the EU right now, but obviously California has their own laws, Utah has their own laws, Brazil has their own laws.

Something we often forget is that we call them "cookie banners," but that's really a misnomer for what they're trying to achieve. It's actually privacy consent.

00:27:59 - Christopher Burns

The misnomer. Yeah, there you go.

00:28:02 - Anthony Campolo

And I thought—this is funny. When Neo goes to see the Oracle, he has to accept a cookie to talk to her. Remember?

00:28:11 - Christopher Burns

Yeah. And obviously cookies are a really important thing, but there's also other things that we'll get into. So let's quickly understand this.

So right now under GDPR, there's five types of privacy categories that you could say, and I'm going to struggle to list all five off the top of my head, but I think it's necessary, marketing, analytics, functionality. And I forgot the last one.

00:28:50 - Anthony Campolo

I've literally never heard of this. I see cookie banners all the time but I've never made one myself.

From the user's perspective, you don't usually see all five of these. Usually they give you two buttons: "Accept All" or "Reject All." So I obviously always click "Reject All" if that's an option. Maybe one out of ten times I'll see more fine-grained options, which is what you're talking about right now. It's very rare they expose them upfront. You can usually click to find them, but who wants to do that?

00:29:26 - Christopher Burns

And there's a lot of balance here between legalities. For example, if the cookie banner pops up and you interact with the page, some countries will accept that as consent given. Others won't. Some countries want to block access to the complete website until you've agreed to some kind of privacy preference. Others are more fluid.

But under all of them is the philosophy that when you click "None," you're only accepting the necessities—the minimum, the essential.

00:30:17 - Anthony Campolo

And functional.

00:30:18 - Christopher Burns

Probably functionality too. Things like Facebook Pixel—you're saying no to those. Some companies define these categories slightly differently because it's partly up to interpretation.

For example, if you're building a React application, there are normally two paths to implement this. You either have someone with a marketing background who says, "Let's use Google Tag Manager"—and if you've ever used it, what a fun tool. That basically lets the marketer inject any script they want, which plays by the same five-category system in the background. Once those categories get accepted, they load a bunch of scripts onto the website.

This is how you see people say, "My website is 90 to 100% on Lighthouse," and then the marketing department comes along and it drops to 50.

00:31:31 - Christopher Burns

Because they start putting all these JavaScript bundles onto the website.

So there's that method, or the other method—which we used at Everfund, and I think is still quite popular—where you look for the company's SDK or script, embed it in your source code, and say, "Just run." The problem there is you actually need to conditionally run it. You need to say, "This should only run if they've agreed to marketing or analytics." So you need more finite control of the functionality.

Communication—that's the last one. The fifth category is communication.

00:32:25 - Anthony Campolo

So actually I asked ChatGPT, and the five categories it gave is strictly necessary, which is called essential; preferences, which is called functionality; analytics, which is called performance/statistics; marketing, which is called targeting/advertising; and then social media, sometimes included under marketing. So some of these are pretty fluid.

00:32:48 - Christopher Burns

Yeah, exactly. All of that functionality runs in the background, restricting the website's scripting.

One of the things I want to do with this project is make the most streamlined version we can. And secondly, give people the capability to add their own cookie banners—putting that control in the hands of the user. "You can make a cookie banner look however you want, but we're going to give you a selection of components for frameworks like React, and you copy it into your application and you're done."

So we've covered two or three aspects of this—it's either a super interesting area or super boring depending on who you are. But it actually becomes a massive deal the more you scale up websites. What's really interesting is down here in the bottom right.

00:34:13 - Christopher Burns

This is where we start talking about some really cool things: the developer tool I've been building into the website to give real-time observability into consent state.

As we can see, consent is currently only set to "necessary." So if I'm building out my website and testing functionality, I can quickly open the dev tool and see, "Oh, it's only on necessary—are all the other things rendering or not?" Really useful for understanding which scripts are conditionally rendering.

We've also built in the compliance layer system so far, handling GDPR, CCPA, LGPD, and US state privacy laws. It's a lot deeper than that because each state can define its own privacy laws as well.

So there's already a pretty big system running in the background here.

00:35:38 - Christopher Burns

And I'm happy to go over it and talk about it more deeply.

00:35:49 - Anthony Campolo

Yeah. Full transparency, my wife and I are working out some tax things we have to figure out today. So I'm kind of messaging—this will only take like five more minutes. But you should keep going, go through your code and project, and talk a bit about how you set that up. I'll be with you mentally in five minutes at most.

00:36:09 - Christopher Burns

Totally cool. I understand taxes in the US are super different to the UK.

00:36:17 - Anthony Campolo

We actually have a professional tax manager, and it's even more complicated than when we did it ourselves.

00:36:26 - Christopher Burns

100%. So let's actually look at some code. How does this work behind the scenes? If you want to allow my screen share, Anthony.

00:36:35 - Anthony Campolo

Yes.

00:36:37 - Christopher Burns

Behind the scenes there are easy ways and slightly more challenging ways to structure this.

Looking at the web as a whole—if we built a React-only system, we'd be limiting the usability to just React. So how do you take a core, in pure TypeScript, and add thin wrappers around it for different frameworks like Vue, React, or SolidJS?

What we can see is a pretty simple package structure: we have a core that has a core JS file and a React package.

00:38:05 - Christopher Burns

When we talked about the consent solution manager, you need to track all of that consent in the background, keep it in local storage. If they refresh the page, do you need to re-show the cookie banner? Close the cookie banner? Pop up the privacy banner? All of that logic needs to live somewhere.

My first version of this actually had a huge amount of—the word's not coming to me now—useState.

00:38:54 - Anthony Campolo

Just regular React useState.

00:38:56 - Christopher Burns

Yeah, useState. And I thought, how can I make this as thin as possible going forward? So one of the first things I started on was state management.

00:39:15 - Anthony Campolo

Good old state management.

00:39:17 - Christopher Burns

Yeah, I'm a big fan of state.

00:39:22 - Anthony Campolo

I see Zustand in here. Looks like that's what you landed on.

00:39:25 - Christopher Burns

Yeah. So I started building with XState and thought, I like it, but maybe it's a bit too overkill right now. I have a feeling I could go back to it—I don't know, we'll see, because there's still a lot of things to build.

00:39:41 - Anthony Campolo

I remember the only time I ever used XState was when you were using it at Everfund. I did the Stripe integration.

00:39:48 - Christopher Burns

Yeah. And XState is fun if you've got really complicated state flows.

00:40:01 - Anthony Campolo

I was having to write docs for myself just to understand it.

00:40:05 - Christopher Burns

Yeah. It's got some really cool dev tools. I had an engineer I told about them, and they were like, "What?! That would have made it 20 times easier to understand."

So yeah, it's a big fundamental shift in logic. What I landed on was Zustand. I'd never really used Zustand before—I just kind of started it up and got going.

And what we have is a really thin store of state that also gets attached to the window—to window.better-events-store. This way other applications can also use it. There may be a use case where your framework doesn't have bindings for the core, and you'd use the window to communicate through it instead of installing it as a dependency.

00:41:17 - Christopher Burns

If that makes sense. You attach it to the window and then interact with it through that.

00:41:24 - Anthony Campolo

Isn't it still being installed at the bundling step, because you're still importing it at the top?

00:41:30 - Christopher Burns

Yeah. So there are two ways to do it: installing the bundled version, where you install and initialize it, or putting a script tag on the page that then initializes the window.

Some tools this package might go on don't have a bundling step, so you need to account for that. You can think of it like how Million.js works, where you can either put a script tag on the page or bundle it into your technology.

So yeah, we bundle it to the window, and then we obviously have things like callbacks, compliance types, and compliance regions. For GDPR, here are the five types: experience, functionality, marketing, measurement, and necessary.

00:42:46 - Christopher Burns

And obviously you have the longer descriptions: "This tracker is used for..."

00:42:55 - Anthony Campolo

I know you said "cookies" isn't the best word, but I feel like what you're building right now, "Better Cookies" would make more sense as a name than "Better Events," because this is really giving you a lot in terms of cookie consent.

00:43:08 - Christopher Burns

The only thing is that "cookies" is such a misnomer. Because how this saves to your browser when it reloads is not cookies—it's using local storage. Cookies are...

00:43:31 - Anthony Campolo

Well, there's the technical cookies, yes, but then there's like what people think of. People who are not developers know about cookies.

00:43:42 - Christopher Burns

Yeah, stuff on your computer, but they don't know what session storage is or local storage.

So yeah, that is something that—it's one of these weird things where it's like, is it a privacy popup or is it a cookies popup? The word everybody knows is "cookies popup," but actually it's more like a privacy popup at this point.

So that is the core bundle that we just spoke about. And all we basically do is strip it out currently as a store, and then that's where we use...

00:44:25 - Anthony Campolo

You probably explained this at the top, but I wasn't paying attention. So you're using Zustand on the backend? Not in React?

00:44:32 - Christopher Burns

Yeah, no, no. So there's no backend. This doesn't have a backend yet. That's the stage two of the company where we build in the event system.

So think of this as just a simple way for you to do everything client-side and restrict marketing tools client-side. Stage two is building that event system.

00:44:57 - Anthony Campolo

Yeah, I guess I'm just asking—and again, I'm sure you explained this—why are JS and React two separate things in core?

00:45:03 - Christopher Burns

Okay, yeah, I think that's a really good question actually. And also even though it's called JS, it's actually TS.

00:45:14 - Anthony Campolo

So is that just like a Node server? Like what is that?

00:45:18 - Christopher Burns

No, it's for the frontend. If you think about putting it onto a WordPress website, that's where you would use the JS core and wrap it with jQuery bindings, or bindings that don't necessarily have a frontend framework.

00:45:40 - Anthony Campolo

Does this make sense? When you build a vanilla JS website with HTML, CSS, and injected JavaScript, is that kind of like having a React frontend and injecting the JS part?

00:45:55 - Christopher Burns

Exactly. And it allows you to not use a rendering framework like React, and still support a Svelte version or a Vue version, without having to bundle all the React into it.

So yeah, we use Zustand to create a store in the core. And then we have a super thin wrapper that exposes a hook.

When we talk about the React layer—we want to keep that React layer as thin as possible and have as much logic handled by the framework-agnostic core. So no matter what framework you use, you're not rebuilding much logic.

All this is is a very simple React context that also detects country. This is something that needs a bit more work.

00:47:15 - Christopher Burns

Depending on your middleware, if you can work out the user's country, you could also say, "Oh, they're from the US—don't even show them a cookie banner. Oh, they're from the EU—show them a cookie banner."

So you want to be intelligent about only showing the consent options to those who need it. And a simple store getter where we do this useEffect hook to subscribe to state changes, and an unsubscribe.

Because if you don't do this upfront, your hooks could be updating the store but React never knows when to actually update the components. Since it's attached to the window, you need to watch for changes to that object to make sure React re-renders.

00:48:19 - Anthony Campolo

You built this with just straight React, you're not using a framework at all.

00:48:23 - Christopher Burns

Yeah, this is just straight React at this point. There's no Next.js in it.

00:48:27 - Anthony Campolo

That's really funny that you're doing this with just straight React, but you use Next for your personal blog website.

00:48:38 - Christopher Burns

Yeah, because this is the SDK. It doesn't need a framework technically. I've been very conscious of keeping things like the cookie banner and the privacy modal out of the SDK and inside the end user's app.

Very much like shadcn. When you go to the components section on the docs website, you actually have these components. We have three components currently, and you basically have this cookie banner that I'm going to be uploading to a shared repository so you can easily install it. And technically you could remove the privacy consent hook and use this for completely your own cookie logic.

00:49:57 - Anthony Campolo

Yeah, so you've made it modular and easy. And you say here Next.js is a framework.

00:50:04 - Christopher Burns

Yeah, it's a framework. Think of it as: React is the rendering logic. You could build a complete cookie banner with just JavaScript by adding things to the DOM, setting class names.

00:50:25 - Anthony Campolo

Good old web components.

00:50:27 - Christopher Burns

Yeah, but what we want to say is: you're very used to your framework, you're very used to certain components. Let's just make it as easy as possible to get your components, hook them up to the consent solution, and go from there.

So as we see, we have what we were showing before—accept or reject, handle close, checking if mounted, and then the actual cookie banner. And then we do something interesting. Have you ever used a React portal?

00:51:10 - Anthony Campolo

We've talked about this on the podcast a bunch of times. And no, I've never used a React portal. It's like an iframe, right?

00:51:18 - Christopher Burns

Yeah, basically it injects—

00:51:21 - Anthony Campolo

There's the web portal, and then there's the React portal. They're different. I'm thinking of the web one.

00:51:27 - Christopher Burns

So the web portal is like an iframe. But a React portal basically pulls that component outside of the DOM tree and injects it somewhere else. So this is basically saying: mount this content to document.body—outside the JSX DOM tree that you've created.

00:51:51 - Anthony Campolo

To make sure it's always—

00:51:54 - Christopher Burns

Sitting on top of the DOM tree. So yeah, this component is going to be on a CDN, a shared UI registry. We can go through the docs website too, because the work I've been doing on that is actually really cool.

You have a cookie banner, and the widget is actually that consent toggle system we showed when you click "Customize," but completely standalone. So if you wanted to embed it into a web page like a privacy page, you could do that.

And then we have the modal version. This is just using simple HTML and Tailwind. But it starts becoming really powerful because it puts control of that cookie banner directly into the user's codebase, where they can change the HTML, the text, the Tailwind, and have it look exactly how they want, because every platform handles it slightly differently.

00:53:17 - Christopher Burns

So this is pulling that logic out, letting them copy and paste it into their app and connect it up.

00:53:28 - Anthony Campolo

Yeah, super interesting. Your code is very clean. What you just explained was easy to understand, and I feel like you definitely haven't overengineered anything.

00:53:46 - Christopher Burns

Yeah.

00:53:47 - Anthony Campolo

And in the past, that's been a bit of an issue.

00:53:50 - Christopher Burns

Yeah, but it's so easy to overengineer it.

00:53:56 - Anthony Campolo

I know.

00:53:57 - Christopher Burns

It's so easy to think, "We'll put the cookie banner inside the SDK and provide one automatically." And sure, there will be a version where we give out an included cookie banner.

But one of the biggest things we want to do by default is give a headless API for controlling consent management. That's where the developer tool comes in—to track what is rendering, what scripts are being fired off. And all of that is going to be backed by a shadcn registry. Have you ever actually looked at a registry and seen how it works?

00:54:53 - Anthony Campolo

I've never used shadcn at all. I have absolutely no experience. Obviously, I've heard people talk about it for years, but never got into it. I was never really in the whole Next.js world.

00:55:07 - Christopher Burns

Yeah, so actually it's super interesting.

00:55:13 - Anthony Campolo

Arsenal and the Spurs are football teams.

00:55:20 - Christopher Burns

Yeah, actual football.

00:55:24 - Anthony Campolo

Fuzzy's dropping sports updates. I think that was more for you than for me.

00:55:34 - Christopher Burns

Yeah. So what we have here is setting up a shared repository to be able to copy the code. Let me share my browser and we can talk through this part.

This actually hasn't delayed the project, but it's one of those things that sounds so easy.

00:56:17 - Anthony Campolo

Keep going. For the next ten minutes, I'm going to be listening off screen just for a second.

00:56:22 - Christopher Burns

So you'd better be listening, because I'm going to be explaining this to you. What we're super used to is looking at all of these components and being able to easily copy them into our code directory using the CLI tool.

But when you click "Manual" you can see what it's going to do: install a React accordion, copy this code into your directory, update your Tailwind. Off the bat that's super easy if you want a manual setup and want to change things easily.

Where it gets really interesting is these other component systems that have started appearing—other people have built other components, like this really cool marquee, and they use the same shadcn system to achieve that. To do that you have to spin up... Oh, my tab wasn't actually moving. Sorry.

00:58:03 - Anthony Campolo

So I was about to say you're only showing your one screen.

00:58:07 - Christopher Burns

No, I thought my tab was moving.

00:58:12 - Anthony Campolo

Fuzzy is again saying, "Chris, this is awesome." So it sounds like you've got one fan and hopefully a user already.

00:58:18 - Christopher Burns

That's great to hear. We are really early. This is ground zero.

00:58:23 - Anthony Campolo

This actually strikes me as the type of project Fuzzy would especially like, because of how you've built it and what it aims to do. Fuzzy cares about privacy, web standards, those kinds of things. And these are the types of developers you're trying to reach.

00:58:50 - Christopher Burns

Yeah, exactly. So let's give you a tutorial on this, Anthony.

00:59:07 - Anthony Campolo

You can bump up your font one more. So it's like a component library slash design system—stuff that's prebuilt to make your front end look less like crap and hopefully function.

00:59:20 - Christopher Burns

Exactly. But the big difference is it copies it into your codebase. So when you look at this command...

00:59:32 - Anthony Campolo

So it's super modularized.

00:59:35 - Christopher Burns

Into your codebase. You can see here, this is the code it's going to be copying in.

00:59:42 - Anthony Campolo

I can already see why people like this, because the biggest issue with using something like this is not having the granularity to modify the components.

00:59:54 - Christopher Burns

Exactly. So what I've been working on is setting up this shadcn-like system for the cookie components, for the popup banner and privacy modal. I've made some progress on it, with some blockers we'll discuss in a minute.

What we see as well is things like Magic UI, another popular one in the same vein, but this one is more about marketing components—like a bento grid—rather than dashboard components.

01:00:44 - Anthony Campolo

Fuzzy says the toast component would be prior art for this.

01:00:50 - Christopher Burns

Yeah, toasts are a big one. And you see that this command still uses the base command, but then it says go to this repository and pull up the file.

So let's actually look into that a little bit deeper, because I've actually made progress on how it works. If you wanted to create your own files that people can easily copy into their own directories, it's something I've been working on.

01:01:30 - Anthony Campolo

So were you using shadcn with Everfund?

01:01:34 - Christopher Burns

No, we never actually used shadcn with Everfund. We used a lot of the Tailwind base components from back in the day and then heavily customized them on top.

My marketing website does use mostly shadcn components, but they look completely different because they're so heavily customized. A card component, a button component, but they look nothing like the defaults.

This concept of copy-pasting components into your code is getting more and more popular. This is why I thought it was really important to say: we're not going to control the base experience for the cookie banner. We're going to create components that you copy and paste into your codebase so you can customize them however you want, instead of having this generic banner that everybody has.

01:02:54 - Anthony Campolo

Fuzzy's complimenting your mustache, by the way.

01:02:58 - Christopher Burns

Thank you.

01:02:59 - Anthony Campolo

I said the same thing when we were on a call a couple weeks ago. I was like, hey, look at that stache.

01:03:10 - Anthony Campolo

This is also streaming on YouTube. I'll drop the link in here.

01:03:16 - Christopher Burns

Definitely. Fuzzy, happy to talk anytime—just send me a DM on Twitter/X.

01:03:29 - Anthony Campolo

Later, man. Thanks for hanging out. I'll send you the link on Discord.

01:03:35 - Christopher Burns

So yeah, having these repositories is a really cool system. It's super early, because I'm pretty sure I was building out my shadcn registry system at the exact moment the maintainer was updating it. So how do you actually create these components?

There's basically a build step that goes with it.

01:04:21 - Anthony Campolo

Okay, real quick, since Dev just hopped into the stream—I wanted to explain what you've done so far concisely. You can let me know if this makes sense. You're explaining your new project, Better Events, which uses shadcn to create a bunch of hooks and components for managing cookies and user privacy consent widgets.

01:04:40 - Christopher Burns

Yes. shadcn for the front-end components, backed by an SDK that handles the state management. And something I forgot to mention that's actually a really big deal: if you have a cookie banner, GDPR law requires you to track every single consent. So every time someone accepts, you need to keep that as a record in a database.

01:05:14 - Anthony Campolo

This is kind of hilarious, because it essentially forces every company to keep detailed records on all of their users, which seems like the opposite of what people wanted.

01:05:24 - Christopher Burns

Yeah, and with an IP address that backs up the consent statement. This IP address consented. It's kind of backwards.

But you do need to hold that consent record. So that's what the next phase of the solution will be—storing those consent statements in a database.

But right now we're just talking about building your own shadcn registry to let other people copy and paste components into their codebases. As you see, you build out this registry system that has some...

01:06:19 - Anthony Campolo

We're on to bigger things, actually.

01:06:22 - Christopher Burns

Is that big enough?

01:06:23 - Anthony Campolo

One more.

01:06:25 - Christopher Burns

So you see you have this registry folder with a schema, and it pulls through each of the blocks into this unified schema. I actually took out the block because I was working on it, but let's show it on the official one. It's shadcn/ui—not shadchan. Let's find the actual official one.

01:07:17 - Anthony Campolo

I would just Google it. I never use GitHub search, it's always let me down honestly.

01:07:27 - Christopher Burns

Okay so here we go. Let's look at his repository. When we go into the www directory, it's the same structure where he has this registry file structure.

When we go to blocks, you'll see a JSON array that says what the block is: a sidebar, a description, what components it requires. Like an atomic structure.

01:08:04 - Anthony Campolo

This is really interesting. It reminds me of infrastructure as code for your UI.

01:08:09 - Christopher Burns

Yeah, exactly. And then what files, what the current path is, and then what path to target—i.e. put them in this specific location in their directory.

That all gets compiled into this repository that sits under the public folder. Someone can then use the CLI to fetch the components.

This is all looking great right now. The reason I say that is because I thought I had everything set up correctly to use the registry system, but I currently get an error on the SDK. He literally updated it yesterday, and he's updating the CLI today as well.

01:09:10 - Anthony Campolo

So coincidentally, you happen to be working on the exact edge case he just fixed.

01:09:15 - Christopher Burns

Yeah. And he's been building in, where is it?

01:09:22 - Anthony Campolo

You do have a talent for finding the specific way to break a really well-used project.

01:09:29 - Christopher Burns

He's been adding this build command. Look—yesterday he added a new registry build command. This is him abstracting his registry build system so you can build a registry faster, without having to maintain all of that code yourself.

So I can create a very standalone, smaller file structure and use his build command, instead of having all that same code duplicated in my front end. Really cool.

01:10:12 - Anthony Campolo

Scroll to the top of this. I want to see what he's using. I was curious about his CLI because I'm using Commander.js.

01:10:26 - Christopher Burns

I think...

01:10:27 - Anthony Campolo

Oh wait, he's using... wait, go back one. I think he is using Commander.

01:10:32 - Christopher Burns

Commander.

01:10:32 - Anthony Campolo

Yeah. Commander's awesome. AutoShow started as just a CLI even though it has a front end and server. So I've spent like a year building a very in-depth Commander.js CLI. It's awesome.

01:10:50 - Christopher Burns

I definitely respect that.

01:10:53 - Anthony Campolo

I recognized it as soon as I saw it. Name, description, program—he's using Commander.

01:11:01 - Christopher Burns

It's something really cool that I haven't used yet. Maybe there will be a need for a CLI on this project sooner or later, but we'll see.

So you can build your own repository system to copy code into your codebase. I'm pretty sure I implemented it during the exact days he was changing the spec, so it doesn't work. These things always happen to me. Why me?

But once he finishes, that will allow you to go into the components and easily copy them into your codebase.

01:11:57 - Anthony Campolo

Do all these integrations actually exist already, or are they work in progress?

01:12:02 - Christopher Burns

Let me show you some more of that in a second.

01:12:08 - Anthony Campolo

You already got a Laravel integration. Are you serious?

01:12:11 - Christopher Burns

That's just the code for how to install the components.

01:12:19 - Anthony Campolo

So you're really leaning in on what shadcn is giving you.

01:12:25 - Christopher Burns

Yeah. So you see here that if you wanted to install...

01:12:34 - Anthony Campolo

Oh, look at that. Found a bug.

01:12:37 - Christopher Burns

It just crashed my whole website. No—I'm joking. Let's just...

01:12:44 - Anthony Campolo

The website's like, no PHP for you.

01:12:49 - Christopher Burns

This was the day I was finally going to move over to PHP, and it just doesn't want me to. But basically, that's just the default components.

01:13:07 - Anthony Campolo

How did you create that animation on the top right now?

01:13:12 - Christopher Burns

That's using a video—a component that streams a video. It's actually a Magic UI template that I bought and started customizing.

01:13:32 - Anthony Campolo

That's cool. Very cool. Did you make the 3D design?

01:13:36 - Christopher Burns

No, definitely not. I have no idea how to do that.

So let's also take a step back and talk about documentation tools. I've looked through so many, and finding a good documentation tool is really hard.

01:14:01 - Christopher Burns

Something that looks really decent. This is actually Fumadocs. Have you heard of Fumadocs before?

01:14:12 - Anthony Campolo

I don't think so.

01:14:14 - Christopher Burns

Teach you something new. So this is Fumadocs.

01:14:24 - Anthony Campolo

The website looks literally identical to the shadcn website.

01:14:31 - Christopher Burns

Yeah, but it's not. I don't even think it has to be Next.js, but it's really cool because it has a few plugin systems.

01:14:50 - Anthony Campolo

Once you go into some of these, it makes sense to go into all of them because they're all being built with each other, right?

01:14:57 - Christopher Burns

Yeah.

01:14:58 - Anthony Campolo

So this thing is probably built with shadcn and I bet...

01:15:02 - Christopher Burns

Something slightly different. It's more homegrown, but it uses Tailwind.

01:15:09 - Anthony Campolo

But they all use Tailwind. And Next.js probably.

01:15:12 - Christopher Burns

Yeah. So if you have an OpenAPI spec, it's got an OpenAPI plugin. As we build the relay, that will be really useful.

01:15:28 - Anthony Campolo

When you build the GraphQL API.

01:15:30 - Christopher Burns

Don't talk to me about GraphQL. I love it, but I can't talk about it. Fumadocs is highly inspired by shadcn. So it's not quite shadcn, but...

01:15:43 - Anthony Campolo

So I was right.

01:15:45 - Christopher Burns

How we do it is we use MDX pages.

01:15:53 - Anthony Campolo

Okay.

01:15:53 - Christopher Burns

And then it renders through. As you can see, it's very simple—light, dark, right-to-left, CSS variables.

01:16:09 - Anthony Campolo

This is like Docusaurus, or the Astro Starlight docs page. I forget what it's called.

01:16:17 - Christopher Burns

Yeah. And it comes with some nice default components. I was actually going to show the progress on this one.

This is how it will work. It's not fully finished, but you see that you'll have this preview at the top showing the component plus the code.

01:16:50 - Anthony Campolo

A quick little render, like a CodeSandbox in the browser.

01:16:55 - Christopher Burns

And then it will have the install, the dependencies, basic usage, advanced usage, the props, and so on.

I still need to work out exactly how I'm going to structure it—three separate components or one component. It can get really complicated. But the point is making it as easy as possible to get this code into your codebase.

01:17:31 - Anthony Campolo

Honestly, man, I could use this for AutoShow because I am going to have an app that people are going to be using hopefully all over the world. And I have not even thought about solving this problem yet.

So if you were literally building a project right now that is meant to solve this, this is something I could actually use and dog food for you.

01:17:52 - Christopher Burns

What, as in installing...

01:17:55 - Anthony Campolo

I need a cookie thing. Like a...

01:17:58 - Christopher Burns

Cookie banner. Yeah, of course.

01:18:02 - Anthony Campolo

Yeah.

01:18:03 - Christopher Burns

Yeah, exactly. We all need them sooner or later. So we'll have the core—that's the brain of the operation—and we'll have the components. So yeah, that's a brief overview of what I've been building. Let me go back to the demo.

01:18:30 - Anthony Campolo

This is sweet. We should schedule another stream in a couple weeks where we try to install this in AutoShow. That would be super interesting.

01:18:39 - Christopher Burns

Yeah, I should have a beta out by then. As you see this working in Next.js, we can see—if I accept all... I think I've just crashed it. But if I accept all, you see I accepted all the consents.

Then if I refresh and click "Reject All," you see I've rejected all marketing. And obviously this is a lot of logic that gets hidden from the user.

01:19:22 - Anthony Campolo

Very snappy. Fast.

01:19:25 - Christopher Burns

Yeah. And what's really interesting is—

01:19:35 - Anthony Campolo

Wait. Hold on. Go back to the compliance thing.

01:19:40 - Anthony Campolo

So what's CCPA and GDPR? Those I know.

01:19:47 - Christopher Burns

CCPA is the California Consumer Privacy Act.

01:19:55 - Anthony Campolo

Right. I've heard of that. I'd just forgotten the acronym.

01:20:02 - Christopher Burns

And LGPD is the Brazilian General Data Protection Law.

01:20:07 - Anthony Campolo

Brazilian General Data Protection Law.

01:20:10 - Christopher Burns

Yeah. The whole goal is to keep it up to date with current laws, so we don't have to look at this as a sacrifice.

Why can't the boring stuff—legalities, compliance—be made so easy that it's almost invisible? So you think, "I'm going to install Google Analytics"? If you're installing Google Analytics, you need the measurement category turned on. When you track measurements, it does that automatically. So let me swap tabs and show you.

01:20:58 - Anthony Campolo

I can say for sure I would not have built in anything for Brazil if I were just creating my own thing for AutoShow. Without a tool like this, I would have looked at GDPR, maybe the California law too.

01:21:15 - Christopher Burns

And maybe pulled up a really rough cookie banner from somewhere. So we can see this is the MDX file and how it gets rendered out.

But if we want to pull through more marketing choices, that's where you can say, "Also pull through functionality" or "Pull through measurement." And then as soon as you save that—kind of annoying because I...

01:21:58 - Anthony Campolo

Are you working off multiple monitors right now?

01:22:00 - Christopher Burns

One ultrawide screen. I'm lucky. But then I lose my tab—like right now, where's my tab? Okay.

01:22:11 - Anthony Campolo

There. Now.

01:22:14 - Christopher Burns

So now when we pull up the local version, you'll see you have more of the options. Making it as easy as possible to track each functionality.

Some of the really cool ideas I have that I still need to see if I can actually implement—one of them I believe I had in the SDK or refactored out earlier. Yeah, refactored it out.

Let me show you how you would actually set this up. So say we're going to a blank docs demo.tsx. See? Already knows where I'm going.

One of the things we obviously want to do is conditionally block the render. So what you want to do is—I think it's not content info, it's... I'm challenging myself here because I've literally forgotten the code I wrote already.

We want "has consented."

01:24:12 - Christopher Burns

Let me pull this up, give you a demo.

01:24:16 - Anthony Campolo

Do you think you could wrap up in the next 5 to 10 minutes, Chris?

01:24:20 - Christopher Burns

Yeah, 100%. We're literally at the end.

01:24:23 - Anthony Campolo

Sorry. I just have to handle some stuff.

01:24:30 - Christopher Burns

It's currently called something different. There we go. So this is, for example, what we spoke about.

Say you have a script—just a quick marketing script that you put into your codebase. As soon as React renders it, Next.js is going to render that script, add it to the page, and start running it.

But what about conditionally blocking the render? You want to say—I can't find it right now, but—you want consents, and then you say things like "necessary". So what that will do is conditionally render this script only if "necessary" consent has been given. Pretty cool, right?

And I want to build that into the dev tool. Wherever you conditionally render something, we hold on to that knowledge so we can say, "Here's everything you're conditionally rendering—your PostHog script, your Intercom, your Crisp. And here's the ones that are not rendering."

So as you test your application with different levels of consent, you get full developer visibility at the same time. So yeah, that's been like a 90-minute overview of this project. I think it's really cool.

01:27:26 - Anthony Campolo

That's great. I think it's really cool. Now that you've explained it to me, it definitely makes total sense—what you built, what it will be for, why I would want to use it, and how I could even use it in my own projects.

You got much better at explaining your code—good job. I'm still going to say, I don't think "Better Events" makes sense as a name. I think that's going to confuse people. But that's just one person's opinion. You'll have to find out from others.

01:27:57 - Christopher Burns

To me, it's more a temporary name. I didn't want to get stuck thinking, "What's the perfect name?" instead of just building.

01:28:08 - Anthony Campolo

"Better Cookies" is the thing.

01:28:10 - Christopher Burns

I know, but as soon as you start doing the event relay, the back-end consent storage, you're going to have "Better Cookies, but also we've got an API and a ClickHouse database." See what I mean?

01:28:28 - Anthony Campolo

You're thinking too specifically about the technical meaning of cookies in the browser versus local storage. Most people, when they think cookies, think the cookie banner. They're not going to think of all cookies as implemented in the browser.

01:28:45 - Christopher Burns

Right, so rename it to Better...

01:28:51 - Anthony Campolo

Better Privacy.

01:28:52 - Christopher Burns

Better Consent.

01:28:54 - Anthony Campolo

"Better Consent." Yeah, I don't know about having the word "consent" in your thing, because people's minds go to weird places. At least mine does.

01:29:05 - Christopher Burns

Yeah. And that's the other thing—the tool can also be used for completely custom payloads, keeping track of other payloads. I have a few ideas and potential people interested in that as well.

So yeah, this is super early. We're at ground zero. And I'm still looking for another opportunity at the same time. I probably should be doing that more than building this out.

01:29:40 - Anthony Campolo

Hire this guy.

01:29:44 - Christopher Burns

I'm open for opportunities. But you know what, this could be just a side project. Am I open to GitHub contributions? Or it could go all the way and I turn it into a company one day. I just don't know yet. And that's what makes it really cool and interesting.

01:30:09 - Anthony Campolo

Yeah, I think it's cool that you're building something open source that anyone can use, and you might turn it into a product or a company. Because you did kind of the reverse with Everfund—you built a company and a product, then slowly open-sourced pieces of it. But the whole platform was never really open source.

Didn't you open source something right at the end, in case people wanted to use Everfund?

01:30:33 - Christopher Burns

No, we didn't really get the buy-in from our investors to do it.

01:30:40 - Anthony Campolo

There's no reason to fund something that's not going to have any return.

01:30:44 - Christopher Burns

I've been thinking about another company in the nonprofit space, or a side project. And a lot of it ties into this solution as well—not that I'm killing two birds with one stone, but it's like, my consent solution over here could pull into another project over there and cut 50% of the work.

But it's a massive thing about verticals versus horizontals. What I'm building here is a horizontal. Everfund was a vertical in a very specific area. I'm really excited to build this in public, talk about it, get contributors. It's lots of fun, and I'm happy to speak to anyone about it.

01:31:36 - Anthony Campolo

This is awesome. I think we'll start wrapping up here, but I would definitely love to do another stream and try to integrate this into my own project.

So let people know your socials. I think we dropped all the Better Events links already, but just one more time—if people want to check this out, it's Better Events, better-events.dev.

01:32:00 - Christopher Burns

That's just a $14 domain. I'm not sold on it right now.

01:32:06 - Anthony Campolo

It's actually a great domain name, and it's a great name in general, but I think "events" as a word is overloaded.

01:32:13 - Christopher Burns

Also, because it doesn't have the event system in yet, it's like a two-part problem.

01:32:21 - Anthony Campolo

So Chris, where can people find you?

01:32:26 - Christopher Burns

ChrisBurns.com. You'll find all my social links on there.

01:32:32 - Anthony Campolo

"SF bound"—that's in your description.

01:32:36 - Christopher Burns

You've got a dream, you've got to put big things out there and say them. If I never say, "This is what I want to do next," I will never achieve it. It's something I've set my eyes on.

I'm going to work hard in a company, or work harder building my own things and scaling them. No matter where it goes, it's going to be really exciting. And I'm sure there are tons of things we can speak about more—APIs, databases, some really fun things we're going to be building. Yeah, Better Events.

01:33:20 - Anthony Campolo

You're a manifestor. It's one of the reasons I love you. Super glad we could reconnect and see what you're doing. We'll be in touch for sure.

01:33:29 - Christopher Burns

Yeah, I love hanging out with everyone. Thanks. Catch you soon.

01:33:33 - Anthony Campolo

Bye, everyone. We'll catch you next time.

01:33:36 - Christopher Burns

Bye.