Smart India Hackathon (SIH) 2026: College Internal Round Playbook

First, be honest about the statement

A statement can look like a perfect fit and still need somebody your team does not have. It never shows up on day one — it shows up when a juror asks who is handling the part nobody has done before, and everyone looks at each other. The free matcher on this site checks all 240 against your team and names the gap.

Get one screen working, then stop coding

Just one, the screen that shows what your project actually does. Fake all the data. A feature added the night before is the feature that breaks in the room.

Record the demo and write one page

Save the recording on your laptop and a phone, downloaded, not on Drive. Then one page on who has this problem: a real person, what they do today, what it costs them.

Say your first 90 seconds out loud, standing, twice

Reading it in your head does not count. Say it aloud and you will find two or three lines you cannot actually say.

Pack the bag tonight

Laptop and charger fully charged, because the sockets are never where you need them. Backup video on two devices. Slides as a PDF on a pen drive and emailed to yourself, since fonts break on other machines. One named person carries all of it — "I thought you had it" is a real way to lose.

Five minutes outside the room

Decide who speaks, one person, and split questions by area: one owns data and domain, one owns how it is built, one owns impact. Do it out loud, or you will work it out in front of the jury instead.

1. The college Wi-Fi will let you down

Thirty teams and a hundred phones on it. Get two teammates to keep a hotspot ready, and connect your laptop to one beforehand so nobody is typing a password while a jury watches.

2. Never demo an empty dashboard

A dashboard with no rows looks unfinished even when the code is perfect. Seed it. data.gov.in has thousands of government datasets, your statement's own ministry usually publishes reports, and Kaggle has something close to almost any domain.

3. Have the demo on video, offline

If the live one dies, do not freeze and do not start debugging. Say "let me show you the recorded run" and keep talking over it. Juries do not mind. What they mind is not seeing it work at all.

4. Assume the laptop will not be yours

PDF on a pen drive, project pushed to GitHub so it can be pulled onto any machine in five minutes.

5. Run it locally too

If your demo needs a hosted link, it needs the internet, and you have already assumed the internet fails.

6. A second person should know the opening

People freeze. People get stuck in traffic. One more person should be able to deliver the first 90 seconds cold.

7. Agree what you say when you do not know

Do not guess, juries can tell instantly. Decide beforehand that one person says "we haven't tested that yet, here's how we'd approach it" and gives two sentences on the approach.

8. Know which three slides matter

You might get stopped at minute four. Most teams respond by racing through everything. Decide in advance which three you would want them to have seen — usually the problem, the demo, and the impact number.

0:00 to 2:00 — the problem, and why nobody solved it

Not the statement read aloud. One real person, what they do today, what it costs them. Then name the actual blocker: no connectivity, no incentive, too expensive, nobody owns the data. These two minutes buy you the other six.

2:00 to 4:00 — the demo, before the architecture

Two full minutes. Narrate as you click and do not apologise for what is missing. If you only get through half your slides, this is the half that has to survive.

4:00 to 6:30 — how it works, then one number

Architecture now, because they have seen it and want to know how. One diagram, three or four boxes. Then a single figure they could write down. Not five metrics — teams that list five give the jury nothing to remember.

Then: use your hands

When a question comes, whoever owns that area raises a hand and answers, everyone else stays quiet. Nobody talks over anybody, and the jury sees a team that organised itself. Never let two people answer one question — the second voice makes the first answer sound incomplete even when it was fine.

The three you will definitely get

"Who actually has this problem today?" — name a real person, do not read the statement back. "What have you built so far?" — show it, plans are free. "Why this team?" — six people saying they are all good at coding is worse than four who can each name a different job.

Everyone prepares a slide anyway

Even though only one of you presents. Not to show it, but so everybody knows the whole project. The teams that fall apart in Q&A are the ones where each person only knew their own part.

"Who actually faces this problem today?"

Trap: reading the problem statement back to them. The jury already read it. Better: name one real person or role, what they do instead right now, and what it costs them in time, money or errors.

"This already exists. Why yours?"

Trap: "our UI is better and ours is free." Better: theirs is a consumer product, yours is built for the ministry. Offline-first, local language, synced with official government data. A private app cannot do that.

"Then why has nobody solved it yet?"

Trap: silence, or "nobody thought of it." Better: name the actual blocker. No connectivity in those districts. No incentive for the user. Nobody owns the data. You only know this if you read the ministry's own report.

"Can you really build this in 36 hours?"

Trap: promising AI, blockchain and IoT together. Better: a modular plan with hours attached. Core prototype in 12, integration in the next 14, testing in the last 10. Say what is already working today.

"Where will the data come from?"

Trap: "we will use dummy data." Better: name a real source. data.gov.in, the ministry's published reports, Bhuvan for anything geospatial. Where live access is restricted, say you generated a realistic schema modelled on the official format.

"What happens when your model is wrong?"

Trap: claiming it will not be. Better: say what a false positive and a false negative each cost in this context, and what the system does about it. A human check, a confidence threshold, a fallback. Knowing your failure mode reads as maturity.

"Why this team?"

Trap: "we are all good at coding." Better: four people who can each name a different job beat six who all do the same one. The jury is estimating whether you survive 36 hours together, not whether you can write code.

"What will you NOT build?"

Trap: saying you will build everything in the statement. Better: name what is out of scope and why. Teams that can draw a boundary look like they have actually planned; teams that promise everything look like they have not started.

"How does this scale beyond your pilot?"

Trap: "it is on the cloud so it scales." Better: talk about the non-technical scaling. Who onboards the next district, what training is needed, what breaks when the language or the terrain changes.

"Who pays for this after the hackathon?"

Trap: "it is free." Better: name the owner. Usually the department that raised the statement, sometimes an existing scheme budget. Even a rough answer beats no answer, because it shows you thought past the demo.

"What if the user has no smartphone?"

Trap: assuming everyone has an Android phone and data. Better: SMS, IVR in the local language, a shared device at the panchayat, or a village-level operator. For most rural statements this single answer separates you from the room.

"How is this different from what the ministry already does?"

Trap: not knowing what they already do. Better: name the current process and where it breaks. Usually it is reactive, paper-based, or delayed. Say what yours changes about that specifically.

"What is your accuracy?"

Trap: quoting a number you cannot defend. Better: say what it is on your test set, on how many samples, and where it fails. An honest 82% with a known weakness beats an unverifiable 99%.

"Show me the hardest part of this."

Trap: showing the login page or the dashboard. Better: know in advance which part is genuinely difficult and go straight to it. Juries ask this to find out whether you built it or assembled it.

"What did you build and what did you use?"

Trap: implying you built everything from scratch. Better: be straight. Pretrained model, fine-tuned on our data. This API for maps, this one for messaging. Using existing tools is not a weakness; pretending you did not is.

"What happens if the internet goes down?"

Trap: not having thought about it. Better: offline-first storage that syncs when the connection returns. For most rural or disaster statements this is not an edge case, it is the normal condition.

"Who maintains this after you graduate?"

Trap: "we will keep working on it." Better: documentation, a public repo, and a handover path to the department or the next batch. Nobody expects a business plan, they want to see you thought about it.

"Give me one number that proves the impact."

Trap: listing five metrics. Better: one figure they could write down. "Cuts the reporting delay from three weeks to a day." Teams that list five give the jury nothing to remember.