Annapurna won BYTEBATTLE as a weekend prototype and became a real food-sharing platform because we treated the Monday after as the actual start. STROT did not win its hackathon and we kept shipping it anyway. The two weeks after an event are where a hackathon project either becomes a portfolio piece or a folder you never open again.
Day one: decide honestly
Ask three questions. Did anyone other than the team want this? Is the hard part solved or faked? Would you use it? If two answers are no, archive the repo with a good README and move on without guilt — a finished, documented prototype is still a fine portfolio item.
Week one: rewrite the skeleton, keep the insight
- Keep the problem statement, the user research and the demo path.
- Rewrite the parts written at 4 a.m. — usually auth, data models and error handling.
- Replace mocked services with real ones, one at a time, with tests on the demo path.
- Set up deployment properly: environment variables, a database with backups, structured logs.
Week two: ten real users
Not a launch — ten people who have the problem, using it while you watch. For Annapurna that meant NGOs and volunteers, not classmates. Write down every confusion. Fix the top three. That loop, repeated, is the entire difference between a prototype and a product.
What to keep from the hackathon
The pitch. It is the clearest statement of the problem you will ever write, and it becomes your README, your LinkedIn post and your interview answer. Judges' feedback too — the criticisms you disagreed with at the time are usually the ones worth revisiting.
Tell the story
Post the journey publicly: what you built, what broke, what users said. Building in public after the event is how the project keeps paying off long after the prize money is spent — and it is how mentors and judges remember your name at the next event.
— Pranjul Rathour, GenAI Engineer from Kanpur, India. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at any campus: pranjulrathour41@gmail.com.