Co-founder / Head of Tech, Effective Altruism Funds
Thanks for this writeup. I'd also add that EA Funds accepts cryptocurrency donations, is tax-deductible in the US (501[c]), the UK, and the Netherlands, and doesn't charge additional fees (fees are just whatever our exchange charges us, which is typically on the order of 0. 2% or lower). Donations can be made to any of our four Funds, or to a list of ~40 supported effective non-profits.
At the moment you need to get in touch with us directly to make donations, we support ~20 coin types, and our minimum donation size is $1,000+ or equivalent. However, we're planning to roll out a new system (integrated with the normal donation form on our website) that supports over 120 coins and will have much lower minimums in the next month or so.
(Disclosure: I'm a co-founder of EA Funds)
DAFs do make it much easier to donate appreciated stock, and this is good advice. However, if you want to make a donation of appreciated assests and you aren't able to set up a DAF, EA Funds accepts donations of stock (in the US) and cryptocurrency (US, UK, and NL) for donations of more than $1000 (no promises that you won't have to send a fax to your broker if you want to donate stock, but in general that hasn't been the case for most of our donors who are donating from Vanguard etc).
For EA Funds this is something that we’re planning to do very soon. It’s something that’s always on the backburner (as shipping features always tends to take priority), but now that there’s a new website that has much better global control of component styling, this is something where I think we can get some easy wins.
Not really (we’ve sporadically used Personas in the past, but not very systematically), but I’ve actually just been doing more reading on this. I expect that (at least for EA Funds) Jobs-to-Be-Done will be a big part of our user research project going forward.
TL;DR; – For Funds/GWWC, the frontends are React (via NextJS) running on Vercel (previously a React SPA running on Netlify). The backend is a bunch of Node.js microservices running on Heroku, connected to a Postgres DB (running on RDS), and wired together with RabbitMQ. We’ve migrated most things to TypeScript, but a lot of the backend is still JS. A lot of business logic is written in SQL/plpgSQL.
EA Funds and GWWC have been on the same platform since 2017, and share the same backend.
Down the React rabbithole a bit: We connect to the backend using Apollo to manage GraphQL queries, we use Immer for immutable state management as needed (though we don’t use Redux or any other global state management). UI components are provided with Material-UI.
I used to use Netlify to host the EA Funds/GWWC frontend, but we’ve moved to Vercel for their first-class NextJS support.
The backend is a collection of quasi-microservices running on Heroku, all written as Node.js apps:
In addition to EA Funds/GWWC, I’ve also helped set up a bunch of other sites used by CEA (e.g. EffectiveAltruism.org, EAGlobal.org, CentreForEffectiveAltruism.org, the GivingWhatWeCan.org homepage). Most of these are currently using the Metalsmith static site generator, which generates static HTML files that are served via Netlify. This setup has been fantastic for performance and reliability, but eventually these sites will be ported over to the NextJS monorepo for better maintainability.
In terms of pain points, it’s generally been a pretty solid system. The biggest challenges have been maintenance. E.g. we’ve migrated to NextJS, partly for the improved performance and DX, but also because the previous SPA was running an outdated version of React, and because of the way the boilerplate I used was architected, upgrading to a more modern version (which many packages now require) was more trouble than it was worth. Similarly, all the static sites have historically been hosted in their own repositories, which has meant that they all have slightly different ways of doing things, and improvements made to one don’t propagate to the others. Hence, the move to a monorepo, where we can share components/logic between sites. Also, the more I use TypeScript, the more I hate using vanilla JS, so I guess that’s something of a pain point in the parts of the backend that haven’t been migrated yet!
We run a pretty lightweight version of Agile. We’ve tried doing more or less of the ‘canonical’ Agile/Scrum methodologies at various points, and settled on what we have because it works for us. Basically, JP and I have a weekly meeting where we set sprint goals, broken down by number of story points (where one story point = ~ half a day of productive dev work). These tasks are added to a kanban board that we update throughout the week as things progress. We do daily check-ins with each other, and with our respective managers, to discuss progress/challenges etc. We also do a couple of pair programming sessions each week.
Tasks are triaged based on discussion with our respective managers, taking into account what seems most important to do next (itself a combination of user feedback, outstanding bugs and feature improvements, org strategy, events in the world etc). We have a loose product roadmap that informs where we expect to be going over the next quarter and year, but we don’t make concrete plans for more than a quarter away.
We’ve iterated a lot on this over the past few years, and I think that we’ve found something that works well. I like that the system is lightweight, and strikes a good balance between giving sufficient direction for what to work on, while allowing for a lot of flexibility and not getting mired in process. It also forces us to make reasonable time estimates about what we’re doing, and these are sanity-checked by another dev, which helps avoid scope creep, or underspecified tasks. Regular check-ins make it easier to stay on track – I find it very motivating to be able to show someone else the cool thing I’ve been working on and get feedback.
I think that as we grow we’ll probably need to systematise things more. At the moment, it relies on JP and I having worked together for a long time and being very comfortable with each others’ working styles. I could imagine that as we take on additional developers, or that as the projects we’re working on diverge more significantly (as I’m now focusing almost exclusively on EA Funds) that we’d need to make some changes, probably in the direction of more concrete progress reports through the week.
For EA Funds (and the pledge management parts of GWWC), that’s me. For the Forum it’s JP. We’re both devs first and foremost though, so we get a lot of input from other people (Aaron who manages the content side of the Forum, Luke Freeman who runs GWWC, Jonas who runs EA Funds, Ben West who manages the Forum team and who is a former tech startup CEO etc)
I think the biggest challenges we face are related to capacity rather than specific skills. So, a really productive fullstack dev could have a huge impact just by virtue of helping us to ship things faster, and cover more surface area.
That said, a few things that I think would be great to have more of:
I’ll first caveat by saying that I haven’t worked at either a typical startup or big tech company.
I think that there’s probably not a huge difference between CEA and a very early stage startup. I think that the most relevant dimension is just scale – currently we’re two devs working on a bunch of different projects, which means a high degree of autonomy and ownership over the code in a way that I expect is similar to a lot of small startups. We’re obviously a more mature org though, so we do have a lot of processes in place (CI, a dedicated Operations team etc) that you wouldn’t find at a really new startup. So, in some sense it’s the freedom and ownership of an early stage startup combined with the security and flexibility of an established org. It also means that there’s a lot of time spent on interacting with users (as opposed to just being siloed in your text editor), which I really like, partly because this is a great community and it’s really nice to talk to EAs who use your software, and partly because it helps you to get better at thinking about product development and making things that serve the needs of your constituency really well.
Another thing that’s a bit strange about CEA as a non-profit, and as an EA org, is that the approach to scaling is a bit different. In a for-profit startup, your aim is to grow as fast as humanly possible (at least, when you hit product-market fit). We’ve deliberately avoided that strategy (at least for now), in large part because it doesn’t seem prudent to scale something like the EA community as fast as possible, because scaling fast trades off pretty hard against the fidelity of your message and the existing culture of the community. This could obviously change in future, but historically it’s been part of our approach. This in turn means that the challenges are a lot about understanding how to build solid products that work for EAs, rather than how to run huge k8s deployments etc.
The Centre for Effective Altruism UK (the legal entity behind EA Funds' UK operations) is registered in the Netherlands as a tax-deductible charity.
When you get to the payment page you can select which country you'd like to donate in. To donate in a way that's tax-deductible in the Netherlands, select 'UK/NL' as your country, and then optionally select EUR as your currency code. You can donate via credit card or SEPA transfer.
ETA: I've updated the relevant FAQ entry to make this clearer.