How to organize a Web3 hackathon in India: a checklist

Almost every failed hackathon failed at this step. "Grow the ecosystem in India" is not an objective you can design against, because the event that maximises registrations is not the event that produces projects still running six months later, and neither is the event that gets you three senior hires.

• Builders shipping on your stack: fewer, stronger teams; hard technical tracks; mentors who can debug your SDK; a follow-on grant path decided before the event.
• Awareness: broad tracks, low barrier to entry, content and streaming built into the production plan, and registration volume as the honest metric.
• Recruitment: a submission format that reveals how people work, judges drawn from your engineering team, and a shortlist process agreed with your hiring managers in advance.

The dependency chain matters more than the total. Some things can be arranged quickly; others gate everything downstream and cannot be compressed however much you spend. The indicative ranges below are general planning guidance, not a quote, and an in-person event sits at the longer end of each.

1. First, and before anything is announced: the objective, the budget, and the prize pool. Every later decision is downstream of these, and a prize pool that changes after announcement damages trust with builders permanently.
2. Next: the date, checked against the academic calendar, exam periods, major festivals, and the other Web3 events competing for the same builders that month.
3. Then, in parallel: the venue or platform, the track definitions, and the judging rubric. Tracks gate mentor recruitment, because you cannot recruit for a stack you have not chosen.
4. Then: mentors and judges. These are the slowest to confirm because you want specific people rather than whoever is free, and good ones are booked weeks out.
5. Last, and only once the above is firm: the marketing push, campus outreach, and registration opening.

Two Indian specifics worth putting in the calendar early. Semester exams and placement season remove large parts of the student pool for weeks at a time, and the dates differ by university. And if you are handing out prize money, the finance and compliance work described below starts at planning time, not after the winners are announced.

The honest answer for most first-time organisers is online for reach, with one in-person demo day for the shortlisted teams. You get the submission volume and the relationships, without committing to full in-person logistics before you know whether the format works for your ecosystem.

The reflex is to go straight to the IITs and NITs. They are worth including, and they are also the most competed-for rooms in the country — you will be the fourth ecosystem that semester, talking to students who have already collected several hackathon T-shirts.

The better play is usually a mix: a few of the top-tier campuses for signal, plus strong tier-two engineering colleges where an outside ecosystem showing up is still a genuine event and the students who engage tend to keep engaging. City-level meetups in Delhi, Bangalore, Hyderabad, and Mumbai then give you a way to keep in contact with the people worth keeping in contact with, which a single campus visit never does.

Whichever you choose, work through the campus coding or blockchain club rather than around it. They know which students actually ship, they can fill a room on a Tuesday evening, and they will tell you honestly whether your track is too hard or too easy.

Registration numbers are the least informative metric in hackathons. A large share of registrations never submit anything, and a further share submit a template with the theme name changed. If registrations are what you report, that is what you will optimise, and you will get a large number and very little else.

• Ask for something small at registration — a repository link, a one-paragraph idea, a previous project. It costs committed teams two minutes and removes most of the noise.
• Require a demo video with every submission. It is the single most effective filter, and it makes judging tractable.
• Publish the rubric with the tracks so teams know what is being scored before they choose what to build.
• Run one mid-event checkpoint. Teams that have not started by then usually will not, and teams that are stuck can still be unblocked.
• Use an established platform for submissions and judging rather than building your own flow. Devfolio is the default in India, and builders already have accounts and profiles there.

A mentor who knows software in general is of limited use to a team fighting your particular SDK at two in the morning. What unblocks that team is someone who has personally hit the same error. Recruit against the tracks you defined, not against seniority.

Brief them properly, and in writing. Mentors should know what the tracks are, what the rubric rewards, what counts as help versus doing the work for a team, and who to escalate to when they cannot solve something. An unbriefed mentor defaults to giving opinions about ideas, which is the least useful thing available to them.

Staff the hours people actually build. For an online hackathon that means evenings and late nights across the weekend, on a channel where questions are visible to everyone, so one answer serves ten teams instead of one.

Write the rubric first. If you invite judges before deciding how projects will be scored, you get five people applying five private standards, and the result is a decision you cannot defend when a team asks why they lost.

• Four or five criteria, each with a stated weight, and a short description of what a high and low score looks like.
• Score technical execution separately from presentation. Otherwise the best pitch wins and your strongest builders learn that building carefully was the wrong strategy.
• State explicitly whether pre-existing code is allowed and how it affects scoring. This is the most common source of disputes.
• Give every judge the same written brief, and have them score independently before any discussion.
• Collect written comments alongside scores, then send them to the teams. It is the highest-value, lowest-cost thing you can give a team that did not win.

This is where otherwise well-run hackathons damage their reputation. Prizes announced in one currency and paid weeks late, in a different amount, to a subset of a team, is a common story and it travels fast in builder communities.

• Decide before announcing: the currency, whether amounts are gross or net of tax, and how a prize splits across a team.
• Collect what finance will need — identity and bank or wallet details — as part of the submission flow, not after the results.
• Get the tax treatment of prize money confirmed by a qualified advisor for your specific structure before you announce, particularly where prizes cross borders or are paid in crypto. Winners will ask, and "we are checking" is a bad answer.
• Publish a payout date alongside the results and then meet it. A realistic date you hit beats an optimistic one you miss.
• Give non-cash prizes a clear owner too. Credits, grants, and accelerator interviews all need someone to actually deliver them.

The weeks after demo day decide whether the hackathon was a marketing spend or an ecosystem investment, and they are the part most commonly left out of the budget. Momentum after a hackathon decays quickly; teams return to jobs and coursework within days.

• Contact the strongest teams within a week, while they still care. A month later is too late.
• Have the next step ready before the event ends: a grant, an accelerator, office hours, a follow-on programme. Interest with nothing to convert into is wasted.
• Make specific introductions to specific people. "Let us know if you need anything" produces nothing.
• Publish what was built, with links and the builders' names. It is the record that makes the next event easier to recruit for, and it gives teams something they can point employers and investors at.
• Keep the community channel open. A dormant Discord is still where those builders are when you launch the next programme.

Pick the metrics that match the objective you wrote down at the start, and agree them before the event so nobody chooses them retrospectively to flatter the result.

• Submissions that met the bar, as a share of registrations — a far better quality signal than either number alone.
• Teams still committing to their repository thirty and ninety days after the event. This is the one that predicts whether anything lasting happened.
• Builders who entered a follow-on programme, took a grant, or were hired.
• Mentor and judge hours actually delivered against what was committed, which tells you whether the model is repeatable.
• Cost per qualifying submission, and separately cost per retained builder. These two usually rank formats differently, and the second is the one that matters.

What the numbers will not tell you is whether the builders trust you afterwards. That comes from whether the judging was defensible, whether the prizes arrived when promised, and whether anyone followed up. Those three are worth more than any metric on the list, and all three are decided by operations rather than budget.