Smart India Hackathon (SIH) 2026: Winner's Playbook
Direct step-by-step companion guide for SIH 2026: three real SIH winning PPTs free to download, SPOC rules, dream team blueprint, problem statement filters, PPT checklists, and 26 jury questions across two rounds, each with the trap answer and the one that works, by SIH winner Zaid Sayyed.
Over 80% of teams get eliminated before writing a single line of code — mostly by missing college SPOC dates, picking the wrong 6-person team, or selecting dead problem statements.
Tap any topic below to unlock the exact checklists, testing simulators, and templates. Looking for the jury questions? Sixteen are in topic 07, and topic 08 adds ten more that arrive sideways after the demo. Each one carries the answer most teams give and the one that actually lands.
Tournament Funnel & SPOC Gateway
How college SPOC nomination, campus internal rounds, and national screening work.
Building the 6-Person Dream Team
Role distribution for 2026 AI problems, avoiding the 6-coder trap, and 24h teammate vetting.
Problem Statement Selection Strategy
Official AICTE evaluation rubric, avoiding dead PS, and the 6-point viability calculator.
The 3-W Solution Architecture Blueprint
Deconstructing ministry problems into Who, What, and Outcome without falling into the Feature Trap.
The Top 10+ Free Developer Tools Vault
Curated free tools for System Architecture diagrams, instant UI scaffolding, official datasets, and grand finale backups.
College Internal Hackathon & Top-45 Cutoff Strategy
The 45-team AICTE quota math, faculty vs jury psychology, 7-day action plan, 10-second live mockup hack, and viva defense sheet.
What the jury asks after the internal round
Screening and Grand Finale questions, each with the answer most teams give and the one that actually lands.
The internal jury is faculty deciding whether to nominate you. This one is a ministry officer and an industry evaluator deciding whether the thing could actually be deployed. Read these out loud with your team, not in your head.
01“Walk me through what changed since we last saw you.”
Trap: Repeating the same pitch you gave four hours ago.
What works: Evaluators visit the same table three or four times across the 36 hours and they are comparing against their own last note. Show the delta. What was broken at the last visit, what works now. Teams that replay the intro every round look like nothing is moving.
02“Show me this running. Not the slides.”
Trap: Opening the PPT and starting from slide one.
What works: Demo first, sixty seconds, on the thing that actually works. Slides only if they ask. At the finale everyone has a deck and very few have something running, so leading with the deck puts you in the wrong pile immediately.
03“Which of our existing systems would this have to talk to?”
Trap: Not knowing the department already runs software.
What works: Name their actual portal or database, then say how you would connect. A REST integration, a nightly CSV export, whatever is realistic. Even naming the system correctly puts you ahead of most of the room.
04“What is the smallest version we could deploy next month?”
Trap: Describing the full vision again.
What works: Name a pilot with a boundary. One district, one depot, one crop, fifty users. Officials are mentally costing a pilot, not a platform, and a team that can scope one sounds like a team that has shipped before.
05“Who inside the ministry owns this on day one?”
Trap: Saying "the government" or "the ministry."
What works: Name the department that raised the statement and the role that would run it day to day. A block officer, a depot supervisor, a district nodal officer. Ownership is the first thing that kills real projects and they know it.
06“What law or policy does this have to comply with?”
Trap: Never having thought about it.
What works: Name one that genuinely applies and what you did about it. The DPDP Act if you touch personal data, sector rules if it is health or finance. One specific answer beats a general promise to be secure.
07“Where does the data sit, and who can see it?”
Trap: "It is on the cloud."
What works: Say the region, say the access model, say what is anonymised. Government data usually cannot leave India, and a team that already knows that reads as deployable rather than academic.
08“What does this cost to run for a year at state scale?”
Trap: "Cloud is cheap" or a number with no working.
What works: A rough figure with the biggest line item named. Inference, storage, SMS, whatever dominates. Being roughly right with your reasoning visible beats a confident number you cannot break down.
09“You have not spoken yet. What did you build?”
Trap: The team leader answering on their behalf.
What works: Finale juries split teams on purpose. Every member should be able to explain their own module and the one next to it. One person answering everything is read as one person having done everything.
10“Twelve other teams picked this statement. Why yours?”
Trap: Listing features.
What works: Name the single thing only you did. Usually it is a constraint you took seriously that others ignored: it works offline, it runs on a four year old phone, it handles the local language. One sharp difference is remembered, a feature list is not.
11“This works on your laptop. What breaks in the field?”
Trap: "Nothing, it is production ready."
What works: Name three real failures and what you do about each. Bad network, a device with no GPS, a user who enters garbage. Nobody believes a 36-hour build is bulletproof, so claiming it is costs you more than the flaws would.
12“How long does it take one worker to learn this?”
Trap: "It is intuitive, anyone can use it."
What works: Give a number and the assumptions behind it. Ten minutes if they can read the local language, one afternoon if training is needed. Adoption is where most government software dies and the officials in the room have watched it happen.
13“What did you get wrong and change during these 36 hours?”
Trap: "Nothing, it went exactly to plan."
What works: One real pivot and what triggered it. The model was too slow so you cached, the API was down so you switched sources. Nothing goes to plan in 36 hours, so the perfect answer reads as either untrue or unaware.
14“Open the code for the feature you just showed me.”
Trap: Hunting through folders while they watch.
What works: Have the repo open in a second window and know where things live. This question is not about code quality. It is a check on whether the demo is connected to anything.
15“How much of this is from an existing open source project?”
Trap: Saying none of it.
What works: Name what you used, the licence, and what you actually wrote. Everyone builds on something and evaluators can search. Being caught overstating your part is fatal in a way that using a library never is.
16“If we gave you three months and a budget, what would you fix first?”
Trap: "Add more features."
What works: Name the weakest part of your own system honestly. It is the last question of the round and it is a maturity test. A team that knows exactly where its work is thin is the team you would fund.
The ten questions nobody prepares for
Not from your slides. These come sideways, usually right after the demo, and they are where confident teams come apart.
That is what makes them dangerous. The wrong answer is the one that comes out naturally under pressure, and it is usually a version of claiming everything is fine. Say these out loud with your team until the second answer is the reflex.
01“How much of this did AI write?”
Trap: "We wrote everything ourselves."
What works: Say it plainly: this part is a pretrained model, this is an API, this logic we wrote. Nobody in that room is against AI in 2026, they are against being lied to. One caught claim puts every other slide back under suspicion, and they can usually tell within a minute.
02“This is a wrapper on somebody else's API. What is actually yours?”
Trap: Getting defensive, or listing the UI as the contribution.
What works: Agree with the premise, then name the part that took real work. The routing logic, the domain rules, the offline fallback, the dataset you cleaned. Almost everything at the finale sits on top of something. The teams that lose here are the ones that pretend otherwise instead of pointing at their own layer.
03“What is your accuracy, and how did you measure it?”
Trap: A round number with no test set behind it.
What works: Give the number, the size of the set you tested on, and where it fails. "About 87 percent on 400 samples, and it drops on night images." A modest number you can defend survives; a 99 percent claim invites one counter-example that ends the conversation.
04“Show me your data. Where did it come from?”
Trap: "We used dummy data."
What works: Name real sources out loud: data.gov.in, the ministry's own reports, Bhuvan for anything geospatial. If live access needs government clearance, say you generated a realistic set modelled on the official schema and show the schema. The word dummy ends the discussion with every evaluator.
05“We tried something like this before and it did not work. Why is yours different?”
Trap: Assuming they are wrong, or that nothing existed before you.
What works: Ask what failed, then answer that specific failure. Usually it was adoption, not technology. Officials asking this are not testing your code, they are testing whether you understand that the hard part was never the building.
06“Who runs this after you graduate?”
Trap: "We will maintain it."
What works: Six final-year students is not a maintenance plan and they know it. Say what makes it survivable instead: documented setup, standard stack their existing vendor can pick up, open source under a permissive licence, handover docs. Sustainability is scored more often than teams expect.
07“Half the people who need this do not have a smartphone. Now what?”
Trap: "They can use the website."
What works: Give the fallback that already exists in your design. An SMS or IVR path, a shared operator device at the block office, a paper form somebody else enters. Government statements almost always carry a last-mile problem, and the team that already noticed it reads as the team that read the statement properly.
08“How would somebody cheat this?”
Trap: "They would not, it is secure."
What works: Name a real abuse case and your check for it. Fake entries for a subsidy, one person marking attendance for six, a photo taken from a different location. Anything with money or benefits attached will be gamed, and evaluators want to see that you thought about the person misusing it, not only the person using it.
09“Who pays for this once the pilot money is over?”
Trap: Talking about subscriptions and paying users for a government system.
What works: For a ministry statement the honest answer is a departmental budget line, and your job is to make it small. Say what one district costs to run per year and what the department stops paying for in exchange, usually manual survey or inspection time. Cost saved is the language of that room.
10“Explain it to me as if I am the person who has to use it, not a judge.”
Trap: Repeating the pitch with the same technical words in it.
What works: Drop every acronym and describe one person's day. "The inspector opens the app at the site, takes one photo, and the report reaches the district office before he leaves." This question is checking whether you have ever pictured a real user, and most teams visibly have not.
About five teams per statement go forward nationally. On a statement that fills its cap that is five out of five hundred, and the round deciding it never sees your code, your demo or your team. It reads six slides and nothing else.
- The four things a screening evaluator checks on each slide, in the order they read them
- The feasibility slide most teams get wrong, and the version that survives
- How to write a references slide when your statement ships no dataset
That breakdown is a sheet I keep on Topmate, written the same way these questions are: the answer most teams give, then the one that works.
500 ideas, 5 seats: the PS survival sheetThe idea submission deck, slide by slide
What a screening evaluator looks for on each of the six slides, and the eight mistakes found in real 2026 decks this season.
There is no jury to convince, no demo to save you and no chance to explain what you meant. Six slides are read, and roughly five teams per statement go forward. This is why a stronger team regularly loses to a team that wrote a clearer deck.
01Title page
What it is read for: Your metadata, against the portal's own record.
Trap: Template text left in place — TO BE UPDATED where the team ID goes, IDEA TITLE where your idea name goes — and a theme typed from memory instead of copied from the portal.
What works: Open the statement page and copy the ID, title, theme and category across character by character. A wrong theme on slide one is the cheapest mark you will ever lose, and it is read before a single sentence of your idea.
02Proposed solution
What it is read for: Whether you understood this statement or a general version of it.
Trap: A description that stays true if you swap the state, the ministry or the domain. "Unified platform combining AI and data for better decisions" describes four hundred other submissions.
What works: Name the specific condition that made the ministry raise this. One monsoon, one district with a single road in, one crop, one queue. The test is simple: replace the place name with somewhere else. If the slide still reads fine, it is not about your statement yet.
03Technical approach
What it is read for: Whether a real system exists behind the diagram.
Trap: A stack that lists HTML, CSS and JavaScript, plus a box labelled AI/ML layer. That is a category, not a choice, and it reads as a team that has not built yet.
What works: Name what you actually run. The model, the library, the database, the routing engine. Specific names are checkable, and being checkable is the whole signal here. A boring stack you can defend beats an impressive one you cannot.
04Feasibility and viability
What it is read for: Whether you know where your own idea is weak.
Trap: Listing only reasons it will work. A slide with no risks on it does not read as confidence, it reads as a team that has not thought past the demo.
What works: Three real risks with what you do about each. Data you cannot get, accuracy that drops in bad conditions, adoption by people who did not ask for this. This is the slide most teams treat as filler and it is the one that separates two decks with the same idea.
05Impact and benefits
What it is read for: Whether the benefit is measurable or just adjectives.
Trap: Better, faster, improved, enhanced. Six boxes of comparatives with nothing underneath them.
What works: One number with your working shown. Hours saved per inspection, rupees per district per year, kilometres of road covered. A rough figure you can explain lands harder than a confident claim nobody can check.
06Research and references
What it is read for: Whether your data plan is real or deferred.
Trap: Entries that name nothing: government datasets, research literature. Framework documentation counted as research. Notes to yourself left printed on the slide.
What works: Named sources with links. data.gov.in, Bhuvan, the ministry's own annual report, the department that raised the statement. If access needs permission, say so on the slide and say what you are using meanwhile. Deferring the data question is what makes an evaluator assume there is no answer.
Every line below came off an actual submission I was sent this month, from teams that had done real work. Check yours against it before anything else.
- Placeholder text still on the slides: TO BE UPDATED, IDEA TITLE, YOUR TEAM NAME.
- A theme on slide one that does not match the portal's theme for that statement.
- A slide belonging to a different project entirely, pasted in by an AI tool that misread the idea's name.
- A duplicated slide, so the deck runs seven pages where the template gives six.
- A note to yourself left visible: verify these references before submission.
- A title box wide enough to run off the slide, cutting the first word in half.
- A full map of India used on a statement about one region, showing nothing about that region.
- A live demo on a free host that sleeps, so the first person to open it sees a blank page.
SIH winning PPT examples, free to download
Three real Smart India Hackathon 2025 idea submissions, the same six-slide format SIH 2026 uses. No form, no Drive request.
A folder of 300 winner decks looks generous and teaches nothing, because nobody opens 300 files and a pile that size hides the one thing worth noticing. Here it is: all three of these take the feasibility and viability slide seriously, and almost no losing deck does. Most teams write the word scalable there and move on. These three use it to answer the jury before the jury speaks, each in a different way.
- PPT 1SIH25070 · Miscellaneous · Software
Secure Data Wiping for Trustworthy IT Asset Recycling
Team Niet - SafeSecure
What to take from it: Every risk sits next to its own mitigation. The USB might not boot on some machines, and the slide says so before anyone can ask, then says what happens instead. Naming your own weak point is what makes the rest of the deck believable.
Open PPT 1 · PDF 5.4 MB - PPT 2SIH25175 · Space Technology · Software
MAITRI: An AI Assistant for the Well-Being of Astronauts
Team Zillion Minds
What to take from it: A "What ifs" block: five ways the system could fail, each with the fallback written underneath. What if the AI misreads an emotion, what if the hardware dies mid-mission, what if the astronaut refuses to use it. These are the questions a jury asks out loud, answered before they get the chance.
Open PPT 2 · PDF 2.5 MB - PPT 3SIH25071 · Disaster Management · Software
AI-Based Rockfall Prediction and Alert System for Open-Pit Mines
Team TechPioneers
What to take from it: Splits feasibility into technical, economic and operational instead of treating it as one word, then lists the problems it has not solved yet, data scarcity and false alarms, and follows with a business model. The most complete structure of the three and the easiest to adapt to any statement.
Open PPT 3 · PDF 2.3 MB
Questions I actually get asked
These come from DMs and mentoring calls, not from a list of what people search for. They are the ones that repeat.
"I'm a first year with no coding background. Can I still do SIH? Can I use AI to build the prototype?"
Yes to both, and the second one is not cheating — most teams in 2026 are using AI to build. Juries do not ask how you built it. They ask whether it works and whether you understand the problem.
But the real risk for a first year is not losing SIH. It is getting cut from the team before SIH starts. Teams are six people, seniors form them quickly, and the first person dropped is always the one who "will learn later."
So do not try to become a competitive coder in three weeks — you will lose that comparison to a third year. Own a job most teams are missing and nobody volunteers for:
- Domain research. Actually read the full statement, find the ministry's own reports, understand why the problem exists. Almost no team does this, and it shows the moment a juror asks why it matters.
- Documentation and slides. Teams with working code still get rejected here.
- Demo operator. Be the person who makes sure it runs on the day. Teams lose rounds to laptops, not to logic.
One thing that works better than it should: pick three statements, read them completely, and write one page on each about who suffers from that problem today. Show that page to any team you approach. Nobody does this, and it makes you visibly useful before you have written a line of code.
"How many teams does my college send forward?"
The ceiling is 45 nominations — 30 software, 15 hardware — and most colleges do not fill it. The practical shape at a mid-size college is closer to forty teams registering, about half actually submitting, and a handful going forward.
That makes the internal round the steepest cut in the entire process, and it happens before SIH has technically begun. Most people spend their preparation on the finale and improvise the round that actually eliminates them.
"Should we pick a hardware or a software statement?"
Hardware statements have a smaller field, which sounds like an advantage and sometimes is. But they are unforgiving: you cannot fake a sensor at 3am, components have delivery times, and a prototype that does not physically work has nowhere to hide.
Pick hardware only if someone on the team has actually built with the components before. "We'll learn Arduino" is not a plan at this stage.
"Everyone is picking the popular statements. Should I avoid them?"
Partly. The statements that read as easy attract the most teams, so you compete against the largest field with the least differentiation.
But do not swing to the opposite extreme and pick something impossible just because it is empty. The question is not popular versus obscure — it is whether your specific team can ship a convincing version of it in thirty-six hours.
That is the actual filter, and it is why the problem statement matcher scores statements against your team's real skills rather than against how impressive they sound. It also tells you which skill you are missing, which is usually the fact that decides it.
If you would rather browse than search, the statements are split across seventeen themes, and each theme page shows how crowded it is and which statements nobody has picked yet. The biggest are smart automation with 55, blockchain and cybersecurity with 31, agriculture, foodtech and rural development with 27, disaster management with 25 and MedTech, BioTech and HealthTech with 20. The quieter ones are worth a look for the same reason everyone ignores them: space technology, robotics and drones, transportation and logistics and clean and green technology.
Where you are in the timeline
SIH moves in phases, and advice that is useful in one phase is noise in another:
- Team formation — six members, and the constraints are real. Sort this before you fall in love with a statement.
- Problem statement selection — the decision with the longest tail. Get it wrong and everything after is harder.
- College internal round — the steepest cut. Covered in detail in the internal round playbook.
- Screening and submission — where preparation stops being about code.
- Grand finale — thirty-six hours, and by then the outcome is mostly already decided.
If you are reading this during internals, skip ahead to the playbook. The rest of this page will still be here afterwards.
SIH 2026: the questions everyone asks
The official portal covers what and when. These are the answers you only get from someone who has been through it.
What is the prize money for SIH 2026?
Each winning team receives ₹1,00,000 per problem statement at the national level, and popular editions have carried ₹1,50,000 for some categories. One winner is declared per problem statement, and a few statements declare joint winners, so the exact pool depends on the statement you pick. Treat the money as a bonus though. The thing that changes your career afterwards is the credential and the people you meet at the finale, not the cheque.
What is the last date for SIH 2026 idea submission?
30 September 2026 for the portal submission. The team leader has the portal login and submits the idea, but the team still has to be nominated by the college SPOC through the internal hackathon first, so your real deadline is your own college's. Most colleges run internals through September, which usually puts it two to three weeks earlier than the portal date. Find out your internal deadline before you plan anything else around 30 September.
How many members are allowed in an SIH team?
Exactly six, including the team leader, and at least one member must be female. All six have to be from the same college, though they can be from different departments. Teams of four or five are not accepted at the national level even if your college allows smaller teams internally. You may also add up to two mentors with five or more years of experience.
Can first year students participate in SIH?
Yes, and it is one of the best moves a first year can make. The real risk is not losing the hackathon, it is getting dropped from a team before it starts, because seniors form teams quickly and the first person cut is always the one who will learn later. Own a job nobody else volunteers for: domain research, the presentation, or being the person who makes sure the demo runs on the day.
Should we pick a software or a hardware problem statement?
Hardware has a smaller field, which sounds like an advantage and sometimes is, but it is unforgiving. You cannot fake a sensor at 3am, components have delivery times, and a prototype that does not physically work has nowhere to hide. Pick hardware only if someone on the team has actually built with those components before. In 2026 there are 182 software and 58 hardware statements.
What is a SPOC in Smart India Hackathon?
The Single Point of Contact, a faculty member your college nominates to manage its entire SIH participation. The SPOC registers the institution, runs the internal hackathon and nominates the teams that go forward. Your team leader has the portal login and submits the idea, but the nomination has to come through the SPOC first. If you do not know who your college SPOC is, that is the single most urgent thing to find out, because no submission counts without going through them.
Is the internal hackathon compulsory for SIH?
Yes. Only teams selected through their institution's internal hackathon can be nominated. Colleges can nominate up to 45 teams, 30 software and 15 hardware, and most do not fill that quota. This is the steepest cut in the whole process and it happens before SIH has technically begun, which is exactly why most teams prepare for the wrong round.
How many teams get selected for the SIH Grand Finale?
Roughly five teams are shortlisted per problem statement nationally. On a popular statement that can mean 500 submissions competing for those five seats, decided entirely by your idea PPT with no jury to convince and no demo to save you. On a quieter statement the same five seats are contested by far fewer teams, which is why statement selection matters more than most teams realise.
What actually happens at the SIH Grand Finale?
Thirty-six continuous hours of building at a nodal centre, usually in another city, with evaluators visiting your table three or four times. They compare against their own notes from the previous visit, so what matters is visible progress between rounds, not one polished demo at the end. Most teams underestimate how much the presentation and the questions decide the result compared to the code.
Can we use AI tools and pretrained models to build our SIH project?
Yes, and most teams in 2026 do. Juries do not ask whether you used AI, they ask what you built and what you used, and they can tell. Say it straight: pretrained model, fine-tuned on our data, this API for maps, this part we wrote. Using AI is not the weakness. Hiding it is, because one caught claim puts every other slide in doubt.
Where do we get datasets for our SIH problem statement?
Some statements ship a dataset link, most do not. Name real sources rather than promising to find data later: data.gov.in, the ministry's own published reports, Bhuvan for anything geospatial. Where live access needs government permission, say openly that you generated a realistic dataset modelled on the official schema. Saying dummy data ends the conversation with any evaluator.
Is Smart India Hackathon worth participating in?
For the win, the odds are long and honest about it. For everything else, it is the highest-leverage thing an Indian engineering student can do with a month. You end up building something real under a deadline, presenting to people who evaluate for a living, and meeting a national cohort. Even teams that lose at internals come out with a project, a team, and a story that survives interviews.
What happens after you win Smart India Hackathon?
The prize money arrives, the certificate arrives, and then nothing arrives unless you build on it. What actually compounds is what you do with the credential in the following months: writing about it, mentoring teams, speaking, and shipping the project further. The win opens doors, it does not walk you through them.
What questions does the SIH jury ask?
Far fewer technical ones than teams expect. At the college internal round the panel is faculty deciding whether you are worth nominating, so they push on scope, effort split and whether the demo is real. At screening and the Grand Finale it is a ministry officer and an industry evaluator, and they ask who owns this on day one, where the data sits, what it costs to run for a year, what breaks in the field, how much of it AI wrote, and who maintains it after you graduate. The pattern is that they are testing whether the thing could be deployed, not whether the code is clever.
How is the SIH idea submission PPT evaluated?
By reading, not by watching. Nobody presents at the screening round and nobody sees your demo, so the six-slide idea submission has to survive on its own with no one there to explain it. Evaluators are scanning many submissions per statement for whether the problem is understood, whether the approach is specific rather than generic, and whether the feasibility slide shows real constraints instead of promises. This is why a technically stronger team often loses to a team that wrote a clearer deck.
How many slides is the SIH idea submission PPT?
Six. Title page, proposed solution, technical approach, feasibility and viability, impact and benefits, and research and references. The format is fixed, and going over it invites a formatting objection to decide something your idea should decide. If a section is spilling onto a seventh slide, the answer is to cut, not to add a page. You can check your own deck against the template for free on the problem statement tool.
What are the most common mistakes in an SIH idea PPT?
The ones that cost marks are unglamorous. Template placeholder text still on the slides, so the deck reads as unfinished. A theme on slide one that does not match the portal listing for that statement. A duplicated slide nobody deleted. A note to yourself left visible. References that name no actual source, just the words government datasets or research literature. And a demo link on a free host that sleeps, so whoever opens it cold sees a blank page. None of these are about your idea, which is exactly why losing marks to them stings.
How is SIH 2026 different from previous editions?
The 2026 edition carries 240 problem statements across 17 themes, with a strong tilt toward AI and applied automation, and a visible increase in statements from state governments and PSUs rather than only central ministries. Statements are still being added through September, so the count you saw when the board opened is not the count today. The other real change is that evaluators now expect you to be explicit about which parts of your build are AI-assisted.