Smart India Hackathon: Problem-Statement Analysis, Team Roles and the 36-Hour Build Plan

The Smart India Hackathon (SIH) is India's largest student hackathon — tens of thousands of students, problem statements sourced from central ministries, state departments, PSUs and industries, and a grand finale where software teams build for roughly 36 continuous hours (the hardware edition runs about five days). The teams that walk out with prizes are rarely the most talented in the room. They are the most prepared: they chose a problem statement they could actually finish, they froze their stack weeks earlier, and every one of the six members knew exactly what they owned from hour zero.

This guide is the preparation system — what the format actually demands, how to read a problem statement like a contract, how to score and shortlist statements, how to split six people across 36 hours, and how to demo like a team that expected to win.

How SIH actually works: the pipeline before the finale

SIH is not a walk-in event. The pipeline typically runs:

1. Problem statements released — usually 200+ statements across themes (agriculture, healthcare, education, governance, security, smart cities, and more), each carrying an organisation name, a category (software or hardware), and a contact detail.
2. Internal hackathon at your college — your institute runs its own shortlisting round. Only the top teams per institute go forward, so your first competition is your own classmates.
3. Team submission on the SIH portal — a team of exactly six students plus up to two mentors, with at least one female team member (this is a stated SIH rule — plan your team composition from day one, not the night before submission).
4. Shortlisting by the problem-statement organisation — the ministry or company that posted the statement reviews submissions and picks the teams it wants at the finale.
5. The grand finale — software teams get roughly 36 hours at a nodal centre; hardware teams get about five days. Judging happens through periodic mentor evaluations plus a final demo and pitch.

The critical insight: the internal hackathon is where most teams die. Colleges can nominate only a limited number of teams, so a decent idea with a sharp 10-minute internal pitch beats a brilliant idea presented as a rambling slide deck. Treat the internal round as a real competition — it is one. The guide to splitting group project work covers the team-coordination mechanics that matter just as much here.

Reading a problem statement like a contract

A problem statement is not a suggestion — it is the judging rubric in disguise. Before you fall in love with an idea, dissect the statement line by line:

• Who posted it, and what do they actually do? A statement from the Ministry of Agriculture about crop disease will be judged by people who know farming, not by people who know transformers. Your solution must speak their language: yield loss, mandi prices, field conditions — not just model architecture.
• What is the stated expected outcome? Some statements ask for a working prototype; others for a data analysis or a design. Match your deliverable to the expected outcome exactly.
• What constraints are hiding in plain sight? "Should work in areas with intermittent connectivity" means offline-first is mandatory, not a nice-to-have. "For use by field workers" means it must run on low-end Android phones, not your MacBook. "Multilingual" means you need at least Hindi + English from day one.
• Is data available? A statement asking for prediction without any mention of data sources is a trap unless you already know where the dataset comes from. If the statement says "data will be provided," verify what that means — sample size, format, access timeline.

Write a one-page "statement brief" for each candidate: the organisation, the real user, the expected outcome, the hidden constraints, the data situation, and your honest 36-hour scope. Teams that do this for 4–5 statements pick better than teams that brainstorm ideas first and hunt for a matching statement later.

The problem-statement scoring matrix

Score each candidate statement 1–5 on these six criteria, multiply by the weights, and shortlist the top two:

Criterion	Weight	What "5" looks like
36-hour feasibility	×3	Core demo buildable in ~24h with your current skills; no research-grade unknowns
Data availability	×2	Dataset identified or obtainable this week; no "we'll figure out data later"
Differentiability	×2	You can name the one thing judges will remember; not a generic CRUD app with a chatbot taped on
Domain fit	×1.5	At least one team member understands the domain (farmer in the family, internship in healthcare, etc.)
Judging clarity	×1.5	You can state in one sentence how a judge verifies it works
Reuse value	×1	The build can become your final-year project or a paper afterward

Two rules of thumb from watching multiple SIH cycles:

1. Feasibility beats ambition. A finished, polished, slightly boring solution outscores an ambitious half-built one every single time. Judges score what they can see working.
2. Beware the "AI will solve it" statement. Statements that invite ML solutions are the most crowded category. Unless your team has real ML chops (not just API calls to a hosted model), a well-engineered software solution in a less crowded lane often places higher.

Callout: shortlist two statements, not one. Organisations shortlist teams, not the other way around — your first choice may not pick you. Have a strong second choice with a different tech angle so one rejection doesn't restart your preparation from zero.

Freezing your tech stack: decide now, not at hour 3

The single biggest time sink at hackathons is stack debate at the venue. Freeze the stack at least two weeks before the finale and build one small prototype end-to-end with it. The decision table:

Build type	Recommended stack	Why
Web dashboard / portal	React (Vite) + Node/Express + a hosted DB	Fastest to scaffold, everyone knows it, deploys anywhere
Mobile-first (field workers, citizens)	Flutter or React Native	One codebase, runs on the judges' phones for the demo
ML-heavy statement	Python (FastAPI) backend + simple React frontend	Keep the frontend thin; the model is the demo
Data visualisation	React + a charting library + static hosting	Judges love a dashboard that updates live
Hardware-adjacent	ESP32/Arduino + a minimal web dashboard	Only if the statement is hardware-category; software teams should not add hardware scope

Non-negotiable tooling decisions to make now:

• Version control: one GitHub repo, main protected, one branch per person or per feature. Everyone should have completed the Git and GitHub workflow guide before the finale — hour 12 is not the time to learn what a merge conflict is.
• Communication: one channel for code, one for decisions. Decisions made in voice calls must be written down in the channel within 10 minutes or they didn't happen.
• Deployment target: decide where the demo will run (Vercel, Render, a VPS, or a local laptop as server) and do one full deploy of a skeleton app before the finale. Deployment surprises at hour 34 are how demos die.

The team of six: roles, not just people

Six developers with no roles is a crowd. Six people with clear ownership is a team. The roles that work:

Role	Owns	Anti-pattern to avoid
Backend lead	APIs, database schema, auth	Rewriting the schema at hour 20
Frontend lead	UI, demo flow, the screens judges see	Pixel-perfecting page 6 while page 1 is broken
ML/data person (if needed)	Model or data pipeline, evaluation numbers	Training a model from scratch instead of using a solid baseline
Integrator	Wiring frontend↔backend, the end-to-end happy path	"It works on my machine" with no deployed integration until hour 30
Pitch + docs lead	Slide deck, 5-minute script, README, submission write-up	Starting the deck at hour 35
Floater / QA	Testing, bug-hunting, second pair of hands wherever the fire is	Floating so much they own nothing — give them explicit QA checklists

Notes that matter:

• The pitch lead is a full-time role in the last 8 hours, not a side task. A great build with a confused pitch loses to a good build with a crisp pitch.
• Cross-train at least two people on deployment. If only one person can deploy and they fall asleep at hour 28, you have no deploy pipeline.
• For idea-stage help, the computer-science project ideas guide is useful for scoping what a 36-hour build can realistically contain — many SIH builds map directly onto final-year project topics.

The 36-hour build plan

This is the schedule winning teams roughly follow. Adjust the hours to your strengths, but keep the phase boundaries sacred — especially the integration freeze.

Hours	Phase	What happens	Done means
0–2	Setup sprint	Repo, skeleton app, DB, deploy pipeline, hello-world deploy	A URL that loads, even if it's an empty page
2–4	Scope lock	Final feature list: the 3 must-haves, 2 nice-to-haves, everything else cut	Written scope doc; no new features after this without cutting one
4–14	Core build	The must-have features, in parallel per role	Each feature works standalone
14–16	Integration #1	Wire everything together, first end-to-end run	The happy path works deployed, not just locally
16–26	Feature + harden	Nice-to-haves, error handling, the demo path polished	No crashes on the demo path; loading and error states exist
26–28	Integration freeze	No new features. Bug fixes only.	Feature branches merged or abandoned
28–32	Demo prep	Recorded backup video, pitch deck, README, submission form	Deck done, video recorded, form filled
32–36	Buffer + rest rotation	Sleep in shifts, final rehearsal, venue setup	Team rested enough to pitch coherently

Three rules that protect the schedule:

1. Deploy from hour 2, continuously. The team that deploys once at hour 34 discovers environment differences at hour 34. The team deploying every few hours discovers them at hour 6, when there's time to fix them.
2. The integrator runs the clock. When integration windows arrive, everyone stops feature work and helps integrate. No exceptions — a feature that isn't integrated doesn't exist.
3. Sleep is a strategy, not a weakness. Plan two sleep shifts (e.g., half the team sleeps hours 18–24, the other half 24–30). A team of zombies at hour 32 writes the bug that kills the demo at hour 35.

The 5-minute demo: what judges actually score

Judges at a nodal centre see dozens of teams. Your demo is 5 minutes if you're lucky. Structure it ruthlessly:

1. The problem (45 seconds) — one concrete user, one concrete pain. "ASHA workers in rural Maharashtra record patient visits on paper; 30% of records are lost or illegible" beats "healthcare data management is a challenge."
2. The solution (30 seconds) — what you built, in one sentence, shown on screen.
3. The live demo (2.5 minutes) — the happy path only. Three clicks, one wow moment. Narrate what you're doing and why it matters to the user.
4. The differentiator (45 seconds) — the one thing other teams didn't do. Offline mode, the evaluation numbers, the field test.
5. What's next (30 seconds) — deployment plan, what you'd build with 3 more months. Shows you think beyond the hackathon.

Handle judge questions with the answer-bridge-evidence pattern: answer directly, bridge to your strength, cite evidence ("Yes, it works offline — here's the sync queue, and we tested it with airplane mode on"). Never bluff on a technical question; "we didn't get to that, here's how we'd approach it" earns more respect than a confident fabrication.

Backup plans: the demo-gods insurance policy

Assume the venue WiFi will fail during your slot, because it fails for someone every year:

• Recorded demo video — a clean 2-minute screen recording of the full happy path, on two devices plus a USB drive. If the live demo fails, you switch to the video in under 30 seconds and narrate over it.
• Offline mode — if your app needs the internet, build a local fallback: seeded demo data, a local server on your laptop, or a mobile hotspot from two different networks.
• Dummy-data toggle — a ?demo=1 mode that loads perfect sample data instantly, so you're never waiting on a slow API during the pitch.
• Hardware spares — for hardware teams: duplicate of every sensor, pre-flashed boards, printed circuit diagrams. Debug at the venue with spares, not with hope.

Rehearse the failure, not just the success: do one full rehearsal where someone unplugs the WiFi mid-demo and the presenter switches to backup without breaking rhythm.

What winning teams do differently

1. They scope like surgeons. Winners cut features in hour 4 without sentimentality. The question is never "would this be cool" — it's "does the judge need to see this to believe the solution works."
2. They pick the lane with the fewest strong teams. Crowded categories (generic AI chatbots) need a genuinely novel angle to place; a sharp solution in an unglamorous category (governance workflows, accessibility) often faces weaker competition.
3. They talk to the organisation's reality. The strongest pitches reference the actual department, its existing systems, and deployment constraints — it signals "we could actually ship this here," which is what the organisation wants to hear.
4. They have numbers. "Reduces data entry time from 8 minutes to 90 seconds, measured over 20 trial entries" beats "it's much faster." Even rough measurements beat adjectives.
5. They finish early. Winners are demo-ready by hour 30 and spend the last hours rehearsing and resting. Teams still coding at hour 35 are not "hustling" — they're gambling.

Common failure modes (and the fix)

Failure mode	Symptom at hour 30	Prevention
Scope creep	8 half-built features, nothing demoable	Written scope lock at hour 4; cut list maintained visibly
Integration cliff	Everything works locally, nothing works deployed	Deploy from hour 2; integration windows at hours 14 and 26
The single point of failure	Only one person understands the backend	Pair on critical paths; document setup in the README from hour 1
Demo-path untested	Works in dev, crashes on the judge's click	Rehearse the exact demo clicks 5+ times; record the backup video
Team friction	Silent members, duplicated work	Roles assigned before the finale; 15-minute standups every 6 hours
Pitch unprepared	"So... yeah, that's our project"	Pitch lead owns the deck from hour 20; rehearse out loud, timed

After the finale: don't let the build die

Win or lose, a 36-hour SIH build is raw material:

• Final-year project: a scoped, judged, working prototype is a strong project foundation. The project synopsis guide shows how to frame it for your department — you'll extend the SIH build with proper documentation, testing, and the features you cut at hour 4.
• Paper: if the solution has a novel angle or solid evaluation numbers, it can become a conference paper. Realistic examples of web platforms in this space — like a virtual study room built on WebRTC or an uptime monitor with an alert dashboard — show the level of completeness reviewers expect.
• Portfolio: a deployed URL, a 2-minute demo video, and a README that explains the problem in one paragraph will do more for placements than a certificate alone.

The preparation checklist

• Team of six fixed, with at least one female member; two mentors identified
• 4–5 problem statements dissected into one-page briefs; top two scored with the matrix
• Tech stack frozen; skeleton app deployed to the real demo target
• Git workflow agreed; everyone comfortable with branches and pull requests
• Roles assigned (backend, frontend, data/ML, integrator, pitch lead, floater)
• One full practice build: a weekend mini-hackathon running the 36-hour plan compressed into 12 hours
• Pitch deck template ready; 5-minute script drafted before the finale
• Backup kit packed: recorded demo video on two devices + USB, hotspot, chargers, extension board
• Internal hackathon pitch rehearsed — remember, that's the first real competition

The internal hackathon: your first real competition

Most SIH journeys end at the college internal hackathon, not the finale — institutes can nominate only a handful of teams. Treat it as a separate competition with its own strategy:

• The internal pitch is 10 minutes, not 36 hours. Judges (your faculty) score the idea, the team's seriousness, and feasibility. A crisp 8-slide deck — problem, users, solution sketch, tech stack, 36-hour scope, team roles — beats a half-built prototype with no narrative.
• Show preparation, not just ideas. Bring the one-page statement briefs, the scoring matrix, and the stack-freeze evidence (a deployed skeleton). Faculty nominate teams they trust to represent the college; preparation is the trust signal.
• Pick an internal-friendly problem statement. Statements from well-known organisations are easier for internal judges to evaluate than obscure ones. Save the exotic pick for when you're already shortlisted.

Using your two mentors well

SIH allows two mentors — usually faculty, sometimes industry. Most teams waste them:

• Before the finale: mentors review your scope and spot the infeasible ("you cannot train that model in 36 hours"). One scope-review session during prep is worth more than daily check-ins.
• During the finale: mentors can't code for you, but they can unblock — an architecture sanity check at hour 6, a pitch rehearsal at hour 30. Book two short slots in advance rather than grabbing them randomly.
• After: a mentor who watched you build is your strongest recommendation-letter source and a natural paper co-author. Keep them posted on what the build becomes.

The submission write-up: small text, big filter

The portal submission — team details, idea synopsis, approach — is what the problem-statement organisation reads before shortlisting. Write it like a grant application, not a chat message:

• Lead with the outcome, not the tech: "A field-worker app that records crop-disease reports offline and syncs when connectivity returns" — then the stack.
• Name the 36-hour scope explicitly: "MVP: report capture, offline queue, dashboard. Post-finale: multilingual support, analytics." This signals you understand the format.
• Proofread like it matters — for the shortlisting committee, this document is your team. Typos in a 300-word write-up suggest sloppiness in 36 hours of code.

SIH rewards the team that treats 36 hours as an execution exercise, not an ideation exercise. Do the thinking in the weeks before — the statement analysis, the stack freeze, the role assignments — so the finale is just typing.