The Evolution of a Platform
Over the past few months we've encouraged our peers to create fresh and innovative fundraising campaigns for the famine in East Africa as part of the 50/50 Project. At the same time, we set out to break down some of the barriers that often face online fundraising campaigns. It's been an interesting process (that started with a simple site to showcase the projects that our partners created) that has since evolved into a platform offering two key barrier-busting features:
A mechanism for projects to start gathering donations immediately. Simple enough, but complicated by a self-imposed caveat: all funds donated had to go directly to charity–no middle-man, no fees, no set-up costs. 100% of money donated right into the charity's bank account. An API allowing projects to integrate into the 50/50 platform in order to track, analyse and have some fun with their donor data.Currently, it looks a little something like this for US projects:
In short: Users complete their donation using a simple, one-page donation form on the 50/50 site. Donation information can then be immediately sent to a project's application via a callback and subsequently made available on our API for search/analysis later. You can get the nitty-gritty details from our API docs.
The embryonic product
When we started to build the 50/50 platform we had no idea what was required. We were learning and building at the same time. Not usually recommended practice, but it's worked out rather well, due, in part, to our accidental realisation that the definitions of Minimal Viable Product and prototype have started to blur: Did we really need to build prototypes that will be destroyed once we're confident that we've validated enough learning to move on and build a MVP?
What if, instead of a prototype, we focused on building a product with Minimal Viable Functionality, but didn't cut-corners on the underlying structure of the application, then applied the principles of validated learning and progressive enhancement as the project progressed?
Setting the scene
Thankfully, the beauty in a sustainable platform rarely comes from innovative tech: It's how you use existing, tried-and-tested code that counts. The first question you should ask yourself before tackling each and every problem is "has someone done this before...?" Just be wary that you don't stray into the wilderness of reverse engineering. Every line of code should be carefully considered: don't use anything you don't need; re-factoring should be an ongoing process.
Careful consideration takes a fraction of the time you've save by borrowing other people's code, and will ensure that you're able to keep on rapidly evolving without having to engage in costly refactoring sessions when you realise you're drowning in technical debt.
By ensuring that our underlying code was modular, extensible and scalable we didn't end up with a disposable prototype, we created an embryonic service. Quickly.
Responding to our environment
Throughout the process we were swamped with brilliant ideas for the platform. However, due to limited resource and a desire to ensure we were building a sustainable and focused platform, we decided to tackle feature development by asking the following questions every time we were presented with a new idea:
-
Is this a feature that could provide a solution to issues that other projects are likely to face?
If we could envisage that a particular feature would be beneficial to a number of current or future projects, we simply built it into the platform, documented it, and felt confident about adding another tool to our kit.
-
If this a feature that is unlikely to be re-used, can find a way around it without building anything new?
We maintain a strong focus on the project owners as makers, so if something felt a little too bespoke we would suggest ways that the API could be hacked to achieve the desired result. However, we kept a note of these requests; you can never be sure if you've answered the first question correctly…
-
Is this a bespoke piece of functionality that can not be satisfactorily hacked into existence?
Sometimes it's worth building throw-away features into the platform. Just remember to document well and code them modularly (let nothing else depend upon its existence). Take a note and remove it when no longer required.
Mutating for good
We're not sure what our next move should be. Cath, Tim and I have all thrown ideas around with the help of some fine 50/50ers, but we're probably not going to know for sure until we start experimenting again.
So, early next year we're planning to open up the 50/50 platform to the US public: anyone will be able to register and create their own projects using our payment gateway and API. During this phase we'll continue to gather feedback from project owners and improve the platform as we go.
It'll still be limited to supporting only the East African famine, and we'll be sticking with the brilliant UNICEF, but I think it'll help get us closer to knowing if there is a desire for a hackable space around online fundraising, a simple one, available to all without the fee-based approach most current services offer.