How to run a student hackathon in a tier-2 city: a practical playbook
Venue, budget, judging, safety and follow-through for a first hackathon outside the metro tech hubs — written while planning KAIOS BUILD / 001 in Prayagraj.
By Kartikeya Mishra, updated 3 Nov 2026 · 10 min read
Some of the most motivated builders in India study and work far from Bengaluru, Hyderabad or Pune. They rarely get the events, mentors and peer networks that metro builders take for granted. A well-run local hackathon can change that for a few dozen people in a single weekend.
This playbook is what we're using to plan KAIOS BUILD / 001 in Prayagraj. It's written before the event, so it describes the plan and the reasoning, not results. We'll update it with what actually happened afterwards.
1. Decide what success means first
Most hackathons measure registrations. Better measures are:
- how many teams finished something that works
- how many participants met someone they'll build with again
- how many projects are still alive 30 days later
Pick two of these before you book a venue. Every later decision — team size, theme, judging — should serve them.
2. Venue and timing
- Colleges are the natural venue: they usually have labs, Wi-Fi and a student body that can register in one notice. Approach the training and placement cell or a technical club with a one-page proposal. Show what students get from it and who's responsible for safety.
- Check the academic calendar. Avoid exam weeks and major festivals; weekends just after mid-semester exams work well.
- Test the Wi-Fi under load. Have a backup: mobile hotspots, and offline copies of documentation.
- Power matters as much as internet. Count sockets, add extension boards, and ask whether there's a generator or UPS.
3. Format: shorter and kinder works better
A 24-hour overnight format excludes many students, especially those who can't stay overnight or need to travel home. A two-day daytime format (for example 10 am to 8 pm on both days) is safer, cheaper and more inclusive. It also produces better-rested demos.
- Teams of 2–4. Allow individuals to join, and run a 30-minute team-forming session at the start.
- One broad theme rooted in local problems — transport, agriculture, local businesses, education — rather than “anything”.
- A mentor check-in at the midpoint of day one to help teams cut scope.
4. Budget honestly
The main costs are:
- food and water for participants and volunteers
- printing and signage
- prizes or certificates
- a small contingency fund
Venue costs are often waived when a college co-hosts. Local businesses, alumni and software companies with student programmes are realistic sponsors. Offer them something concrete: a short talk, a judging seat, or a named challenge track.
Publish a clear rulebook before registration opens. Cash prizes and contest structures can have legal and tax implications, so get them reviewed. Never promise prizes that aren't funded.
5. Judging that participants trust
- Publish the criteria before the event. For example: problem clarity, a working demo, user evidence and presentation — each scored out of 5.
- Use at least three judges, and have each judge score teams independently before any discussion.
- Judges declare any conflicts of interest and don't score teams they know.
- Give every team at least one line of written feedback. For many first-time participants, this matters more than the result.
6. Safety and conduct
Publish a code of conduct and name the people to contact if something goes wrong. Make sure there's a safe way home in the evening. For participants under 18, follow the host college's rules on supervision and consent.
7. Follow-through is where the value is
Most hackathon projects die on Monday morning. Plan the 30 days after the event as carefully as the event itself:
- Collect each team's repository or demo link at submission.
- Invite teams to keep building in small accountability groups with a weekly check-in.
- Ask teams to confirm their collaboration on a platform that records it, so every participant leaves with verifiable proof of the work they did together. On KAIOS BUILD, both teammates must confirm before a collaboration appears.
- Run a short demo session one month later. Whoever shows up with progress is your core community.
Planning KAIOS BUILD / 001?
Dates and venue will be confirmed on our Prayagraj community page. If you'd like to take part, mentor or sponsor, join the waitlist and we'll contact you when details are final.