Hi, I'm Samuel Cochran

on Twitter, Facebook, Google, LinkedIn, GitHub, Stack Overflow, and Steam.

Building Apps For Charity, or How To Win $10k

Last Monday I rocked up to the Discovr office to Stuart Hall asking "Hey, want to go to Sydney?" Vodafone were running #AppAid, a 48–hour hackathon to build apps for charities. The lovely Michelle O'Brien approached Stu inviting some of our team over to participate. A quick look at the causes and proposed apps really inspired us, and what a great idea—of course we said yes! Flights were organised, bags packaged, and we were on a plane Wednesday night.

OzHarvest is that charity that stood out for us. They rescue excess food from landfill and distribute it to recipient agencies to feed people who would otherwise go hungry. They have 15 trucks roaming Sydney, Newcastle, Adelaide and Brisbane collecting and delivering food from 7am to 11pm, feeding over 10,000 people every day. That's also roughly 150 tonnes per month saved from landfill. Not only is this a fantastic cause, it's a massive and incredibly interesting logistical problem. This was the clincher for me: it's a problem that's a perfect fit for a technological solution. The more operational efficiency and support we can provide to OzHarvest, the more mouths they can feed.

James, Tom, Stu, Tom's son, and I.
James, Tom, Stu, Tom's son, and I.

Given only 48 hours we couldn't address everything we'd like to, so we prioritised. Their initial brief was to build an app to "enable hundreds of food donors to notify OzHarvest when they have food available for rescue and for OzHarvest to plan and coordinate the process of food rescue in real time, in order to maximise the benefit to thousands of recipients."1 Some food donors have regular pickups available which are scheduled with drivers, but the staff are also inundated with calls from donors with unexpected surpluses available straight away. Sometimes these ad–hoc requests can only be retained for a small period of time, or will shortly perish, so pickup has to be arranged straight away. Currently this involves slotting the request into the paper–based run–sheet of a driver out in the field via SMS. This whole time–consuming process has to be conducted by a staff member, and the phone call may be a prohibitive hurdle for the donor's agent. The first aim of the app, therefore, was to eliminate the phone call.

The team engaged in heated discussion.
"Well... I'm going to do it like this."

Stu and I got straight to work building an iOS app and Ruby on Rails API and staff backend. After a couple of hours we had some basic token–based user authentication with registration and pickup requests coming through. After creating a dashboard for the OzHarvest staff to monitor the pending pickups we added the ability to push notifications back to the app to coordinate the pickup. The staff dashboard was also fleshed out to support CRUD on users, donors, recipients, and pickups.

MacBook Air surrounded by Samsung promotional gear
The irony of developing iOS apps on Macs at a Samsung–sponsored event was not lost on us.

Stu added a map of donors to the app so even if you don't have food to donate or mouths to feed you can help out by supporting those that do. After we'd finished the basic functionality, the wonderful Simon Seeber to whom we are even in debt donated a few hours to help us get everything pretty.

After a little sleep, presentations were due on Saturday morning. We had 5 minutes to convince a panel of judges—including the esteemed Guy Kawaksaki!—that our cause and app were worthy of their investment. Salem Lassoued, one of the OzHarvest volunteers, introduced OzHarvest, presented the business problem, and handed things over to me to present the mobile app. With Stu driving on an iPhone, I talked through what we built, why, and where we'd like to take it, punctuated by a push notification. Salem tidied it up with a quick dip into marketability and we all breathed a little sigh of relief.

OzHarvest's operations are massive, and so is the potential scope of these apps. The blatantly obvious and, I think, most beneficial next steps would be to add support for managing the vehicles and routes, drivers, and the daily runs. This would remove paper run sheets and allow the driver and support staff to coordinate ad–hoc pickups and deliveries.

Another potential are for improvement is more functionality for recipient agencies—the people handing out food. Not only does OzHarvest receive fresh food, they receive non–perishable food and all sorts of relevant support equipment. Some of this is warehoused when space can be arranged and allocated to agencies as fairly as possible. At the moment, the inventory is occasionally emailed to over 500 people to gauge interest and arrange delivery. We can turn this process on it's head and let recipients browse the available stock ad–hoc and make a request for anything they can use. These requests can be reviewed and tempered by OzHarvest staff to allocate and arrange delivery of the available resources.

The current website looks like a pretty standard content management system which I think could benefit from some member services. Real–time statistics on the home page for a start. A "skite" page for the generous food donors who want to promote their involvement with OzHarvest. A directory of recipient agencies who would like to advertise their services and raise awareness. Maps of donors and recipients for supporters, volunteers, and those in need. I'm sure there's more! I've already started fleshing out some of these ideas based on the current website.

There's so much to do, and it's such an inspirational cause. I'm going to try to continue donating what time I can to completing more of this functionality, but it's going to be hard from so far away. There are some fantastic volunteers at OzHarvest who may be able to help complete more of these features also.

A frosty beer in front of the Sydney Opera House.
Cheers, Sydney.