For people who have never been to one
Your first hackathon: what actually happens, and what to bring.
The word sounds like breaking into a bank. It is a group project with a deadline you can see from where you're sitting. Here is what the day looks like, so nothing surprises you.
What a hackathon is
A fixed block of time, anywhere from an afternoon to a whole weekend, where small teams build something that runs and then show it to the room. Some are competitions with judges and cash prizes and sponsors. Some are just a room and a clock. Ours in Athens is the second kind: six hours, no prizes, everyone gets in.
The thing people get wrong is thinking it's about code. It's about finishing. Most of what makes a good team on the day has nothing to do with programming.
Hour by hour
You arrive. There is a name tag and a lot of people looking at their phones because they don't know anyone either. Then teams get formed, either you bring one or the organisers make them. At Commit Athens names come out of a bowl, five at a time, so you don't have to solve the "I don't have a team" problem yourself.
Then the first ten minutes with your team, which are the hardest ten minutes of the day. Five strangers, one idea. Whoever talks first usually sets the direction, so if you have an idea, say it early and badly rather than late and polished. The stupid ideas are the ones that get finished.
Then you build. This is most of the day and goes faster than you expect. Then demos: each team stands up and shows the thing, working or not, for a few minutes. Then it's over, and you have four people's Instagram handles you didn't have that morning.
What to bring
- A laptop and the charger. Sockets run out; ask early.
- Logins that already work. GitHub, whichever AI tool you use, a Google account. Resetting a password at 14:30 is a bad use of a team.
- Water. Something to eat if the event doesn't feed you, and many don't.
- Nothing else. You do not need a project, a plan or a slide deck.
What you can build in three hours
One small thing that does one thing. A page with a single button. A quiz about your neighbourhood. A game that fits on one screen. A bot that answers exactly one kind of question. A site that tells you whether your bus is worth waiting for.
Not: an app with accounts, a database, a payment system and a mobile version. Every team that starts there ends the day with a login page. Cut the idea until it fits in the time, then cut it again. If your team disagrees on what to build, take the smaller one.
If you can't code
You still have a job, and probably more than one. Somebody has to decide what the thing is. Somebody has to draw the screen before anyone builds it. Somebody has to write the words in it. Somebody has to keep trying to break it and say "this is broken" out loud. And somebody has to make the four-minute demo make sense, which is the part most programmers are bad at.
The AI tools also close most of the gap now. ChatGPT, Claude, Cursor, Lovable, Bolt: you describe the thing in plain sentences and they write the code. You will still need one person who can tell when the output is wrong, and there is usually one on the team.
The demo
Four minutes goes like this: one sentence on what it is, then show it doing the thing, then stop. Don't explain what you would have built with more time. Don't apologise. If it crashes, say "it does that" and move on. The demos people remember are the broken ones with a good sentence in front of them.
Things first-timers get wrong
Spending the first hour picking a name. Adding features at 16:00. Letting the one person who can code do everything while four people watch. Not talking to the team next to you, who have already solved the thing you're stuck on. Leaving before the demos, which is the part where it becomes worth it.
Saturday 10 October 2026, 12:00 to 18:00, Galatsi. Free. The full details.