Ep. #107, Empowering Nonprofits with Christopher Burns of Everfund

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Christopher Burns from Everfund. What's up, Chris?

Christopher Burns: Hey, thank you for having me. I've been a host on so many podcasts, episodes of my own on FSJam, I feel like I need to get out there and start being a guest on other people's podcasts.

Brian: Yeah. Well, I appreciate you connecting. We've been connected at least for six plus months. You know it's funny, because I was actually on your podcast longer than that so we were connected a long time ago. Do you quickly want to share what FSJam is and what the goal is over there?

Christopher: Yeah, of course. We've seen the evolution of the JAMStack, starting out from the days of Gatsby and Hugo and Jekyll and all these things, to really this evolution where people are building full stack applications on the JAMStack. So that's a backend, a frontend, all in this decoupled manner, and we saw some frameworks arise out of this movement, Redwood JS, at the time BisonJS, Blitz.

Me and Anthony came together and we started discussing, "What is the future of the JAMStack looking like? And it's not just static websites. It's how do full stack applications come into it? And how are they different to normal JAMStack websites?" Something you would compile down to standard HTML and ship to clients. About a year and a half now we've been doing it, we've had so many guests on, from Tom Preston-Werner to Matt Biilmann, all the way to Mishko at Quick, so we really saw a massive breadth of knowledge.

One of the bigger things we try to get from it, as all podcasts, is that you meet the people that are making these really cool projects and understand why they're making them and how they could matter in the future of the JavaScript ecosystem.

Brian: Perfect. Yeah. Well, hopefully folks will check that out. I didn't have you on to talk about FSJam but I felt like there were some space there that folks could go add it to their podcast feed. I actually wanted you to talk about Everfund and the project you're currently working on currently in the JAMStack. Can you give us the quick, elevator pitch on Everfund?

Christopher: Yeah, of course.

At Everfund we're lowering the bar for developers to enable non profits to help them adapt to digitalization and updating them with modern web technologies. Building powerful donation systems, marketing and operations, using headless and low code tools, and gaining that developer control back in that hands of the developer where they can build a whole solution without having to worry about the server and building from scratch.

Brian: Excellent. Yeah, this is not only an admirable cause for helping out non profits, but it's pretty common for nonprofits to get stuck into... Actually this was a story up on my other podcast, I chatted with a nonprofit who wanted to build a website and they went to a bunch of consultants in agencies and say, "Okay, how much?" And it was always out of reach for them because working with the agency is going to cost more money, nonprofits historically just don't make a profit so they don't have a lot of money to spend on this problem.

But that said, he ended up learning how to code himself and building his own solutions because WordPress and everything else wasn't cutting it for what he was trying to accomplish. So he ended up learning NextJS from the bottom up. I'm blanking on the name of the project but I'll mention it later in my picks. But I mention that because I don't think everybody who runs a nonprofit should also learn how to code and also the folks who write code to support nonprofits shouldn't also be handing over Kubernetes infrastructure to deploy or setup custom Stripe implementations to take payments or donations. So from my understanding of Everfund, it fits into that gap so people can just pick off the shelf.

Christopher: Yeah, of course. As a developer, we get so mind-complex when it comes to technologies, "Oh, we should be using the cutting edge, NextJS over Gatsby2."

We talk about that performance and that bleeding edge of technology, and when we speak to most nonprofits, they're way behind the tech times. They're still using WordPress as the default, they're still going to agencies that I wouldn't say are giving them the worst experience, but they're giving them an experience they understand because they're very limited on the technical knowledge.

This is one of the biggest things we're trying to tackle with Everfund, is giving the developers all of that power they need to create an amazing experience while giving that non profit a dashboard they can understand. To us, when we think of things like Open Graph images, we instantly know, "Oh, that's a thing that will show on Facebook and Twitter when you share a link."

But to a nonprofit they're like, "What is that?" And you don't want them to have to Google it, so you start explaining it in language they understand like, "This image will display on Facebook," and then they understand it. So it's about giving the right technology with just the right amount of power to the right people and then what we see is the turnover goes smaller, and we see an increase in donations just from what we've rolled out so far.

Brian: Excellent. So I guess my next question is what have you rolled out so far? What does the product look like today?

Christopher: Of course. We started out really quite humble as an agency that was playing around with NFC and QR code technology, pre pandemic. We built something for one of our local charities, NGOs in the UK, and we really saw this massive gap of taking donations in the real world. That's when built out our MVP, and our MVP has evolved from there, for sure. But its main concepts are a dashboard the charity understands and knows how to use, and a no code solution that can be shared as almost like a link generator, like Bit.ly on Facebook, Twitter, to easily make buckets of donations where they can easily understand, "This money came from Facebook, this money came from Twitter."

And an embeddable, no code solution, low code solution to put into their WordPress websites, to put into their Jamstack websites, and they're the tools that we have today. We've just finished rolling out beta to our international support, so we're rolling out more features when it comes to US charities and more in the coming months.

Brian: Okay, excellent. I see a lot of these no code and low code solutions and I'm very intrigued. I'm at a position where I don't write a ton of code, I'm not writing full-time development work today so when I go to build a new solution or a new tool, I'm always looking to pick up stuff off the shelf or hopefully I've already built out the design system that I can just pick and choose what I'm trying to accomplish. So I'm curious, with Everfund, how does this connect? Am I expected to spin up an entire NextJS app or can I embed this into my web flow or et cetera?

Christopher: Yeah, of course you can embed it into WebFlow, we've even got a WordPress plugin to make it even easier. We've got a script hosted on a CDN, and literally we put the snippets onto our doc saying, "This is how to implement it into a React app, this is how to implement it into a View app." We really try to keep it as lightweight as possible in terms of the actual code on the snippet, so it really does load fast and hopefully not affect your Lighthouse scores.

Brian: Okay, excellent. Yeah, and I'm curious, we didn't actually go into too much detail of your background as well. I'm curious, you mentioned agency, but what got you to this point in your career to say, "You know what? Let's start a startup"?

Christopher: Yeah, this is actually a really interesting question because I feel like I have a very unique perspective to a certain extent because I'm from the UK and not many people decide, "I'm going to make a company as soon as I leave college/university." Me and my business co-founder, we started just rolling, we left university, started on our first idea and we just kept going and going. It was that thing of like--Loads of other people were like, "That's admirable what you're doing."

And it's like five years later and we're still holding on and still not got a real job yet. When I say a real job, I mean like you leave university, you go work at a big company then decide what you want to do with your life. With that, I've evolved my technology skills over time. During university I knew a lot of PHP and since university I learned React Native, then evolved into React, and learnt so much more about JavaScript ever since.

Brian: Excellent. Yeah, your product is targeted towards nonprofits, so I'm curious how do you source users at this point? Do you have a connection already, an organic connection to nonprofits to make this work?

Christopher: Yeah. The nonprofit signs up to our system and then they can start using it. But what we've found is agencies are a really big player for Everfund because when a nonprofit comes to an agency and say, "I need a website, I need a donation solution, I need all these things," an agency normally has to work out what their budget is and what they can afford, and what they have to cut out or do differently to get it into their means. When it comes to Everfund, before Everfund they would have to build a whole Stripe integration themselves.

So that's front to back, Stripe, direct debits, monthly payments, single payments, GDPR settings, all this stuff as you know. As soon as you go to start building these things, massive complexities start being added. What about authentication? Two factor support for payments? So we handle all of this stuff by default, meaning when that agency says, "You need a donation system, we would charge $5,000 to build that ourself or we'll just use Everfund because that's $200 because it's so much easier to implement." And then they're joined onto this platform.

Brian: Okay, excellent. Yeah. As far as Everfund goes, I know personally because I've worked with Stripe directly. But my question to you is why not use Stripe?

Christopher: Of course. I have this love and hate relationship with Stripe. I absolutely love it and I feel like a lot of people really do enjoy it, but you have to look at the breadth of the knowledge of Stripe they've used. A lot of people make single payments and that's it. They may dabble into billing, they may dabble into other things. But where the true complexity is with Stripe Connect, and Stripe Connect, Stripe Connect Custom, is when you're using all of Stripe's interfaces in a white labeled solution.

So that's what we do at Everfund, the end user is creating a Stripe account but then we are managing Stripe completely for them. What I find here is that there's a lot of knowledge and a lot of complexities that come with regulation, updates to standards, test mode, live mode. The biggest thing of it all is actually having to host a server. When we speak about the JAMstack, in 2020, last year's JAMstack survey, 9% of websites on the JAMstack were nonprofit websites.

So that means if they want payment infrastructure, then they're going to have to host a server because when it comes to taking payments, it's a two side authentication method with the server and the client. So that's something that we remove with using Everfund, and our headless SDK that we're building, it's that you won't have to run any server yourself.

Then when it comes to all of that logic, all of that donation logic, all of that marketing logic, we believe it's so much more than just a payment. It's exactly the same when it comes to eCommerce, it's so much easier to just pay for a product, but what about the shipping of the product? How is it going to get from A to B? Reviews? Returns? Refunds? All of these things build into this massive complex industry that is eCommerce, and we believe when it comes to nonprofits, this is a new industry that has really not been capitalized on yet.

Brian: Yeah, this is true. I specifically leverage Stripe to be the backend or be the payments infrastructure for my swag shop. Swag.OpenSauced.Pizza. I currently have it shut down because I did not want to put labels on sticker packs and stuff like that anymore, so don't buy anything please. But the easy thing to do is ship stickers, have a one cost, one product.

But when you introduce things like T shirts, having a SKU that has sizing attached to it, it's still challenging to do with Stripe and there's a lot of layers you could put on top to make it work. It sounds like with Everfund, the layer which is donations, that's what you're handling and that's something that if anybody listening, they've tried to do a donations platform or did not even a nonprofit.

A lot of folks do these... Just recently we had an event for Ukraine, a Developer Ukraine event. So donating and setting up that infrastructure, it tends to just go directly to GoFundMe or Indiegogo was the other one.

Christopher: Yeah. When it came to that Ukraine appeal by Remote, I will 100% say it's an amazing thing to do. But when you see how they handled the payment, it's that no matter what amount you put in, they just rounded it to the dollar and then did 34 dollars of quantities in Stripe. So it was like, "34 $1 items."

Because this is a big thing that we've found with building our headless SDK, which I'm sure we'll talk about next, is that it's this really weird mix between eCommerce, depending on the scenario, and standard one off donations.

For example, take a sanctuary, like a horse sanctuary. You could go up on Patreon and say, "I just want to donate $10." Or you can go up and say, "I want to support this pony, Justice, for $10 a month for a year." So then that's added complexity of this card checkout with items that have recurring interval. There's this hole, hinting that we've found that it's a really weird middle ground of how do you tackle it well? This is something that we're doing right now.

Brian: It's interesting, I could see this, things like campaign financing in the US. I don't know if you've ever looked into US politics, but don't do it if you haven't. You have enough politics going on in the UK that you can get your fill. But in the US with donations, there's a cap on how much you can donate per person, per campaign, per event, per activity and it does get very complex, especially when you go back to try and report different stuff like that.

I know for a fact that's something Stripe is not focused on, is donations when it comes to politics. But it's an angle that I think, for what you're trying to solve, if I happen to be running the local candidate race, I don't know, for a city council and I want to take campaign funds I also have to adhere to the same campaign funding laws.

And anybody who's listening who properly studies political science, feel free to correct me, @BDougie on Twitter. But at the end of the day, I see there's an opportunity and a market for a lot of this. The other thing is when it comes to... You and your co-founder had approached me earlier this year as you were raising funding and I learned more about your project through that conversation, and I had a lot of concerns and questions like why focus on nonprofits? Why not just use Stripe?

And you answered all these in that conversation and I felt like that as you peel back the onion and you realize like, "I do want to do something for a nonprofit, I do want to host an event for Ukraine or et cetera," then you realize, "Oh, I actually need some infrastructure, I need something to make sure that all the T's are crossed and the I's are dotted."

Christopher: And it's only the start, we are going in from payments and then hope to branch out into things like marketing. That's another massive rabbit hole of you've collected all this information now, how about getting recurring donations? Getting that supporter to donation again to your next cause? Not burning bridges because you message them too often.

These are the things that there's not a science to, but it's also not completely made up. There's certain cadences that do definitely work and we see a lot of things that happen in nonprofits is influenced by what's happening in other nonprofits around them. For example, we have hospices in the UK where people go to spend their last days well, and they're very regional, for example.

When one of them does one thing very successful, that's when the next hospice will follow on from them so there's also this Follow The Leader effect. This is very much because--

As an industry they do not have a lot of money to innovate because they're spending a lot of money on their causes. At the end of the day, that's what we want as a supporter, is you want to know that when you donate to a charity, as much of that money as possible is actually going to the cause that you feel close to.

Brian: Okay, excellent. You had mentioned in passing a headless-

Christopher: A headless SDK.

Brian: Headless SDKs, so I'm curious to get into that and what that is.

Christopher: Yeah, of course. So what we've built in our no code tools is a complete donation solution but we also build that UI and all that payment processing logic. When we handed it to the medium to larger size charities, they actually loved the technology but wanted a complete custom UI. They want control of that whole flow. They may not want four pages or five pages, they may want one massive page.

So it's about giving that flexibility to them customers that really want it, because not every customer will want it. Most customers will be happy just using the no code tool because it's one line of code and it's done. But then the ones that really want to provide that custom experience, that really know what they're doing to build an amazing donation experience, that's when we're giving them the infrastructure to do it.

Brian: Excellent. Yeah, so I did want to talk about your connection, because your choice in using Redwood to build the product, you had mentioned that in passing. Curious how that's going and what the community is like as far as support and discovery?

Christopher: Yeah, of course. This is a massive subject that I could talk about all day. We built our original MVP on Gatsby 2, Happy and Prisma 1/Mongo and it was this massive Glue Effect, we just tried and mashed it all together and hoped it would stick because at the time I didn't know best conventions. I just picked the top frameworks that I thought would be the ones to use and went with it, and it kind of went okay.

We got MVP out, we got payments moving, we got a dashboard made, but then as we kept going it started getting really hard to move forward because Gatsby 2 was showing its limits, Prisma 1 was showing its limits. Then a moment came along that I discuss with Anthony in an FSJam episode called When To Declare Technical Bankruptcy, was when is it too much? Redwood JS came out in its alpha, and I'd heard of it and I kept it aside, I said, "I can't use it yet. It's way too early."

So I watched it on the side, carried on trying to push through this really big pipe of not great infrastructure. A point came where I was like, "This is actually really, really hard now." So we looked at what they were doing over at Redwood JS and we decided that while it was very early to make a choice, we believed in their choice of Graph QL and Prisma 2 because Prisma one was being deprecated.

So we believed in Graph Ql and Prisma 2 and they were very early in their web and auth solution, so we decided to go, "Hey, look. We know our dashboard really sucks right now. It's not doing amazing so let's rewrite it before it gets too much bigger, take all of the logic we can, let Redwood JS handle the infrastructure side to it." It was probably one of the best decisions we ever made because, yeah, I think it would've sank the company if we'd carried on trying to push down that tube really.

Redwood has gone from stroke to stroke and has gotten much better every single update, it's now at 2.0, they've always handled breaking changes very well. In terms of a project, I believe we joined their beta on 0.9 and now they're on 2.0 so that's over 30 versions that we've grown with them. In that time we really pushed the framework to its limits, found out what it did really well and what needed replacing.

For example, our donation systems, our donation gateway that hosts that no code solution is actually in Next JS, and because we picked Redwood JS that had the Graph QL endpoint, we can easily communicate with the Redwood backend and have that perfect moment of that ISSR and all of that OG goodness while getting all the benefits of this real well scaffolded backend.

Brian: Okay, excellent. Yeah, appreciate you going into that. I just had Anthony on the podcast like last episode, talking about QuickNode, his new employer and he's been on previously talking about Redwood so it's nice to get the updated take. But also getting a take from folks who are deploying this stuff through production, because I personally have a Redwood app which is my admin dashboard for what is now Hot.OpenSauced.Pizza, and we haven't really shipped anything through that.

But what I loved about that experience is it was so quick to get an admin dashboard up and running, because we already had data on Superbase so once figuring out how to connect the Supabase to Prisma and then generate schemas and stuff like that, it became very easy to stand it up real quick. So I had envisioned once we had made the dashboard actual, in production, because we don't need it today, we'll probably go back to the well and build that and start building out more tooling.

At least more internal tooling using Redwood. We were early in the Veet transition, so we have a React Veet app and we built everything else, all our other infrastructure on our own and tooling. I think me and my Open Source contributors, we built this together. So it's working right now, we essentially have an Open Source framework at the moment. But there's going to be a point where I actually need to pull the report and say, "We're not framework authors anymore. We're going to choose something else." So Redwood's on top of the list for us.

Christopher: Exactly. The really big challenge is not necessarily when do you say, "This ain't good enough anymore, it's that how much quality of life, speed, that was a massive thing about swapping to Redwood is what we've been able to achieve just with two people." As a solo developer we have a whole payment platform with a whole dashboard and a complete experience all done by one person, myself, and that's what we've done in the past. But now it's about expanding it to more team members, and the biggest thing about Redwood is because their fundamentals are so ingrained in the platform, if you teach the fundamentals and most people pick up the rest of the code so, so easily.

Brian: Yeah. This is true. In a world why I have an Open Source project, I take on a lot of transient contributors, so people will just come through, ship a feature and move on. It's very, very important for me that the thing that people don't get hung up on is not the infrastructure and the architecture of the product, but instead it's on something with a little more nuance, and not on things like how do I build out new database tables? Or how do I connect my API to my frontend?

Which is interesting, going back to the start of this conversation when you went to your podcast, FSJam. Redwood is pushing forward with this full stack jam, making it easy for folks to do stuff quickly. I think on their website it was like, "The framework for startups." It was some sort of tagline like that. I truly believe that if you want to start something really quickly, Redwood's a really good tool.

It might not meet you for a server side render or maybe for some other edge network craziness or whatever. But if you want to just build a prototype and build something that will hopefully get you past, because you hit a ceiling with Gatsby 2 and Prisma 1, and also just grow with you, I think Redwood's actually a really good thing to look at right now.

Christopher: Yeah, there've been so many friends that I've spoken to that have been early employees at other startups and they've gone, "So they've brought me in to rebuild the whole platform because they've outsourced the original platform and it's just no good." I think picking Redwood as one of the first choices you make could be one of the most fundamental technology choices you can make because at the end of the day no one really wants to set up ES Lin, Jest, Prettier, Graph QL, all of this stuff, every single time they start a project. They just want it done for them.

Brian: Yeah, speaking of which, I still need to setup Prettier for a project. I'm getting some crazy PRs from outside contributors and it reminds me lending is important and it's something you should probably setup before you start taking contribution from people other than yourself.

Christopher: Yeah, and the biggest thing is how do you know what the best choices are? You can only make the choices based upon your opinions and I think that's when it comes to newer developers who are not quite senior, having them choices already made for you is one of the best ways to make sure that you don't then make mistakes.

Because at the end of the day, if you say to not necessarily a junior engineer, say a junior/mid level engineer, "Go configure ES Lin," will they really make the right choices? Will they really be like, "Well, the codebase now has zero problems or 1,000 problems"? How do you find that middle ground? And how do you then potentially keep it going? Put in Jest tests on everything, Storybook. As a suite of tools, Redwood seems to have it figured out well and I'm sure with enough time it won't be the only one that does it.

Brian: Excellent. So going back to Everfund, what's next for the future? What are y'all shipping moving forward?

Christopher: Yeah. We're currently working on our Headless SDK and we'll be looking for more engineers to help us soon, and then we'll be really working on the operating system of charities, giving them the best tools with the least amount of users needed to manage them, that communication back and forth between donators, making more payments, more international payments. All of these things that we're really working on, and if you're passionate about charities or even know a charity that could use Everfund, I would love for you to reach out to me.

Brian: Excellent, yeah. So listeners, definitely reach out to Chris and the Everfund team, and also reach out if you're interested in working on this problem. It sounds like they might be hiring pretty soon. With that I actually want to transition us to picks, so these are Jam picks, things that we're jamming on, could be music, could be food related, could be technology related. It's all good, and it's all relative. So if you don't mind, I'll go first because I did get a nonprofit founder, they're a nonprofit, it's RAD .

This is basically to give mental health services to content creators. Originally this person was a gamer on Twitch and live streamer, and they saw an opportunity and a need to fill for providing mental health services to that cohort of folks. It sits broader now. But Jason who's the founder legitimately learned how to do JAMStack development. He picked up Next JS and he picked up all these suite of tools as he was googling and looking at Reddit and was able to draw together a landing page, and eventually a fully working site.

He's connected to quite a few different organizations, so definitely check it out, YouAreRad.org. Then my second pick, when we were talking about the setting up systems and making less decisions about shipping your app, my pick is actually Figma and I'm now an editor on Figma so I've been using Figma directly for Open Source. We currently have two designers that we've been working with pretty regularly and it just ended up chaos on trying to keep track of designs and whatever tool or system.

As an outsider, a developer who doesn't design stuff regularly, Figma is pretty intuitive for me. I spent a little bit of time learning how to use it. I also had a little sit down with my current designer and he actually walked me through how to use Figma, how to create a team, how to find files. I didn't even know you could write comments directly and stuff, it's mind blowing. Amazing tool. If this comparison is fair, Figma is like what GitHub is to developers, Figma to designers, and it's proving extremely valuable and useful.

Christopher: Yeah, that world is completely different. You're either in two or three camps. It used to be Adobe versus Sketch, but now it's like, "Are you using Figma or are you using Adobe XD?" That's really where it's gone. My pick would be React Bricks. We've recently redesigned our website, and that was to a spec that was given to us, a design from a design and really adding that layout in blocks in React using Next JS was actually really, really good fun and a really nice little challenge. Because our new website has little gubbins and different layered views, so really having to challenge my CSS skills again was a really good challenge.

Brian: And React Bricks, is this kind of like Storybook, just another tool, similar?

Christopher: Kind of, but actually much higher level. You make a brick, and then it's the CMS as well. So when you go onto their admin dashboard you'll have all the bricks that you've made and you can obviously upload a photo, change the text, change the colors, and because you've made all these bricks in a playground then your content editors can come in and say, "I want that brick, that brick and that brick," click save and that's the new website. Predefined from all the bricks you make. It's really cool. I believe it's ReactBricks.com.

Brian: Yeah, this is fascinating, because especially in the world that I live right now which is my landing page has gotten multiple iterations and we're currently A-B Testing copy and all this other stuff. If I could create bricks to basically say, "OK, here is where the feature suite is going to show up, this is where the testimonials will show up." It sounds like that's basically what I could do, is hot swap things on demand?

Christopher: Exactly. It allows you to put more pages together a lot faster. If you have that suite of bricks that when it comes to making a new page, you go, "Ah, pull that brick, that brick, that brick, fill out the content." 90% of the time you have exactly what you need with your core web bricks. But this is pretty much building websites is a completely different dark arts to building a full stack application.

Brian: Yeah, this is true and this is something that I went through this practice because at my time at Netlify, we did have marketing sites and we had the actual product design, and it is a different cadence but also approach. I love building marketing sites, I'm not great at it but I love building stuff that hopefully I can convert folks. A previous pick for a previous episode was Post Hog and I have been really knees deep in analytics and conversions and stuff like that on the website. All GDPR compliant if anybody is concerned. But yeah, it's a whole nother world I never had to be in for years until very recently.

Christopher: Yeah. And it's quite an interesting one because even that standard has its rules with CMSs, frameworks, Eleventy, Gatsby, Next JS, Next JS is a bit overkill but it's great for things like React Bricks. Remix is starting to come up with marketing websites more. Then it's all about CSS and the animations and graphics, and Greensock would be another one of my picks. It's that animation library, it's pretty cool if you get a chance to look at it. But yeah, it's completely its own skill set, in my opinion, is building marketing websites compared to actually building full stack websites.

Brian: Oh yeah. Anyway, we could probably go miles long on this conversation. But I follow Jay who currently works at Google, does a lot of animations and SVG animations and I discovered through him and also Sarah Drasner has a book out there about SVG animations. Highly recommend taking this up if you want to go down this rabbit hole. It is a fascinating place.

It's basically a place where either I have to offload that to someone that has more experience than me or hire contractors to work on this, because my skillset is not that deep when it comes to it. It's a fun problem but I know I'm not going to be the perfect person to solve this problem.

Speaking of which, solving problems, everyone check out Everfund. Chris, thank you so much for jumping on, having this conversation. I do hope that folks who are involved in this space or want to be involved in the space will reach out. And listeners, keep spreading the jam.