Team SPD

I owe a bunch of people on LinkedIn an apology.

After we won Smart India Hackathon in December 2024, and again when SIH 2025 came around, people kept reaching out. Can you share your presentation? What helped you guys win? I never replied. Not to one of them. I don't have a great excuse — it was easier to keep moving than to write it all down. So, sorry. This is the answer to all of those DMs at once.

This is a participant's perspective. It's my hypothesis about why we won. I don't actually know which parts of what we did mattered most to the judges. What I have is the full story of what we did, and a guess about which parts were probably load-bearing.

2023: the year we didn't even make it past internals

The first time I tried to do SIH, I didn't make it out of our college's internal round.

Six of us — four boys, two girls — put together a team called SPD. We picked a problem statement, gave it a weird little name, wrote up a solution, drafted a tech stack, and drew what we thought a system architecture diagram should look like (a bunch of icons with arrows pointing in the directions data flowed, basically). We added some business angle. We did a decent job for first-timers.

I was off doing some student-entrepreneurship program at the time, so my team carried more than their share. And then, on submission day, I had to drop out before we could even submit.

Our college has two campuses. Half my team was on one, half on the other. There was a logistical thing where one of us had to step back, and I told Hemanth — who really, really did not want me to do it — that it was fine. We're friends. You win, we win. I pushed him into the room anyway.

They didn't make it. We weren't selected.

That sucked more than I expected it to. We had filled the slides. We had a proper-looking architecture diagram. We had business angle. We thought we'd done enough. We had not done enough. The gap between what felt like enough and what was actually enough is a thing I think about a lot now.

A few months before that, I'd become the lead of our college's first Google Developer Student Club. So coming off that high into a hackathon loss in our home college was a particular kind of demoralizing.

The year between

Then we went to our first external hackathon and lost two competitions in the same day. Then a Mumbai event, where we landed top 10. After Mumbai, something clicked. Over the next twelve months, the same four boys — me, Hemanth, Naveen, Harsha — won three hackathons.

One of those wins is how all four of us got our first jobs. The founder of Aegion Dynamic, the startup I still work at as a software engineer, was on the judging panel. We won the hackathon, he extended internships to all four of us. I'm still there.

So by the time SIH 2024 opened, we had three wins under us, real internships, a year of shipping side projects, and the kind of repaired confidence that only comes from actually winning a few. We weren't the same team that had failed to clear internals in 2023. We were materially different humans.

The lucky problem statement

We almost missed SIH 2024. One of our friends spotted that a problem statement on the SIH portal lined up almost exactly with a project we'd been building all year. Not a perfect match. The problem statement asked for a complete institution-management system. We had built a part of it — the classroom-management part. But the overlap was uncanny enough that we had a head start no other team in the country could have without doing a year of unrelated work first.

This is luck. Not skill. I want to be honest about that. The reason we even competed in the right problem-statement was that a friend happened to read one and connect it to something we were already doing.

Assembling team SPD

We kept the SPD name and rebuilt the full six. Six people, six different jobs:

Hemanth is the Flutter and mobile guy. Full-stack, in the sense that you can throw a web app or a back end at him and he'll ship it, but he sticks to mobile. Well-rounded, DSA-fluent.

Naveen is the AI guy. He built the custom face-recognition model that lets a teacher take attendance for an entire classroom by waving their phone camera over the room. He also built the agent system — multiple specialist agents for students, teachers, and administrators, with a real retrieval pipeline behind them, not a generic chat wrapper.

Harsha is the all-rounder. Mostly back end, hops onto the front end when we need an extra pair of hands, deeply into DSA. He and Hemanth grind LeetCode. Naveen and I do not.

Raghavi is our outside view. She finds resources, pulls business and market data, gives us the non-technical perspective our heads-down engineering brains lose track of. She is also the most useful presentation reviewer on the team, because she can tell when the narrative has gone weird in a way the technical people miss.

Amrutha is part-apprentice, part-presenter. She's slightly technical, learning under Hemanth, and contributes the second non-technical viewpoint that keeps the presentation honest. Two people on a team noticing the same thing about a slide is meaningfully different from one person noticing it.

Me. I'm an all-rounder by accident — a little technical, a little non-technical. My core technical job is web front end. The boys do not let me touch the back end most of the time, which is fair. My real differentiator is presentation. I have, for whatever reason, an American-inflected accent that has been useful at events in India in a way I find embarrassing to write about but cannot pretend isn't true.

I also have one other specialty. I'm the do-or-die debugger. When something breaks at a normal time, the boys fix it themselves. When something breaks five minutes before judges arrive at our table, I get to look at it for the first time, and somehow I can usually see the bug. I think it's because I've been outside their code all weekend, so I'm seeing it fresh while they're seeing it through the lens of a thousand small decisions they made in the last forty-eight hours. I don't know if that's a real skill or a story I tell myself, but it has worked enough times now that I'll take it.

The thing I want to flag about this team is that everybody can contribute to the presentation, and everybody can contribute technically in some direction. There's no person whose job ends at the slide deck and no person whose job ends at the code. The feedback loops run both ways. Raghavi will critique my presentation narrative; I will spot a bug Harsha can't see; Hemanth will rewrite a slide line because the technical claim was off. That collaboration is the actual moat.

What we put in the submission

The submission rules made you pick a problem statement, write a solution, fill a slide deck, and submit. We did all of that, and then some.

We filled the problem-statement slide exactly as required. We added a slide on what we understood the problem to be — explicitly, in our own words, separate from the problem statement we were given — so the judges could see we'd actually read it. We listed our solution as bullet points. We wrote out our own technological limitations honestly, and against each one, we wrote either a fix or a workable alternative. We listed business impact with real numbers we'd worked out, not gestured at.

We had two real architecture diagrams, not one fake one. The first was a system architecture diagram with role-tagged data flows. The second was an abstract diagram of the AI system Naveen had built. Tech-stack icons sat separately from both, so the diagrams didn't have to do duty as logo grids.

We linked to a deployed web demo. Not a Figma wireframe — an actual web application I'd coded and deployed, with screenshots embedded in the deck. We linked to a GitHub repo with a working mobile-app prototype that judges could download from the releases page. The repo had screenshots of the mobile UI on the README.

At the end, we linked to research papers we'd actually read while building the AI features — face-recognition literature, retrieval-augmented generation work. Not a generic citation pile; just the things we'd genuinely consulted, in case any judge wanted to verify we knew what we were doing.

And then the thing I think mattered most: we made a video.

About four to five minutes long, all six of us in it. I introduced the problem. Each teammate spoke about their part of the system. We embedded extra architecture diagrams we couldn't fit in the slide deck. I edited it together, put it on YouTube, and linked it from both the deck and the submission form.

By 2024, anyone could generate a passable-looking deck with AI. Perplexity could write you research, ChatGPT could write your sentences, and judges knew it. Half the trust was already gone before submissions opened. So we built the video to put real human faces, real voices, real technical specifics in front of the judges. You can fake a deck. You can't fake six people talking on camera about a system they actually built. We also hand-wrote our slide sentences — used AI to research, but typed the prose ourselves, both because we wanted to and because AI-text detection was a real concern. This is the ai-era principle showing up in the smallest possible way: the floor is on the ground now, so the ceiling is the only place anything matters.

We were the only team from our college selected to the SIH 2024 finals. We were the first team from our college, ever, to make it through.

Delhi

The finals were at a college near Noida. We booked tickets to Delhi. I got violently sick the moment we landed and spent most of the trip in the hotel room while the others saw the city. I did get to see the Red Fort. I will take the Red Fort over the rest of the trip happening to me on a worse fever scale.

The hackathon environment at SIH nationals is the most charged room I have sat in. Competitor teams to the left and right of us, mentors circulating with feedback every few hours, an unbroken hum of tired typing for the duration. We rebuilt and reshipped continuously. The mentors gave us feedback, we incorporated it, we redeployed.

Right before final judging, our deployment broke. I don't remember exactly what — something stopped working in the back end and the demo wouldn't run. We had a recorded demo as backup, but I really wanted to show the live one. The judges were in front of us. They asked if I needed a minute. I said something like just hang on, it's only going to take a second, and they were about to turn to the next team, and I fixed it. The do-or-die debugger thing — that's the moment I'm thinking of when I say it.

We presented. All of us spoke. The judges asked teammates separately, partly to verify everyone had really worked on it. Then judging closed, we zipped up the project, submitted, and waited.

The Power Rangers thing

When we'd first walked into the venue, an organizer at registration looked at our team name and asked, Why team SPD? I said Power Rangers SPD, half-expecting nothing back. She lit up. She knew. Where I come from, no one had ever recognized the reference at any of the hackathons we'd done before. So that was its own small win on day one.

We had also made custom badges. Red, Blue, Green, White, Pink, Yellow — one for each Ranger. Red was me, Blue was Hemanth, Green was Harsha, White was Naveen, Pink was Amrutha, Yellow was Raghavi. We kept them in our pockets the whole hackathon, mostly for ourselves.

When our team name came up at the results announcement, we walked on stage and pulled the badges out. The judges posed with us in the SPD pose — hands out with the rock symbol — for the photos. That is not a thing you can plan for. You can plan the badges. You can't plan the judges going along with it.

We won.

What transfers to other hackathons

Not all of this is portable. We had an unfair head start because of the year-old project we had already built. We had an unfair head start because a friend spotted the problem-statement match in the first place. We had a six-person team where everybody could speak to both the technical and the narrative, which is not a thing every team has access to.

But the parts that are portable, I think, are these.

Treat the problem-statements as the actual artifact, not as a slide to fill. We wrote out what we understood the problem to be, in our own words, separate from the brief we were given. That single slide signaled to the judges that we had read carefully. Most teams skip it. It costs almost nothing to add and seems to do a lot of work.

List your real limitations and pair each one with a real mitigation or a real alternative. Judges have heard a hundred decks claim a project does everything. A deck that admits what it cannot do, and explains why, immediately registers as more honest.

Build the demo, even if it's a prototype. We could have used Figma wireframes for the web app's vision slides. We coded the screens instead and screenshot them. The screenshots looked like screenshots, not like mockups, because they were screenshots. Judges can tell.

Make a video where everyone on the team is on camera. By 2024, the technical-deck moat had collapsed — anyone could generate one. The video was the part of our submission that was provably built by humans who actually existed and actually understood the project. This is the storytelling-is-not-optional principle, just operationalized for a remote-judged round.

Write your slide sentences by hand. Use AI to research, to find sources, to pressure-test claims. Do not use AI to write the prose that goes onto the deck. Judges in the AI era are scanning for signs of generic phrasing, and you will lose more credit by sounding like every other deck than you'll save in time.

Have a do-or-die debugger on the team — someone who hasn't been heads-down in the codebase all weekend. Their fresh-eyes view at the breakage moment is structurally different from the rest of the team's. If you can architect this on purpose, do it.

Theme your team in a way the judges will remember. SPD was not strategic. We just liked Power Rangers. But a memorable team identity, with badges or a visual marker that judges can latch onto, is a low-cost narrative aid. The judges in your room will see thirty decks; they will remember three teams. Be one of the three.

Run feedback loops in both directions. Engineers reviewing presentation copy. Presenters reviewing technical claims. The single biggest improvement to most decks I've seen is a non-technical teammate saying that's confusing, say it again differently. A team that can't run that loop ships a deck only the engineers understand.

That's the answer to the LinkedIn DMs. None of it is a secret. Most of it isn't even original. We just did all of it at once, with a team that happened to be able to.