Ben: Hello and welcome to PodRocket. Today, I'm here with Christopher Burns who's a returning guest on PodRocket. So super excited to have him back on the podcast. Christopher is the co-host of the FSJam podcast and he's also the CEO of Everfund. How are you, Chris? Christopher Burns: Thank you for having me on. Just before Christmas, before we all split up and disappear. No matter where you are, we all are in that hectic rush right now of trying to prepare everything for Christmas and making sure nothing sets on fire while you disappear for a week. Ben: Certainly know that feeling, so really glad you made some time out of your schedule to come and talk to us. Today, it'd be great to learn a bit about Everfund. Could you give me an intro to what you're building? Christopher Burns: Yes. So Everfund is ultimately making donations and nonprofits easier. We're basically a plug and play donation solution allowing you to completely bypass Stripe and all them other things that come with it and just quickly implement Everfund's plug and play features. Yes, it just works. Ben: Got it. Typically, if I were building a website or any kind of digital product that needed to accept money, I would think Stripe first. No affiliation with Stripe, but I think we all know they have a great product. I guess I would typically think Stripe is pretty easy to integrate. So how does Everfund improve upon the experience of using Stripe to collect payments? Christopher Burns: Yes, of course. I'm not going to come on here and say Stripe is not a great product. We use Stripe internally. It's actually the backbone of Everfund. We use Stripe Connect Custom, so we are built on top of that. When you think of Stripe, you think of the other big companies that use it like Shopify, like Uber. You don't think of Stripe. You think of, "Okay, so that's e-commerce. They're built on top." Yes, Stripe handles the payment, but all that nuance that comes with e-commerce or booking a taxi, that's all handled by them said companies. Christopher Burns: So what Everfund is, is we've targeted the market at specifically nonprofit donations. It's a really underserved area. What we've seen over the period of creating the company is that we tend to get an agency that gets hired... We get a frontend developer or an agency hired by a nonprofit to go build a website. I go, "Great. I need to go build a website," and then say, "Oh, by the way, it needs to have a way for supporters to donate to our charity because we're a nonprofit. Christopher Burns: So then they go, "Okay, so that really simple website..." Normally, a WordPress website and if they're advance these days, it's a Gatsby website or a Next website has now turned into this bigger thing because it now involves moving parts, such as a payment. And then, when we look at the payment side, you go, "Okay..." As a developer, you are thinking in your head and you go, "Payments equal Stripe." Really, really easy. You think, "Great. Stripe's going to get me a hundred percent of the way there." Christopher Burns: Actually, when it does, there's a lot of nuances and what I like to say is a hidden dip. As in, there's so much more than just the payment that comes to a donation, especially if you're in countries like the UK, where you've got GDPR to worry about, some marketing preferences. You then also have gift aid - that's a tax scheme, so the charity can claim 25% more. Verifying the address. Christopher Burns: All these things that the developer could go, "First up, I'm going to implement Stripe." But then, these are all the other things that they've got to worry about on top of that. To the point is that then they're running a whole microservice that is a database, an API, address verifier. All these things... What the charity wanted in the day was a website that was cheap and easy to maintain. Christopher Burns: Building a whole microservice for a donation system... Obviously, we've done it and it takes a lot of time and a lot of nuances. So what we've been doing is lowering that barrier to entry. So the frontend developer can just focus on what they're used to - HTML, CSS, React, if they want to go that far. And then, quickly, easily implement, Everfund - a literal plug and play solution, four lines of code and that's it. When that button gets clicked or that event handler gets triggered, it will pop up a model and we'll handle the complete donation process. And then, tell the developer when it's done. And then, they can carry on doing whatever they need to do. Christopher Burns: You never leave the website, you do not risk anything. It's always up to date. To a frontend developer who obviously is not skilled in payments and all these other things to think about, it really removes the risk, the barrier to entry, and actually the knowledge of knowing that what they've implemented will be continually supported no matter what changes in terms of payment regulations, because that's another thing that completely changes year on year, country by country. Ben: Got it. Basically, there's all these complications on top of just the actual collection of payments that are specific to the nonprofit space and you abstract all that away and make it super easy for nonprofits to just collect payments and- Christopher Burns: Exactly. Ben: Handle all the other data collection and compliance and whatnot. Christopher Burns: Exactly. When we look at these nonprofits, in terms of like categories... In the latest Jamstack report, nonprofits were the eighth biggest category where there are 9% shareholder. So there's a lot of nonprofit websites being built in the Jamstack area. What's important about the Jamstack is you have no services, you have no backend. So you need to just offload it to somebody else to handle for you. Christopher Burns: The biggest thing, like I said is that knowledge transfer has been massively reduced where the developer... Instead of thinking, adding the donation system is going to take weeks. It now takes minutes because it's done for them. Integrate, and then they just hand it off to the charity to start dealing with the rest of time. Ben: Are the complications associated with collecting payments in a nonprofit different in different countries? I imagine with taxes and just nonprofit status and those things, does that change around the world? Do you support nonprofits in different regions? Or how are you thinking about that? Christopher Burns: Yes, so currently we're almost at post MVP. We're at the end of our MVP. While we've been building our MVP, we have been UK-only because that's where we're based and that's where we have all our knowledge with nonprofits. As we come to early next year, we'll be introducing a complete rollout of multi-country support onto the platform. Obviously, that's American charities, that's Canadian charities, Irish charities for us. Christopher Burns: With that, we'll be handling all the nuances that comes with that, so that is obviously verifying the charities. The biggest thing is not just single payments. We're so used to a single payment, but what about recurring payments? A lot of countries have different models of recurring payments. Christopher Burns: In the UK, we have something called Bacs, Direct Debits. When in America, it's just standard transfers, I think it is or I forgot the actual word. But it's about doing all them nuances for each country, making sure that every country that's supported is a gold standard and not losing any features. Also, making sure if there's tax schemes available, that they are implemented so the donors and the charities can gain more money. Christopher Burns: Because at the end of the day, one of the biggest things about Everfund is that we're trying to reduce the cost to the charity, to let them focus on the fundraising. Because we all know building websites is a very expensive endeavor for so many businesses. Especially when you think of how much time it takes to build donation systems, add that developer time on, 50 hours at $50 an hour, that's $5,000 that instantly can be moved to something else. So it's really focusing on what they're good at, what we can handle for them, and really move it forward. Ben: So curious to learn a bit more about the tech stack that powers Everfund. You mentioned Stripe is one of the core pieces of infrastructure. What other technologies are you leveraging and maybe take me through some of the decision making that went into why you chose each layer of the stack. Christopher Burns: Yes, of course. So it's first best to talk about where Everfund came from, to understand where the technology is today because it's been an evolution. Me and my co-founder, we graduated university in the UK four years ago now. We started a company. It was actually a loyalty app, React Native. We built it all and we actually never released it. We pivoted to NFC technology. When we was working on NFC technology, we came across the biggest nonprofit in our area that needed help in this area. So we started helping them with NFC technology. Christopher Burns: That's when we then moved into NFC payments, so taking QR code and NFC payments before the pandemic even happened and everyone learned how to actually use a QR code. So over that time, we moved from building this one-off bespoke payment solution through QR code and NFC, to a more broad platform that can be implemented for a URL or a website or a QR code or a NFC tech or a tweet. Christopher Burns: So how did we get here from there, was one very ugly rebuild of the entire platform and two betting on the right technology when it came time to rebuild the sinking ship. When it was time to rebuild the sinking ship, it was time to pick RedwoodJS. We have been a very early adopter on RedwoodJS and saw it from 0.8 to RC.1.4. now, I think it is. It's really helped keep up momentum on the platform all the way through. We also used your standard technologies like NextJS, and GraphQL, TypeScript, styled-components - previously Tailwind. All your typical blazing, bleeding edge tech stack that we all love these days. Ben: So you mentioned you rebuilt the platform. Can you tell me a bit about what led to that decision to do a rebuild and how you chose, going into the rebuild, how you made different decisions in the first time around based on your learnings. Christopher Burns: Yes, of course. As a first time founder... I would say now looking back, still quite youthful in the industry. Well, I've been programming JavaScript since 15 or so. Building an actual full stack application, this was my first whole go around. Everybody obviously says, "I use these tools." So when we built that MVP, like I said, for that original charity, we used Gatsby 2. We used Happy on the backend. Prisma 1 and MongoDB. We just glued it all together ourself. That was like two different Gatsby applications - one to run our checkout logic and one to run our dashboard. We glued this whole thing together, we got it out, and it worked. It was like, "Yay" "People are making money off of this" "It's working. Donations are coming through." Christopher Burns: And then, it got to a point very, very fast where it's like, "Okay, we need to fully rethink something" and the whole system just fell apart as fast as possible to a point where we begrudgingly say that, "There was no choice but to rebuild as it..." It's always that meme where there's two buttons and it's like "Rebuild the whole platform" or "Just fix the bugs". It's this thing of like, new technologies were coming out. This was at the time Redwood was starting to be picked up. Prisma 1... I think the biggest force here would actually be the migration from Prisma 1 to Prisma 2. Christopher Burns: So Prisma 1 was obviously deprecated very fast as soon as Prisma 2 became widely available. So we had to do a full migration over, but we had none of the tools available to move it over seamlessly. So that's when obviously RedwoodJS came about and they had these, you could say, talking points of fully maintainable into the future, GraphQL support straight out of the box, authorization support out of the box. Christopher Burns: All these things that I were building myself, I saw in RedwoodJS that they all had been handled together. Instead of me building the glue, the glue was already built. The biggest thing that it came with was that it wasn't just me making all the decisions, a lot of the decisions about how things should be structured, laid out, loading cells, success cells have been done for me. So it took that position of, "I know this is my first rodeo and I'm just fumbling through it" to "I'm sure what I've built is good enough", if that makes sense. It's secure enough, it's built good enough, it does what it needs to do, and it will continue to do it into the future past adding more and more features. Christopher Burns: We took a really early bet on RedwoodJS and that bet has came out successful. Going into the 1.0, our application still works. It's not broken. The migrations have worked all the way through. So it's really, really successful that we rebuilt it in RedwoodJS. I think the biggest thing that we got burned by all of it was actually Gatsby 2 because the original platform was built off of Gatsby 2. It went through this moment of, I would say, crisis where NextJS came out with a lot of features very fast, that very much shined a light on how bad Gatsby 2 was at that moment. Christopher Burns: I dealt with this problem in multiple situations and multiple sites that I was working on as we was an agency moving over. And so, we rebuilt our checkout logic in NextJS. So our donation checkouts are all built on NextJS. And then, our dashboard and our GraphQL API are built in Redwood. The Redwood side connects with the NextJS side through GraphQL, meaning obviously it's an open interface. It has worked really, really well to this point with not many problems so inherent. The rebuild, you could say, was a necessary tick as it did work. But yes, I wish I never made the mistakes in the first phase, meaning that you had to rebuild it. But sometimes, you can't see that far in front until you've passed that barrier. Ben: Yes. I mean, hindsight's always 20/20, right? It's easy looking back to see the mistakes you made, but it also sounds like, the first version you made progress, it helped you... It was quick, it was easy. And so, sometimes it's better to do something quick and make progress. And then, once you know more, do the rebuild at that point. Christopher Burns: Exactly. We only rebuilt it once we knew that it was a viable business and a viable product that we could expand to other charities. Because as you know, you don't want to spend all your time making a perfect product for nobody to use it - nobody to even be interested in using it. It's that hard balance of, "I'll just add in another feature and then people will start using it and it'll be magical" and that thing of actually marketing it and spending a lot of time on them sales leads and all that other stuff. Ben: On that subject, curious. How are you approaching user or customer acquisition? How are you thinking about your early marketing sales motions? Christopher Burns: Yes. This is actually a really interesting thought because when we see nonprofits, they're not... We class them as in three categories. You've got your giant ones. No matter what country, you'll know them. Like for example, Cancer UK is the most giantest one in the UK, as in it does cancer, Oxfam, Barnardo's. These are UK charities, but you know... Boys & Girls Club, I think is a massive one in American... All that other, all that ones. They have developers in-house, they have teems of money to spend to make more money. So they're all handled, they probably just get their developers in-house to do everything. Christopher Burns: Then, you got your middle sized that they're decent enough, they're big enough, and they'll hire an agency. So the agency will do whatever they want because they're paying. And then, you have the actual small to medium. The small to medium are the ones that literally... A volunteer has built them a WordPress website in their free time and is not going very well. But at the end of the day, it gets the job done. When someone searches that charity's name on the internet, 99% of the time, the website comes up. So we've looked at it from two ways as in, we can go directly straight to the charities. But if the charity already has a solution built in, no matter if they're happy or unhappy with it, it's normally a hard sale because... Why are they going to rip out something that works, they've already ticked the box. I can take a payment. No matter if it's the worst payment in the world or the best payment in the world, to them, it takes a donation. Christopher Burns: And then, obviously you have the small to medium that they either have nothing or they use another third-party service that doesn't do what they need. The biggest ones for example, are in the UK... Canada, is called JustGiving. It's more of a fundraising type website where somebody will say, "I'm going to run a marathon, donate me money." That's not really the right use case of a donating checkout. Christopher Burns: Donation checkouts are really specific thing to say, "I want to support this charity. How do I get it done as fast as possible?" So going to the donation checkout in two ways, one of them is going directly to the charity, like I was just saying, and basically saying, "We're going to take out the old one, implement this new one." Fundraising goes up because now you have a modern donation solution. And then, the second way that we are actually spending more time as of late, is actually going directly to developers. Christopher Burns: Because at the end of the day, when we look at them middle sized charities and even still the small ones with volunteers, you see that they've been given a task. I need to implement a donation solution. As we conclude to in the beginning, a lot of them don't have that knowledge. They might know of Stripe, but actually implement Stripe is still a big deal even with all of its documentation. So going directly to developers at the beginning of a cycle... So it's a new website or an update to the website or a volunteer building a website and saying, "Look, we know you're going to need this. We're going to make it easy for you and we are going to make it so simple that you can watch a YouTube video and understand how to implement it on WordPress." Christopher Burns: We spent a lot of time actually building a WordPress plugin of Everfund that is literally... Install it from WordPress and it just works. You put one line of code in your theme where you want the button to be clicked and it just works. That is massive to them people that don't have the money to take a developer on even part-time or contractual, but they just need a way to take donations. That's where we're going bottoms up to some extent. Christopher Burns: A lot of our business is in this area. As we say, if they have developers, they've already ticked the box and going, "I'm going to Stripe straight off. I'm going to build all the nuances my myself." Because they will, they're big enough to. But the smaller ones and the medium sized ones, that's where they really need the best of today's technologies. Jamstack, perfect example. Like I said, most websites are still built on WordPress for nonprofits. When actually they will be better off using... A Jamstack technology will be cheaper and necessarily less to maintain, but getting the required knowledge is obviously a big thing. Ben: How do you charge? Is it based on a percentage of spend to the platform like Stripe or is it a different model? Christopher Burns: Yes, of course. So Stripe handles a payment transaction fee. So that's normally... Depending on your country, about 1.2% - in the UK, I think that is. So what we do is we believe the services we are providing the charity is slightly more than just the donation. So we have a flat fee of 3% on the actual donation, but we also have a feature that allows the supporter to transparently know how much it's going to cost to handle this donation and we allow the donator to cover that. 97% of donors actually cover that, so the charity doesn't pay that fee. Christopher Burns: But then, we actually have a platform fee on the tools, our donation links, and our donation widgets only because we think we're going to be increasing value tenfold. But like I said, we do have generous free tiers that no matter if the charity is small to large, they can get going really, really cheaply and easily and most of the time, hardly pay a penny. Ben: Got it. So when I go to donate to a charity that uses Everfund... Let's say, I want to donate a hundred dollars. It tells me, "Oh, it's going to cost $3 in transaction fees. Do you want to donate a $103 to cover that?" Is that- Christopher Burns: Exactly. Ben: 97% of people say yes to that? Christopher Burns: Exactly. So it actually works out to, the charity only ever pays like 0.365% of transaction fees. So while there is yes, a 3% transaction fee, when we be transparent with the donators, they know that they're giving money to help the charity by saying to them, "Look, did you know that not all that hundred dollars will actually get to the charity?" 97% of the time, donators just want to choose to cover the fee, so we give that tool to help them. Christopher Burns: Like you said, it is very transparent where we'll say, "You pay $103. A hundred dollars will go to the charity, $3 will go to the processing fees. Thank you very much." Ben: I'm curious to hear a bit about your future roadmap. You mentioned you're ending... I think you said you're at the tail end of your MVP period, sounds like you have proven out that there is a viable product and market. So what does the future look like for the product? And then, we can talk about the future for the business and growth of the company. Christopher Burns: Of course. So something that I've hardly spoken about is actually, we currently have two products that when we say we take donations, it actually falls into two products. The first one is a no-code solution that we call donation links. So obviously, the URL is a parameter. That's what you're going to share on Twitter, on Facebook. You generate that on the dashboard, you share to Facebook. Donation system, ready to go. Christopher Burns: And then, we have our donation widget that's this a low code version. So obviously, you put the code in the click handler and the donation can be taken from a model. Actually when we've been speaking to developers and doing interviews, we've actually found out while the donation widget is great - 90% of the solution. But to that top 5% that really like it customized, we actually want to take a step further. We actually want to make the headless donation checkout system. Christopher Burns: We're going to be building a version of our checkout that is completely headless, meaning that the end developer can have the full knowledge and functionality of Everfund's donation systems with a full custom UI and also allowing more nuances of the platform because there's always nuances when it comes to charities. Sometimes you're donating to a specific person or a remembrance or an event. All these nuances, we will be able to handle better in this complete custom UI. So that's actually where we're going is we've tackled a no-code, a low code, and next we're going to be tackling a headless code solution. Ben: And so that no-code, is that like a hosted link where you just follow a link, you have a hosted page and you could donate and is hosted on your infrastructure? Christopher Burns: Exactly. Yes. Inside the dashboard, the nonprofit signs up for Everfund. And then, they see a section called links and they say, "I'm going to generate a link." We say, "What are you going to do with that link?" And we say, "I'm going to put it on Twitter." So you are already directing them to not use the same thing for everything. So they say, "Okay, I'm going to put this donation link on Twitter for this campaign," "I'm going to put this donation link on Facebook for this campaign." And then, they'll instantly be able to see which link actually had made more money for them, giving them more insights into where to spend more money in terms of marketing budgets, in terms of advertising budgets. That's actually the no-code solution. Christopher Burns: The no-code, low code, they're all interchangeable words. But when I say no-code, I mean, this is just a URL. Obviously, you can add in extra parameters to customize it, but that's our no-code solution. Obviously, our low code is like this, what we call the Everfund SDK. So it's a really simple script to basically have that no-code solution embedded into our model fully built. Ben: I'm curious for the headless version. How did you think about the different options there? I imagine one option is just like the ability to do a lot of customization of the UI of the low code. Maybe you provide a React component and it's stylable and you have customizable feel. It sounds like you're... Or correct me if I'm wrong, it sounds like you're doing more of an API approach where it's really like, "Here, I provide APIs and it's up to developers to just build whatever they want on top of that." Ben: So how did you think about the different range of options and providing something that's extensible, but also easy to use and easier to build on? Christopher Burns: Exactly. So I think it's really looking at what use case a developer has and how far they want to go with it. Because as I said about the three tiers of charities, the bottom tier will just be happy to have a link that they can give someone to take a donation and then you move up. So then, they expect on their website, no matter how good or bad it is, just a donation checkout that they can actually get donation through. And then when you look at that biggest size, that's obviously where it comes to loads of nuances. Christopher Burns: So in terms of customizability, we like to say that our middle one, that will be the donation widget, will allow it to be customizationable enough where you believe the checkout flow that we've defined is good for your charity. Obviously, we have customization in our dashboard of like changing the color, changing the image, changing the logo. All these things can be easily customized, even with some CSS. But if you define that you want a completely different donation checkout flow, you want something completely different, something that we haven't even thought of, but you know it involves a donation and extra logic. That's when you know you're probably going to be running another microservice yourself. So it's extra functionality that you're expecting Everfund to slot into. Christopher Burns: So that's really where the headless solution will be. Is that thing of knowing that the donation widget will tackle 97% of all use cases. But really when there's a lot of nuances, that's when you will have to go the step further and will want something completely headless where we are just going to handle taking the payment and making sure everything works. It's up to you, the developer to make sure it looks correct, it works correct. Christopher Burns: That's really where Stripe is today. You look at Stripe and Stripe has payment links, through a URL, through that dashboard. They have a redirect to their checkout. And then, they obviously have their completely headless API mode that most people use. The thing is like we were saying back to the beginning, why not just use Stripe? Well, Stripe is just the payment. Stripe checkout is technically a competitor to our donation links. They can be both used to take a donation, but if you talk about all the nuances that go around a payment, that's where our tool is specifically arranged for nonprofits. Ben: So we talked earlier a bit about... You're obviously an adopter of a bunch of bleeding edge frontend technologies and you have a podcast to talk about those things. So curious from your perspective... We're just about to cross into 2022, so what are you most excited about in the next year in the world of frontend? Christopher Burns: Yes. I think we are going into the most interesting year yet and it's going to be one of the most decisive years that I think we're going to come across in a while. Obviously, I wrote my own podcast with Anthony about this and we've had so many guests on that I've been able to put a really good formulated opinion on this. I think what we're going to see is the year of abstractions, even further to where we currently are. As you said, I've used a lot of bleeding edge technologies, but that's only because the abstractions that they've given me, I've had to risk early, early technology. But the reward has been the amount of time and development that we've had on Everfund has been incredible for one developer. Christopher Burns: We've been bootstrapped to this point, we haven't had any other developers. The whole system has been built by just me. These bleeding edge technologies have allowed me to move this fast with the caveat of, they can break once in a while or completely require you to refactor them depending on the tool. So what do I think we're going to see for 2022? I think we're going to see a really good paid offering from people like Prisma who are obviously building everybody's ORMs. I think we're going to see PlanetScale massively increase in adoption rates. I think we're going to see React become a smaller thing actually. I think we're going to see Svelte and Vue get more of the limelight in the coming year. I actually think we're going to see Redwood hit 1.0 properly, a fully released. Blitz, obviously a companion framework will hopefully get to 1.0 as well. Christopher Burns: Hopefully, we'll see the release of even more dev tools that we've not heard of yet and we know soon as we hit see them, we'll want to use them. The best one that comes to my mind is Snapper - a tool to allow developers to copy their live database locally and take out all the redacted information. So you are basically working with live data with no personal information. Christopher Burns: All these tools, they've come about in the last year, but we're going to see our mass adoption, I think, in the next year. Hence, Jamstack as a whole getting even bigger, especially with Netlify and Vercel currently taking their next rounds of funding. Also all the acquisitions Vercel has done in that space. I think this space is only going to get hotter faster and we're going to see a lot of innovation in the next 12 months. It's going to be explosive, I can't wait. Ben: I'm curious. One thing you said there stuck out to me, which is that you think this year React is... Maybe not that React will get less popular, but Vue and Svelte and other Vue layer frameworks or Vue libraries, whatever you want to call them, will grow in popularity. I'm curious, what leads you to that conclusion? Christopher Burns: What leads me to that conclusion? So when I built the Everfund SDK, obviously I'm a React kid. I've used React for a long time. I also built a demo in Svelte, in Slinkity, in Vue, and got to use these other languages that everyone keeps talking about. When I used the Vue version and the Svelte version, obviously these things, we could talk about the nuances of all the different ones for a long time, but the time it took to simply build what I needed was a lot, lot lower in Svelte and Vue compared to React. I think when you pair that with an ORM layer, an API layer like Redwood is doing, and you allow that decoupling of a full API service with the authorization built into it, what Svelte kit is doing, and other frameworks that we're seeing pop up all the time, we're going to see this really big gap close where you say, "I can only do everything I need with React because React has good Prisma support, good Stripe support, good everything support". Christopher Burns: And you're going to see, "What about Svelte?" It's going to take off massively in the next year where it's not just going to be that website layer, it's going to be that whole "front to back, I can build a full startup with this" and I think we're only in the early years still. Prisma 2, I think was the big, you could say, the big bang event that really set everything off, making it easy. I think it's going to continue to grow and become easier and easier to build a full stack application, easier and faster. Ben: Awesome. Well, Chris, it's been awesome having you on the show and it's been great learning about Everfund. We will put links to Everfund in the episode description for anyone out there. We'll also put a link to FSJam in case anyone wants to check out your podcast. But yes, thanks so much for joining us. Christopher Burns: Thank you for having me on. I really enjoyed being on the crossover episode as well. This is actually the first podcast I've ever done that's not my own podcast. Ben: Oh wow. Christopher Burns: You can have that accolade. It's like, I've done what? 60 episodes of my own podcast. I've never been on anyone else's podcast. So there you go. Yes. It's kind of crazy to think about it like that. Ben: Yes. Well, this is your second episode. We'd welcome you back for future episodes. So hopefully we have a chance to speak again. Christopher Burns: Thank you so much. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me even though that's not a popular option. It's Brian@logrocket.