How to create a hackathon people actually want to attend
A hackathon can be far more than a room full of people building things quickly. It can be a place where participants test ideas, meet new people, and go home with fresh energy.
Jonny Strömberg, founder and developer at Confetti, has helped organize several hackathons — among them Hackaway, together with Martina Elm and Ted Valentin. Participants traveled out to an island off Stockholm, built ideas together, and took part in an event many later described as one of the best hackathons they'd been to.
When Jonny talks about what makes a hackathon good, he keeps returning to the same thing: the experience. It isn't only about what participants build. It's also about what they feel, who they meet, and what they take home with them.
Start with what participants should get out of it
A common mistake is to start with the format itself. You decide it's going to be a hackathon, set a date, book a venue, and assume the rest will sort itself out.
A better first step is to ask: what should participants get out of this?
Sometimes the goal is to build something concrete. Maybe you want to test a new API, explore a product, or solve a clearly defined problem. A shorter, more focused hackathon can work well for that.
Other times it's more about community, inspiration, and new connections. Then the format needs to leave room for more than just the building.
Consider:
- What do we want participants to feel as they head home?
- Should the focus be on results, learning, relationships, or ideas?
- What kinds of participants do we want to bring together?
- How much time is reasonable to ask of them?
Once you know what participants should take away, decisions about venue, length, food, teams, and program get much easier.
Choose a place that gives the event energy
The venue shapes the whole feeling. It determines not just where participants sit, but how they talk, how they move around, and how they remember the event afterward.
Jonny describes something powerful about coding in places that weren't primarily built for it. An island, a hotel lobby, a house outside the city, or somewhere entirely unexpected. It creates a sense of doing something together that's set apart from everyday life.
The unexpected also helps people meet. When everyone arrives somewhere new, more people are new together. That can lower the threshold for talking to someone you don't know.
A good venue doesn't have to be expensive or perfect. It has to suit the purpose. If you're asking participants to travel away for a weekend, the place needs to feel worth the trip. If you're running a shorter hackathon after work, a simple space that makes it easy to focus and collaborate may be all you need.
Keep the size manageable
A hackathon doesn't have to be big to be good. If anything, too large a group makes it harder for participants to get to know each other and to get room to show what they've made.
Jonny finds that somewhere around 40 to 70 participants is often a good size. Enough people to create energy, but not so many that anyone disappears into the crowd.
It also makes the ending easier to plan. Many hackathons close with teams presenting their projects. With too many teams, the presentations drag and lose momentum. At a reasonable size, more people get stage time without the audience losing focus.
Build teams that can actually work together
Team size matters a great deal. Teams that are too small struggle to get through the work. Teams that are too large risk becoming chaotic.
Jonny points to 3–4 people as a size that often works well. There's room for several skill sets, but the group is still small enough to make decisions quickly.
What matters most is that the roles complement each other. A good team might have someone focused on the technology, someone on design, someone on copy or presentation, and someone on the idea or business logic. That way people can work in parallel without constantly having to sync up.
Avoid teams where several people want to do exactly the same thing. The risk of stepping on each other's toes goes up.
Match the length to what you're offering
There's no perfect number of hours for a hackathon. The length has to fit the concept.
Jonny describes the difference between a short hackathon that ends with a party and one where participants travel away for a weekend. Both can work, but they need to be planned differently.
A shorter event can be more focused. Participants show up, build something, present, and move on. An event running across a whole weekend means you need to give more back. That calls for a good venue, good food, clear structure, and an experience that makes the time worth spending.
Bear in mind especially that participants have differing amounts of time available. Students can often be more flexible. People with families, travel, or a demanding job may need to plan further ahead. If you're asking for a whole weekend, the value has to be obvious.
Put simply: don't ask for more time than the event can carry.
Make room for meeting, not just building
Many people come to a hackathon to build something. But it's often the encounters that make them remember it.
At Hackaway, the journey to and from the island became an important part of the experience. The boat ride gave participants time to talk, float ideas, and get to know each other before the work began. On the way back there was time to talk about the weekend, exchange contact details, and wind down naturally.
It's a good example of how breaks and transportation can become part of the event rather than something that merely happens between program items.
You can create these encounters in several ways:
- Give participants time to talk before the work starts.
- Help people who arrive alone find a team.
- Build in breaks long enough for people to actually meet.
- Leave time for conversation after the presentations.
None of this has to be elaborate. But it does have to be planned.
Keep the competition at the right level
Competition can give a hackathon energy. It helps participants pull their ideas together, finish on time, and show what they've built.
But it shouldn't take over.
At Hackaway the organizers offered prize money to the winners. Looking back, they saw it hadn't quite worked. Some participants felt the money made the competition too serious, shifting the focus from creativity and community toward performance.
Symbolic prizes often work better. Winning is still fun, but the mood stays lighter. The aim is for participants to dare to test ideas, not just optimize for the judges.
The closing presentations matter too. They give teams a chance to show what they've made and celebrate the work together. Just make sure there's enough time, so the ending doesn't feel rushed.
Make it easy to take part
A good hackathon asks a lot of the organizer. There's information, registration, a schedule, participant lists, communication, check-in, and follow-up. The more smoothly the practical side runs, the more you can focus on the experience.
This is where Confetti can help you keep everything in one place. You can build a clear event page, collect registrations, send information to participants, check them in on the day, and follow up afterward.
It also makes the event easier for participants. They know where to find the information, what applies, and what the next step is.
When the practical side feels clear, it's easier for participants to relax, keep building, and get to know the people around them.
Create something participants remember
A good hackathon isn't only about what gets built during a few intense hours. It's about the whole.
The right venue brings energy. The right team lets ideas grow. The right length leaves participants energized rather than exhausted. And the right ending sends people away with new contacts, new thinking, and the feeling that they want to come back.
Start with the participants. What do they need in order to contribute, feel comfortable, and have fun along the way?
Plan from there, and the hackathon becomes more than a format. It becomes an experience people actually want to be part of.
