Most writing about hackathons focuses on how to participate in them. This isn’t that. This is about running your own, with a clear reason for doing it before you start spending money and burning weekends on logistics.
This is a written version of my DevRelCon London 2019 talk.
The events that go wrong are almost never badly run. They fail because nobody defined what success looked like. You can have great food, a buzzing room, and genuinely talented people building things, and still leave on Sunday wondering what you actually got out of it. Goal clarity is what separates events that compound into something from ones that end with a Slack archive nobody looks at again.
What a Hackathon Actually Is
My working definition: an invention marathon. You bring together developers, designers, researchers, and industry experts, give them a challenge and a fixed amount of time, and they build prototype solutions before presenting at the end.
The format is more flexible than people expect. The building period runs anywhere from four hours to 36 (the latter common in game jams). Presentations can be structured pitches, science-fair demos, or a show-and-tell. Not every event needs winners or prizes.
The challenge itself is underestimated. It’s a Goldilocks problem: too specific and everyone builds the same thing; too broad and people spend half the time figuring out what they’re supposed to be building. A well-designed challenge creates focus while leaving room for interpretation, gets people into building faster, and produces a more interesting range of outcomes.
Why You Might Run One
Research and development is one of the most legitimate uses. If you have a specific business problem and would genuinely value external contributors working on it, the format is productive. The challenge from one event I ran: “How can we improve the customer experience for fans coming to Wimbledon, both during and after their visit?” If you’re in the UK and frame the activity correctly, R&D tax credits may also apply.
Community building works when you have a cause people want to rally around: social impact, civic technology, accessibility. The hackathon becomes the reason for people to gather, which then needs to be sustained afterward.
Product adoption is a longer game than people realize. If someone builds something meaningful with your tools in a constrained time period, that experience tends to stick. Some companies approach this through hack-kits, a getting-started guide optimized for speed rather than best practice.
Gathering feedback on pre-release or generally available products can surface honest reactions and case studies. The key: be explicit with attendees about what feedback you’re looking for. Vague asks produce vague responses.
Recruitment works better as a supplementary goal than the primary one. Hackathons reveal things interviews miss: pressure communication, prioritization, teamwork. But the format advantages certain personality types, and strong technical ability doesn’t always show up well in a 24-hour sprint.
Supporting sales is underused. A potential customer is warm but not committed. You run a small event where hackers, your sales engineers, and people from the customer’s business work together on a challenge built around your product in their context. More on this later.
Skills development drives most internal hackathons, giving people space to try technologies outside their day-to-day work.
When Not to Run One
If you have a very specific scope for what you want built, a hackathon is the wrong tool. You’ll spend money running an event where everyone builds roughly the same thing. Hire people instead.
If you’re expecting deployment-ready code, adjust expectations. Hackathon projects are rough. They’re valuable for ideation and identifying directions worth pursuing, but treating them as production work will disappoint you.
If you want to own what gets built but aren’t planning to pay people, two conditions need to hold: everyone knows this from the first minute (not buried in Ts and Cs), and people are compensated for their time. Skip either, and you’ll generate resentment that follows the brand.
And if the goal is purely brand awareness, you still need an audience aware of you to walk through the door. Investing in established events first is often the more efficient path.
The Ingredients
Every event needs a venue, a date, a theme or challenge, and people. Hackathons add a few things.
Food has become a point of tension. Many attendees expect multiple meals and constant snacks. If that’s not feasible, set expectations upfront. If you frame the event well, people will sort themselves out.
Content covers two phases: context-setting at the opening and talks or workshops during the building period. Good content in both makes a material difference to what gets built. The opening helps people form ideas faster; the mid-event content helps them execute.
Prizes are optional. A show-and-tell without any competitive element often produces more honest presentations. Prizes work when they reinforce the event’s goals rather than just serving as incentive to show up.
Follow-up is where most hackathons fall apart. If there’s no plan for what happens to projects after the event ends, they’ll gather dust. Building follow-up activities into the event design from the start is what creates momentum.
Designing for Your Goal
Research and Development
These events work best on weekdays. Stakeholder involvement is critical for R&D hackathons, and stakeholders are more available during the working week. The events can also be smaller, which means more manageable space requirements.
Get the attendee mix right. Applications help here, giving you visibility on incoming skills before the event and letting you fill gaps through targeted outreach. Equip people with industry knowledge through the opening content and mentorship during the build period; mentors who understand the challenge domain, not just the technology, are particularly valuable.
Pay people. If they’re genuinely working on your business problems, that’s real work. It also makes weekday scheduling more tractable for contractors and consultants.
Useful follow-up formats: development workshops where you take the most promising projects and run a tighter hack on those ideas, or redux events where you replay the top presentations to stakeholders who weren’t in the room.
Community Building
The emphasis shifts from outcomes to environment. Small, thoughtful touches get remembered disproportionately. This isn’t just event polish; it’s the signal that there’s a community worth being part of.
Weekends work better because fewer people are at work. These events are generally open and free to attend, which means they can be larger, and larger creates a different energy: more projects, more serendipitous conversations.
Content should work for beginners, or at least include content that does. Community events attract a wide range of abilities, and content that leaves beginners behind means a portion of your attendees spend the day lost.
Plan how you sustain the community after the event. Online spaces, follow-up socials, and clear reasons to keep showing up are worth designing before the event happens rather than after.
Supporting Sales
The framing is explicit: you’re running a professional engagement, paying people, and the goal is to advance a commercial relationship.
Get stakeholders from all sides in the room, including people from the potential customer’s organization. The event becomes collaborative rather than a demonstration of what you built in 24 hours.
Include your sales engineers in the hacking team rather than keeping them as observers. They know the product and the customer context, and they can upskill hackers while the event runs.
Neutral-ground venues matter more than you’d expect. Your office puts the customer on your territory. Theirs makes it feel like a site visit. A third space frames it as a shared event.
Document everything. These events are smaller, fewer projects get built, and it’s easy to leave without a clear record of what was made. You’ll want to reference those projects in follow-up conversations.
Two Recipes
Community hackathons are open, larger, and more variable. You reach more people, get more projects, the energy is higher, and you don’t need to pay attendees. You can involve multiple stakeholders across organizations. The challenges: recruiting is harder than it looks, you don’t control who shows up or what skills they bring, and the projects belong to the people who built them.
Application-based hackathons are smaller and more controlled. You curate the room, prepare people in advance, and the work produced belongs to you. You can include NDAs and share more privileged information, like real datasets, because there’s a formal agreement in place. The tradeoffs: smaller rooms feel different, you’re paying people, and the internal case for budget is harder to make when outcomes are uncertain.
There are plenty of variations between these ends: application processes for otherwise-open community events where vetting matters, high-stakes prizes that self-select for serious attendees, heavily involved stakeholders at weekend events. The format is flexible. The principles aren’t.
Knowing what you’re trying to get out of it before you start is what makes hackathons work. Once that’s clear, most of the decisions about format, audience, compensation, and follow-up follow from it logically. Start with the goal. Build backward from there.