What running a local developer hackathon taught us about the parts nobody plans for
A local hackathon helped DevBooster connect with developers offline - and showed us why the physical experience matters as much as the agenda.
At some point, building a product for developers and talking to developers started to feel like two different things. DevBooster lives in the browser - it is there when someone is writing code, debugging, figuring something out. But the relationship with the people using it was almost entirely digital: support threads, feedback forms, the occasional reply to a changelog post.
We wanted to change that. A local hackathon felt like the right format - a room full of developers, a problem to solve, a time constraint, and the kind of energy that only happens when people are physically in the same space working toward something.
What we did not fully anticipate was how much of organising an event well comes down to the physical details.
-Why a hackathon made sense for us
The brief we set ourselves was simple: bring local developers together, give them a reason to build something with browser-based tooling, and make it worth their Saturday. No corporate agenda, no sales pitch embedded in the agenda. Just a good format, a clear challenge, and a reason to show up.
A hackathon fits that brief better than a meetup or a conference. The format creates its own energy - there is something to work on, there are constraints, and there is an outcome at the end of the day. People leave having built something, which is a different feeling from leaving having watched presentations.
It also creates a natural opportunity to do something for participants that goes beyond a name badge and a lunch. Which is where the physical side of things starts to matter.
The participant experience starts before the first line of code
The moment someone walks into a hackathon and picks up their kit sets a tone. It is the first tangible signal of whether the organisers took this seriously or threw it together. A cheap tote bag with a couple of sponsor flyers and a pen from a hotel says one thing. A thoughtfully assembled kit says something else entirely.
For developers specifically, this matters more than it might for other audiences. People who spend their days sweating the details of how software looks and feels notice when the same attention has or has not been applied to the physical things around them.
We wanted the kit to feel like it had been designed, not assembled.
What went into the participant kit
We settled on three items: a t-shirt, a notebook, and a sticker pack.
The t-shirt is a given for any hackathon – it creates a visual identity for the day and people actually wear them. We kept the design clean: the DevBooster mark on the chest, nothing over-designed. The notebook earned its place because hackathons involve a lot of sketching – architecture diagrams, quick logic flows, interface ideas that are faster to draw than to type.
The sticker pack was the easiest call. Stickers are the native currency of developer culture. Every laptop in the room will have them within a week. For a browser-based tool, having the identity visible on the machines people code on every day is exactly where it belongs.
Prizes worth winning
For prizes, the principle was the same as the kit: quality over volume. A handful of items that feel genuinely useful and well-made lands better than a pile of things that feel like they were grabbed from a supplier catalogue at the last minute.
Developer audiences in particular are good at reading the difference between something that was chosen with care and something that was not. The prize does not need to be expensive - it needs to feel considered.
The logistics part nobody plans for
Here is what most first-time hackathon organisers underestimate: getting physical items to an event venue on time, in the right quantities, properly packed, is its own project.
We produced the participant kits through SoMerch - they handled everything from production and printing to kitting and delivery directly to the venue. Each set was packed and ready to hand out on the day, without us managing a single logistics step beyond confirming the brief and approving the mockups.
For a small team running their first event, having that handled entirely externally was the difference between the physical side of the event working smoothly and it becoming a last-minute scramble.
How to run your own developer hackathon
-
Keep the format tight. A one-day format with a clear challenge, defined judging criteria, and a hard end time works better than an open-ended structure. Developers work well with constraints.
-
Invest in the physical experience. The kit, the space, the food - these things matter more than they appear to on a planning spreadsheet. A well-run physical event is remembered differently than a well-run online one. The details compound.
-
Solve the logistics before the week of the event. Production and delivery of physical items takes time. If you are organising participant kits or prizes, brief your supplier early and confirm delivery to the venue well in advance.
-
Make the prizes worth the effort. Developers will spend a full day building something. The prize does not need to be large - but it should feel like it reflects the effort that went into earning it.
-
Follow up with something tangible. After the event, a short post about what was built, who won, and what the team learned keeps the community connected and gives participants something to point to.
Running a local hackathon is one of the more effective things a developer-focused product can do to build genuine community. The digital relationship with users is important - but there is something that happens in a room full of people building together that does not translate to any online format.
If you have been thinking about it, the logistics are more manageable than they look.