Skip to content

Organizing a hackathon

Thinking about organizing an AT Protocol hackathon? Great. Here is what we have learned from running community events, so you do not have to start from scratch.

Get people building on AT Protocol together to ship working code or a proof-of-concept by the end. The side benefit is just as valuable: people meet, get inspired, and learn new things from each other.

A theme is optional, but it sets the tone and attracts a specific crowd. Pick something that genuinely interests AT Protocol developers. Some directions that work: a specific lexicon or app surface, a shared piece of infrastructure (feeds, labelers, PDS tooling), or an open prompt like “double your development speed.”

For a physical event, the venue matters most. Enough space, reliable internet, and enough power for everyone’s laptops. For a one to three day event, sort out food and drinks for the whole stretch.

A hackathon is not expensive to run. You mainly need a venue, catering, and a few things that make it more fun. As a rough guide, past community events landed around 100 to 150 euro per participant per day, mostly driven by the catering. You can ask participants to chip in, cover it from a company budget, or find a sponsor.

Pick dates that work for most people and avoid clashing with holidays or other community events. One to three days works, depending on how deep the projects go. Running part of it over a weekend has worked well. Check the events page for your country and ask around so you are not competing with another event the same week.

You will need a few hands for marketing, logistics, catering, and venue setup. It is not rocket science, but it is more than a one-person job. Post about it early and let your country’s community account know, and we will help spread the word to the wider community.

Plan the flow: registration, team formation, kick-off, hacking time, breaks, presentations, and wrap-up. Leave real time for socializing and networking, not only heads-down coding.

Write a clear invite with the goal, theme, date, venue, and how to sign up. Send it to your country site’s maintainer and we will list it on the events page and share it from the community account.

Set clear rules up front: a code of conduct, how to submit a project, and how judging works. The exact criteria are yours, as long as they match the goal and theme. The community code of conduct is a good baseline to point participants at.

Prizes are nice but not required. If you do offer them, make them enticing enough to motivate people.

Keep it smooth. Your on-site team handles any logistical hiccups while people build. Make sure everyone has what they need and keep them posted on timing and any changes.

We would love hackathon projects to outlive a single weekend. AT Protocol is open by design, and the projects are a good way to grow the ecosystem’s shared toolbox.

  • Publish code under an open-source license (MIT is a good default) so the whole community can use and build on it.
  • Encourage people to continue or build on earlier projects rather than starting cold.
  • Ask each team to document what they did and share a short summary or demo of the results, including ideas for whoever picks it up next.

Afterwards, a short wrap-up helps: what worked, what to improve next time. Share the results with participants and thank everyone for showing up.

  • On the wifi: make sure port 22 is open for SSH so people can push and pull from their repos (ask us how we know).
  • Have a working coffee machine, and a backup for when it dies.
  • Name badges or stickers, at least for day one.
  • The shorter the hackathon, the more you should organize topics and teams beforehand. For a single day you do not want to burn two hours on this. A short online kick-off in the weeks before helps.

Want to run one? Open an issue on the website repository or reach your country site’s maintainer, and we will help you take the next steps.