Hackathons for public good: running one for a cause

A hackathon for public good works when a real organisation on the ground owns the challenge, people who live with the problem are in the room, and someone has agreed in advance to maintain what gets built. Without those three, cause hackathons tend to produce well-meaning apps that nobody uses and a partner left with code it cannot run. Plan the event around the charity's capacity, not the volunteers' enthusiasm.

This piece focuses on cause-led events run with or for charities, community groups and public services. For the general mechanics of a hackathon, see How to run a hackathon that produces something real. For the full range of formats, see Hackathons, jams and challenges: every type explained.

Why cause hackathons fail differently

Corporate hackathons fail when nobody owns the result. Cause hackathons fail for that reason and three more:

• The partner is small. A charity with four staff cannot absorb a new app, a database and twelve volunteers asking for feedback.
• The people affected are absent. Teams design for refugees, older people or patients without meeting any of them.
• The problem is not technical. Many social problems are about trust, time, money or rules. A clever app can make them worse by adding one more thing to learn.
• Goodwill ends on Sunday. Volunteers move on, and nobody maintains what they built.

The fix in each case is preparation and honesty, not more energy during the event.

How to run one, step by step

1. Start from a partner, not from a cause. Find one or two organisations already working on the issue and ask what would actually help them. Sometimes the answer is not a hackathon at all: it might be a volunteer data analyst for three months. Respect that answer.

2. Write the challenge with the partner and the people affected. Hold short stakeholder interviews with frontline staff and, with care and consent, with people who use the service. Use a problem tree to separate causes from symptoms. Then write one or two challenge statements that name the person and the moment that matters. See How to write a challenge statement people want to solve.

3. Agree what the partner can absorb. Ask plainly: what can you run after we leave? Who on your team will look after it? What tools do you already use? If they work in spreadsheets and a messaging app, the best solution may be a better spreadsheet and a set of message templates. Write the constraints into the brief.

4. Bring lived experience into the room. Invite people affected by the problem as participants, advisers or testers, and pay for their time where possible. Brief them on what to expect, give them a clear role, and make sure they are never just an audience for pitches. If direct involvement is not safe or appropriate, bring their voice through recorded interviews or the partner's frontline staff.

5. Protect people and data. Cause hackathons often involve vulnerable groups. Agree safeguarding rules for anyone in contact with service users. Use anonymised, aggregated or synthetic data unless there is a clear legal basis and a proper agreement for anything else. Never ask a partner to hand over case files to make the weekend more realistic.

6. Choose open outputs by default. Agree beforehand that code, designs and documentation will be released under an open licence or handed fully to the partner, so the work cannot be locked away by a team or a sponsor. Make this a condition of entry.

7. Recruit for skills the partner lacks. Alongside developers, recruit designers, researchers, data analysts, writers, lawyers and people who know the sector. Many of the best outputs at cause hackathons are a clearer form, a better process or a fundraising pitch, not software.

8. Judge on use, not polish. Ask the partner and at least one person with lived experience to judge. Weight the criteria towards "could the partner use this next month?" and "did the team test it with real people?" A concierge test, where the team delivers the service by hand to a few people, is often stronger evidence than a working prototype.

9. Fund the follow-on, even modestly. Before the event, secure something for afterwards: a few months of a volunteer maintainer, a small grant, a sponsor's developer time. Name who will hand over the work and when, and use a rollout checklist to make the handover real.

Illustrative example

Illustrative. A food bank network in a northern European city was struggling to match surplus food from restaurants with the volunteers who could collect it the same evening. A local university and a software company offered to host a hackathon.

The organisers spent the first month with the network rather than planning the event. Interviews with coordinators showed that the real problem was not a missing app: coordinators already used a group chat, but offers got lost among dozens of messages. Volunteers also said they hesitated to commit because they did not know how much food they would be carrying.

The challenge became: "How might we help a volunteer decide in under a minute whether they can take tonight's collection?" Two coordinators and three volunteers joined the teams. The rules required all outputs to be openly licensed and handed to the network.

The winning team did not build an app. They designed a fixed message template restaurants could fill in (time, location, number of crates), a simple shared sheet that showed who had claimed each collection, and a short weekly rota. They ran it by hand for two evenings during the event with real offers. The software company gave one developer half a day a week for three months to support the network while it settled in.

Do's and don'ts

Do

• Start with the partner's needs and capacity, and accept it if a hackathon is not the answer.
• Bring people with lived experience into the event in a real role, with their time valued.
• Agree safeguarding and data rules before anyone arrives.
• Make open outputs and full handover a condition of entry.
• Secure some follow-on support before the event, even if small.

Don't

• Don't pick a cause because it looks good in photographs.
• Don't build tools the partner cannot run, host or pay for after the weekend.
• Don't treat vulnerable people as content for presentations.
• Don't let a sponsor claim ownership of what volunteers built for a charity.
• Don't measure success by number of participants or apps. Measure what the partner is still using three months later.

Questions people ask

How do I find a charity to partner with for a hackathon? Start with organisations already working on the issue locally, and ask what would help them, not whether they want a hackathon. Umbrella bodies, volunteer centres and community foundations can introduce you. Be ready to hear that they need something else.

Who should own what is built at a social good hackathon? Ideally the partner, or the public through an open licence. Agree this in writing before the event and make it a condition of taking part, so no team or sponsor can lock the work away.

What makes a good social good hackathon project? A small, specific problem the partner faces every week, a solution they can run with their existing people and tools, and evidence that the people affected found it useful during the event.

Methods to prepare with

Begin with stakeholder interviews and an empathy map for the people affected, then frame the challenge with a problem tree and How might we. To keep partners and volunteers aligned afterwards, use a stakeholder communication plan. For civic challenges involving several public bodies, see The ecosystem hackathon, and for keeping the work alive afterwards, Why most hackathon winners never launch.