6 Hours of Programming, 18 Hours of Everything Else
We filmed the product ad before the product fully worked. That probably sounds backwards if your mental image of a hackathon is 4 people hammering at keyboards and pretending caffeine is a personality trait. It was backwards. It was also the right call.
We filmed the product ad before the product fully worked. That probably sounds backwards if your mental image of a hackathon is 4 people hammering at keyboards and pretending caffeine is a personality trait. It was backwards. It was also the right call.
SNPSU was one of the most fun hackathons I've been to, and not because of the coding. We probably spent six hours actually building and the rest doing everything people underrate: arguing about features, sketching architecture, pricing out APIs like broke students because we were broke students, and trying to build for users who were never going to tolerate a shiny expensive AI toy. The prompt was about semi-literate and rural users. That changes your instincts fast. You stop asking what looks impressive and start asking what someone would actually use.
Our team was stacked, which helped. Sohan carried harder than anyone had a right to. He was locked in almost the entire time while the rest of us orbited around the core build doing the useful side work: research, setup, infrastructure, product calls, and the occasional half-baked opinion that somehow turned into a real feature. That division of labor sounds less glamorous than "we coded nonstop for 24 hours." It was better.
The product itself had a weird kind of ambition. We wanted an AI app with almost no text in the interface, basically two lines on the login page and the rest handled visually. Then we pushed the idea further. A lot of people in rural India still use button phones. So why not make something that could run on KaiOS? Once that clicked, the whole thing sharpened. The app stopped feeling like a generic hackathon AI demo and started feeling like a real product decision.
There was a lot of wandering in between. The campus was huge, so naturally we spent part of the hackathon exploring it like tourists who had accidentally brought laptops. All the classrooms looked like a hotel rooms, we picked an empty one, which became our improvised ad studio. Shooting a promo video for a product that was still being stitched together in another room is objectively ridiculous. We did it anyway. I still think that was one of the best parts.
Night hit, the usual developer script kicked in around us, and teams started reaching for caffeine like they were clocking into a shift at a small factory. We went in a stupider direction. Soft drinks, ice cream, some deeply cursed mixtures I wouldn't recommend to anyone who values their organs. The goal wasn't taste. The goal was staying awake out of spite. It worked, which is annoying because it validates terrible behavior.
What I remember most is that we spent less time obsessing over how much we could build and more time asking who we were building for. Most teams around us seemed to be racing the clock in the obvious way, more screens, more features, more code, more things to show judges. We kept circling back to the user. What would a semi-literate person actually tap? What would feel obvious on a tiny device? What would still work if the phone was cheap, the network bad, and patience nonexistent? Those questions slowed us down in the short term. They also made the product sharper.
We placed second.
I'm not going to pretend that was some grand philosophical victory over brute-force coding. Plenty of teams built more than we did. But I do think we got rewarded for taking the problem statement seriously instead of treating it like decoration. Sometimes the winning move in a hackathon isn't writing more code. It's resisting the urge to write the wrong code.