Smart India Hackathon 2026
All 236 Problem Statements

Shortlist five to ten statements that interest the whole team, then score each from 1 to 5 on these questions. Add the scores and discuss the top three.

Read the full statement, not only its title, and note every constraint it mentions - the users, the environment, the budget. Ideas that ignore a stated constraint are easy to reject.

A strong team covers every part of the project, not just coding. Useful roles:

• Problem owner - knows the statement best, talks to users, keeps the team honest about what is actually needed.
• Builders - software, hardware or both, depending on the statement.
• Data or systems person - datasets, cloud, integration, testing.
• Designer and presenter - the slides, the demo flow and the pitch.

Agree early on who decides when the team disagrees, and meet at a fixed time every week. Most teams that fall apart do so because nobody owned the deadline.

Use the official template exactly as given; changing its layout can count against you. Within it, every slide should answer one question clearly:

1. What is the problem, and who has it? Use the statement's own words, then one concrete example.
2. What is your solution? One sentence first, then the key features.
3. How does it work? A block diagram or flowchart: inputs, processing, outputs. Name the technologies.
4. Is it feasible? What you have already built or tested, the risks, and how you will handle them.
5. Who benefits, and how much? Users, cost, time saved - with numbers where you can.
6. What is your evidence? References, datasets and prototypes that back up your claims.

Judges see hundreds of decks. Short sentences, one diagram per idea and a clear title on every slide make yours easy to understand in the minute they have.

• Build the riskiest part first. If the idea depends on a sensor working outdoors or a model being accurate, prove that before anything else.
• Keep a demo that always works. Tag a stable version and never break it; develop new features on a copy.
• Record your results. Photos, videos, test logs and measurements are what make a feasibility claim believable.
• Practise the demo. Time it, rehearse the questions judges are likely to ask, and plan what you will do if the network or a device fails.

Hardware teams: the SchemFlow tool is useful for annotated circuit diagrams in your slides, and the Embedded C from Zero course covers the firmware skills most hardware statements need.

• Picking a statement because its title sounds exciting, without reading the details.
• Proposing a feature list instead of a solution to the stated problem.
• Claiming results the team has not measured.
• Leaving the presentation to the last night.
• Relying on a single team member who knows how everything works.