Overview
Polytechfest Hackathon (2022) — John's team placed 1st and won INR 25,000 for a real-time chat application built under 24-hour competition constraints.
This archived case study records verified hackathon facts only: placement, prize, real-time chat scope, and time box. Specific frameworks, user counts, and infrastructure choices beyond "real-time chat" and JavaScript are intentionally not claimed.
Business problem
Hackathon judging compresses product problems into hours:
- Prove real-time behavior live — chat must work in front of judges, not as a mocked UI.
- Scope ruthlessly — 24 hours forbids enterprise polish; the team picks one narrative and ships it.
- Demo reliability — a fragile real-time path fails the presentation even if the idea is good.
- Team coordination — roles split so integration happens early enough to test end-to-end before deadline.
Solution
The team delivered a web real-time chat application — participants send and receive messages without manual page refresh, demonstrating a working messaging loop within the competition window.
Success criteria were judging-room proof, not production hardening: connect, send, receive, repeat — reliably during the demo.
Architecture
Web chat client
│
│ real-time messaging channel
▼
Chat backend / relay
│
└── broadcast to connected participants
Exact infrastructure is omitted where the resume does not specify it. Architecturally, the system separates chat UI, a real-time delivery path, and connected participants — the minimum shape required for live messaging.
Challenges
24-hour time box
Every hour spent on non-demo features risked an incomplete integration. The team prioritized a working message loop over secondary UX.
Real-time under demo stress
Judges generate bursty traffic. The chat path had to survive simultaneous sends during presentation, not just single-user testing.
Sleep-deprived integration
Late-cycle bugs in the real-time path are expensive. Early end-to-end smoke tests were the difference between 1st place and a partial demo.
Technical decisions
- Real-time chat as the sole thesis — one provable story beats many half-built tabs.
- JavaScript web client — stack kept generic per verified resume facts; no invented Firebase or socket library claims.
- Demo-first quality bar — stability during live judging trumped feature breadth.
- Archived status — competition artifact, not ongoing product maintenance.
Gallery
Text-only descriptions of what was shown:
- Real-time chat interface — Live message send and receive without manual refresh.
- 24-hour delivery scope — Working end-to-end chat within one competition window.
- Live presentation — Judging based on functioning real-time flow.
Technologies
Verified stack (resume-level): JavaScript, real-time messaging, web application.
Process: 24-hour hackathon delivery, team coordination, live demo.
Lessons learned
- Integrate early in hackathons — real-time bugs found at hour 20 are fatal.
- One demo path — judges remember working chat, not roadmap slides.
- Do not invent stack detail — honest hackathon write-ups age better than exaggerated tech lists.
Future improvements
Not applicable — archived competition entry. A production evolution would require new requirements, security model, and persistence design outside this hackathon scope.