What hackathons and competitions taught me about shipping

During college I spent a lot of time at hackathons and competitions — from AMSAS 2022 by ISRO, which I won, to KIRIT 3.0 and 4.0 by Kirloskar Institute of Management, where I was a national finalist, the Hult Prize at JBIMS (campus winner), the 50-hour School of Design Think Hackathon (winner), the Intelligent Planet Hackathon at KFUPM in Saudi Arabia (finalist), and the Amazon ML Challenge 2024, where I was a Top 100 ML Challenger among 74,823 teams.

Every format was different: research challenges, business case competitions, design sprints and machine learning leaderboards. But the habits that worked kept repeating. This is the playbook I ended up with.

1. Spend the first hour on the problem, not the code

The strongest submissions start with a precise problem statement. Who is the user? What do they do today? What is painful about it? AgriFinAI, for example, starts from specific problems — unpredictable weather, limited access to credit, fragmented markets and missing localized advice — before any feature is mentioned.

If you can't state the problem in two sentences, the judges won't be able to either.

2. Pick one end-to-end flow and make it real

A demo with one complete flow beats a slide with ten features. Choose the single journey that proves your idea — upload a document and see the checklist, ask a question and get a grounded answer — and make that work end-to-end before adding anything else.

3. Use managed building blocks

A hackathon is not the time to build infrastructure. Hosted AI APIs, a frontend framework you know well, and one-click deployment let you spend your time on what's unique about the idea. Several of my hackathon builds — AgriFinAI, DocFlow AI and Saathi — combined Next.js or React with Gemini or other hosted models for exactly this reason.

4. Deploy early

A live URL changes how people engage with your project. Deploy in the first few hours, even if it's a skeleton, so the final hours are spent on polish rather than fighting deployment.

5. Design the demo, not just the product

Judges see your project for a few minutes. Script the demo: the problem, the user, the one flow, the result. Have sample data ready. Know what you'll click and in what order.

6. Be honest about what's built

It's tempting to present the vision as if it's finished. Experienced judges notice. Clearly separating "working today" from "next steps" makes the working parts more credible.

7. Competitive programming is a quiet multiplier

Alongside hackathons, I've solved 400+ problems on competitive programming platforms. It doesn't show up directly in a demo, but it makes implementation under time pressure much faster — you spend less time stuck on the algorithmic parts and more time on the product.

What carries over to real work

The same habits apply in a job: understand the problem first, ship an end-to-end slice, lean on managed services, show progress early, and be clear about what's done. Hackathons just compress the feedback loop into a weekend.