You've found an event that looks good. Time to register. This chapter covers what happens between clicking "Sign Up" and walking through the door (or logging on), so you show up feeling prepared instead of panicked.

Most hackathons use a simple registration form. You'll typically be asked for your name, email, role (developer, designer, student, etc.), and whether you already have a team or need one.

Some events also ask about your experience level, what skills you bring, and what you're interested in working on. Don't overthink these — they help organisers plan team formation and match you with the right mentors. Be honest. "I'm a marketing student who's curious about AI" is a perfectly great answer.

A few things to know about registration:

Free events have a ~65% show-up rate. Organisers know this and plan accordingly. But please, if your plans change, let them know. It helps with food planning, team balancing, and waitlist management.

Paid events (even a small fee) have much higher attendance. If there's a modest registration fee, it usually means fewer no-shows and a more committed group of participants. Worth it.

Some events screen applicants. Larger or more competitive events may review applications. This isn't about gatekeeping — it's about ensuring the right mix of skills. If you're asked to apply, take a few minutes to write a genuine answer about why you're interested. Enthusiasm counts.

The moment you register is when things get exciting. Here's what to do:

Most events will invite you to a Slack or Discord workspace after registration. Join it right away. This is where you'll find teammates, learn about challenges, get tech support, and soak up the pre-event energy.

Introduce yourself in the general channel. Something like: "Hey! I'm [name], I'm a [role/background], and I'm excited about [theme/track]. Looking for a team!" You'd be surprised how many great teams start with a simple Slack introduction.

Most hackathons organise projects around challenge tracks — specific problem areas or themes. Read through them before the event. Think about which ones excite you. You don't need to commit yet, but having a direction in mind makes team formation much smoother.

If the event is hosted on BuilderBase, you can browse challenges, read sponsor briefs, and explore what other participants are interested in — all before the event starts.

Many well-run events offer sessions before the main event: an orientation for newcomers, a brainstorming session to explore ideas, or office hours to set up tools. Go to these. They dramatically reduce first-day chaos and give you a head start on connecting with potential teammates.

Whether it's on-site or online, most hackathons follow a similar rhythm:

This is where the organisers set the stage. They'll welcome everyone, walk through the schedule, introduce the challenges, explain judging criteria, and acknowledge sponsors. Pay attention to the judging criteria — this is the cheat code that most participants ignore (more on this in Chapter 15).

The newcomer moment. Good events will ask first-timers to identify themselves — raise your hand, type in chat, whatever the format. This isn't to embarrass you. It's to celebrate you and to signal to the room that you belong here. If you're new, lean into it. If you're experienced, welcome the newcomers. The culture of a hackathon is shaped in these small moments.

If you don't already have a team, this is where you find one. People pitch project ideas (usually one minute each), and then everyone mingles to join the projects that excite them.

Tips for this moment:

This is the main event. Once teams form and projects are scoped, you build. The room gets quiet (or loud, depending on the vibe), people put on headphones, and work begins.

During hacking, expect meals (organisers will announce them), checkpoint announcements ("halfway there — start scoping down!"), and mentors circulating to help. Take breaks. Eat. Talk to people. The best ideas often come from stepping away from the screen.

At the end, each team presents what they built. Demos are usually 1–3 minutes per team. You show your prototype, explain the problem you solved, and answer a couple of questions from judges.

This is the part people are most nervous about, but it's also the most fun. There's something magical about seeing what 20 different teams built from scratch in the same timeframe. We'll cover how to crush your demo in Chapter 14.

Winners are announced, everyone claps, group photos happen, and then people mill around exchanging contacts and talking about what they built. Don't skip this part. The connections you make after the event ends can be more valuable than the event itself.

"I'll be the least experienced person there." Maybe. So what? Someone has to be, and they're usually the person who learns the most. Experienced participants love helping newcomers — it's part of the culture.

"I won't be able to contribute." You will. Every team needs someone who can research, design, write, present, test, organise, or simply ask "but would a real user actually do this?" These contributions matter as much as code.

"My team will be annoyed that I don't know things." Hackathon teams expect a mix of skill levels. If you're upfront about what you know and what you're learning, people will meet you where you are.

"I'll waste my weekend and have nothing to show." Even the "worst" hackathon experience teaches you something — about teamwork, about building under pressure, about what you want to learn next. And most hackathon experiences are far better than the worst.

Key takeaways: