The Ultimate Guide to Hackathon Planning

A hackathon is not a conference with laptops. The registration is by team, not by person; the schedule runs overnight; you feed people three or four times; and a third of everyone who signs up will not turn up. This guide covers what actually breaks, in the order it breaks, and how to set the event up so it does not.

1. Decide the team rule before you open registration

Every downstream decision depends on this, and changing it after you open is painful — you will already have teams that no longer fit the rule. Settle three things first:

• Minimum and maximum team size. Two to four is the common range for a 24-hour event. Below two you lose the collaboration you are trying to create; above four, someone is always idle.
• Whether you allow solo entries. If you do, you need a team-forming channel before the event, or those people drop out.
• Whether the price is per team or per person. This is the one that catches people out. A flat team price is simpler to advertise and much simpler to refund.

On Vihaya Events you set the minimum and maximum on the event itself, and the registration form refuses to submit an incomplete team — it tells the leader "add 1 more member" rather than failing silently at payment. Every custom question you add is asked of every member, not just the person paying.

Collect each member's own email address

This is the single most common setup mistake. If you only collect the team leader's contact details, then on the morning of the event you have one email address for a four-person team, and three people arrive with no ticket and no QR code. Ask for each member's email and phone individually. Each member should receive their own ticket.

Watch for duplicates too — teams routinely paste the leader's address into all four rows because it is faster. Vihaya flags this inline while they type ("Same email as Participant 1 — they would get both tickets") rather than letting you discover it at the gate.

2. Size the event honestly, then plan for the no-show rate

Free hackathons routinely see 30–50% no-show. Paid ones are dramatically better, which is one of the strongest arguments for charging even a nominal fee — ₹100 changes registration from a bookmark into a commitment.

Two practical consequences:

• Do not cater to your registration count. Cater to your expected attendance, and have a plan to top up.
• Run a waitlist rather than over-selling. Over-selling to compensate for no-shows works right up until the year everyone turns up, and then you have a room that is genuinely too small and a safety problem.

3. Use tracks if you have more than one theme

If your hackathon has themes — fintech, health, open innovation — model them as separate tracks rather than one big event with a dropdown. Tracks give you a per-theme capacity, per-theme pricing and per-theme check-in, which is what you actually need on the day.

The practical payoff is at the door: if each track has its own gate, a scanner scoped to that track will refuse a ticket for a different one instead of silently admitting them. That is the difference between a clean count and a room that does not match the roster.

4. Price it in phases, not one flat number

Early-bird pricing is not just a discount — it is a forecasting tool. People who commit early let you order food, book the venue and confirm sponsors with real numbers instead of guesses.

Phase	Typical window	What it buys you
Super early bird	6–8 weeks out	Proof the event is real; something to show sponsors
Early bird	3–5 weeks out	The bulk of committed teams; your catering baseline
Regular	Final 2 weeks	Late deciders, at full price

Cap each phase by seats as well as by date. A phase with a seat allocation hands over automatically when it sells out, so you are never in the position of selling early-bird tickets the week of the event. See how pricing works on Vihaya for how the platform fee interacts with this.

5. Plan food as a scanning problem, not a catering problem

Catering quantity is the easy half. The hard half is that a 24-hour hackathon serves three or four meals, and without a system you get the same queue argument at every one: has this person already eaten?

The workable approach is to make meals part of the ticket and scan them. Give each ticket a meal allowance, scan at the counter, and enforce a cooldown so the same QR cannot be used twice in five minutes. Two details that matter in practice:

• Record veg vs non-veg on the ticket itself and show it to the person serving. This is the one thing you must not get wrong, and it should not depend on a volunteer remembering.
• Show the counter how many meals are left on that ticket before they serve, so staff can warn rather than refuse.

6. Check-in: one desk, one source of truth

The failure mode here is having two desks that disagree. Someone checks in on a laptop at the main door, someone else scans QR codes at a side entrance, and by lunchtime nobody knows the real number in the building — which is a fire-safety number, not a vanity metric.

Whatever tool you use, make sure every entry point writes to the same record. On Vihaya both the QR scanner and the manual check-in desk read and write the same arrival state, so a team member admitted at the gate already shows as arrived on the desk.

Also: put a laptop with search at the door. Someone will always have lost the email, and the ability to find them by name or phone in three seconds is what keeps the queue moving.

7. Certificates: decide the rule, then automate it

Certificates are the last job of the event and the one most likely to be done badly, usually at 2am the following week by one exhausted volunteer with a mail merge.

Decide the eligibility rule up front — normally "checked in", sometimes "checked in and submitted a project" — and let attendees collect their own certificate rather than emailing 300 PDFs from a browser tab. Self-serve also means the person who lost theirs in six months can get it again without asking you.

8. The 48-hour-out checklist

• Export the roster to CSV and give a copy to the venue and the catering lead.
• Print an attendance sheet as the offline fallback for when the wifi dies. It will.
• Confirm every team has usable contact details for at least two members.
• Send the joining instructions — address, timings, what to bring, what is provided.
• Brief the door team on the refusal cases: wrong track, unpaid, and already-checked-in.
• Charge every scanning device, and bring power banks.

Running a hackathon this term? See how team registration works on Vihaya Events — free for free events, with team rules, per-track check-in and self-serve certificates included.