24-Hour Hackathon Battle Plan

Pick Theme 02 — NGO & Social Impact

Not because it's easier to build, but because it's easier to win with a simple build. Social-impact judging leans on problem clarity, real users and a working demo. Industry & Enterprise judging leans on technical depth (Industrial AI/ML, Supply Chain, Cybersecurity, Industry 4.0) — that is where the 4th-year ML teams go, and where a 24-hour prototype looks thin next to them.

Lower skill floor Story > depth Data you can honestly fake Higher team count → win on execution

Head-to-head

Factor	01 Industry & Enterprise	02 NGO & Social Impact
What judges reward	Novelty, technical depth, scalability, ROI model	Problem clarity, real beneficiaries, working demo, measurable impact
Who you compete with	Teams with ML/CV/IoT experience and domain data	Mixed crowd — many are also first-timers
Minimum viable demo	Often needs a working model or hardware	A form + a dashboard + one smart feature can win
Data you need	Enterprise/industrial data you don't have → looks fake	Small, realistic, self-collected or public data is believable
30-second explainability	"We optimise throughput of a forging line"	"A teacher flags dropout risk in 5 minutes a day"
Risk for you	Medium-low (fewer teams, higher bar)	Medium (more teams, lower bar)

Pick Theme 01 instead only if

Someone on your team has real ML/CV/IoT project experience (not just coursework), and
you have a genuine dataset or a real industrial/FinTech problem from an internship or family business, and
you can scope it to one narrow sub-stack: FinTech (easiest) or Smart Enterprise (second easiest). Avoid "Industrial AI/ML" and "Industry 4.0" as a beginner team.

Sub-stack (the little tags) — how to choose

Sub-stacks usually carry their own sub-prizes, so aim at the one with the fewest competitors and the strongest story you can tell. For your team: Rural Upliftment, Education (Non-Profit Tech) or Social Welfare. Healthcare & Hygiene is the most crowded after Open Innovation.

Verify this yourself in 5 minutes: open the event site / ask an organiser in the Discord: (1) Is there a separate prize per sub-stack? (2) Is the team size cap 4? (3) Do we need to use a sponsor API or cloud? (4) Exact submission cutoff time and what the judges see (repo? video? live demo? 3-min pitch?). Your plan changes more from question 4 than from anything else on this page.

The scope rule (read this before ideas)

Three features that tell one clear story beat ten half-built ones. Judges reward a clean, finished demo over an ambitious idea that breaks. Build the golden path — the exact click sequence you will show on stage — first, then add anything else only if time remains.

Commit within 20 minutes. Use this filter, score each idea /5:

Can I demo the whole thing in 3 minutes without explaining?
Can the golden path be built in 10 hours by 4 beginners?
Does the pitch contain a number (people affected, minutes saved, rupees saved)?
Is there one "wow" moment (an AI output, a map, a live alert)?
Do I need hardware, payments, or a government API? (if yes → subtract 3)

A · ShikshaTrack — dropout early-warning recommended

One-liner: A teacher marks 2 signals a day (present/absent, homework) and the app flags children at risk of dropping out, then drafts a parent message in the local language.
Users: Teacher (data entry) + school/NGO coordinator (dashboard)
Golden path: 1 Login → 2 Attendance screen (tap present/absent for a class list) → 3 Risk list auto-sorts flagged students → 4 Student profile shows trend + generated parent message → Copy/Send
The "AI": Transparent score (attendance streak + trend + distance + mid-day-meal flag) + LLM writes the local-language message a teacher would actually send
Impact number: "1 teacher, 40 students, 5 minutes/day, 12 at-risk children identified in week 1"
Stack: Plain HTML/CSS/JS + Tailwind CDN + Supabase (Postgres) + one LLM API + Chart.js

B · HealthCamp — follow-up tracker for NGO camps

One-liner: NGO health camps register patients on paper and lose them. This registers a patient, creates a follow-up date, and shows coordinators who is due today and who never returned.
Golden path: 1 Register patient (voice-assisted form) → 2 Set follow-up date → 3 "Due today" list → 4 Reminder message + dashboard of camp stats
The "AI": LLM turns a free-text complaint into a structured tag (e.g. "sugar problem, 2 months") and writes the reminder in the patient's language
Impact number: "1 camp, 300 patients, follow-up no-show drops from 70% to X%"
Why it's strong: Healthcare & Hygiene is a listed sub-stack; the no-show problem is instantly believable to any judge

C · SchemeSaathi — voice-first govt-scheme finder

One-liner: A rural user speaks their situation ("I'm a widow with two kids, no land") and gets the 3 schemes they qualify for, read back aloud in their language.
Golden path: 1 Tap mic → 2 Speak → 3 Transcript + matched schemes → 4 Details read aloud + documents checklist
Risk: Browser speech APIs are flaky with accents and on venue wifi — always keep a typed-input fallback path and pre-recorded audio for the demo
Pick this only if: You have a confident demoer and you test the mic on the actual venue machine early

Reject list (don't let anyone reopen these)

Anything needing payments, KYC, government APIs, hospital data, or hardware sensors
Blockchain / "Web3 verified donations" — no judge has asked for this in years
Marketplaces (two-sided: needs seed supply and demand to demo)
Anything where the core value needs 1000 real users to be visible
Chatbots with more than 3 buttons — you will burn hours on state handling
Fine-tuning a model. Never in 24 hours.

Hour 0 = when the hacking clock starts

Rule of thumb: the plan below assumes you show up with the pre-hackathon prep already done (see tab 7). Skip that prep and you lose hours 0–4 to setup and indecision — that is how beginner teams end up with nothing to demo.

Hours	Block	Owner	Done when…
H0–0.5	Scope lock	All 4, standing up	One printed sentence: "We help who do what". 4 screens named. Reject list posted on the wall. Nobody reopens this.
H0.5–1	Demo-path script + repo	Lead (M1)	Repo created, all 4 cloned and pushed a commit. The 3-minute demo click-path is written as literal steps.
H1–3	Skeleton, deployed empty	M3 + M4	The 4 screens exist with hardcoded data, and the URL is live (Vercel/Netlify/Streamlit Cloud). Deploy at hour 3, not hour 20.
H3–4	Data model + DB live	M2	Tables created, seed script inserts 40 fake students/patients. Everyone can read from it.
H4–9	Golden path end-to-end	M2+M3, M4 on AI	Screen 1 → 4 works start to finish with real data. Feature freeze on the golden path at H9 — after this you may only fix, not add.
H9–12	The one wow feature	M4 (+M1)	AI message generation / matching works on all seed records, and fails gracefully when the API is down.
H12–15	SLEEP ROTATION	2 & 2 split	M1+M3 sleep 3h while M2+M4 hold the fort, then swap. Full sleep for all 4 is better than 4 zombies — one exhausted person breaks main and eats 2 hours.
H15–18	Polish + demo data	Split	Charts render, loading states, mobile layout, seeded demo account that looks real, no console errors.
H18–19	HARD FREEZE	M1 enforces	No new code merges to `main`. Only the demo path gets bug fixes. "One more feature" at H18 is how teams lose.
H19–21	README + architecture diagram + deck	M1 + M4	5 slides done. Diagram drawn (tab 5). README has problem, stack, how to run, screenshots. Submissions usually require these.
H21–22.5	Rehearse ×2, timed	All 4	Two full run-throughs with a phone timer. Cut every word that isn't needed. Assign who answers which question type.
H22.5–23	Insurance	M4	90-second screen recording of the working demo + screenshots saved. If venue wifi or the API dies on stage, you still have a demo.
H21 onward	SUBMIT — don't wait	M1	Submit as soon as the README + repo + video are in. Then keep improving the pitch only. Late submissions are the single most common beginner disaster.

Hourly cadence (the thing that actually saves you)

Every hour, 2 minutes, standing: what works, what's blocked, who needs help. All 4 speak.
Blocked > 20 minutes? Scream for a mentor or a teammate. The hackathon has mentors — use them with a specific question ("how do I save a form to Supabase from plain JS?"), never "it doesn't work".
Commit every hour to a feature branch; merge to main only when it runs. One GitHub repo, main is always demo-able.
Never refactor after H18. Ugly code that works is a feature.

Roles are ownership of outcomes, not walls. Everyone touches everything. But each of the four below is accountable — if it's broken, that person is the one who decides what to cut.

M1 · LEAD + INTEGRATOR

Owns: the demo path, the repo, the deadline, the pitch

Runs the H0 scope lock and the hourly standups
Owns main. Only M1 merges. Says "no" to new features
Enforces the H18 freeze and submits early
Presents slide 1, 2 and 5; drives the live demo if you use one
Watches the clock — no one else has to
Weakest builder's job: a non-scary coder can do this and add more value than their code would

M2 · DATA + BACKEND

Owns: the database, seed data, and every connection between screens

Supabase/Firebase project, tables, and 40 realistic seed rows
Makes the first working "save → read" loop by H4
Writes the API key handling (.env, never commit keys)
Owns the README's "how to run" section
Fixes "it works on my laptop" — that bug is always this person's

M3 · FRONTEND + DESIGN

Owns: whether it looks like a real product in the first 5 seconds

Builds the 4 screens, mobile-first (judges hold phones; often so does your demoer)
Steals a colour palette at H1 and never changes it again
Charts and numbers on screen — the "impact" evidence lives here
Keeps an offline static copy of the UI as the last-resort demo
Also owns: font sizes big enough for a projector. Test on the venue screen.

M4 · AI + DEMO / DECK

Owns: the wow moment, plus everything that makes the pitch land

Wires the single LLM call (with a hard-coded fallback string if the API fails)
Owns the 5 slides, the timer, and both rehearsals
Records the 90-second backup video at H22.5
Owns the architecture diagram (tab 5) — it goes on slide 4
Answers the "how is this AI?" question honestly

Ownership per block

Hours	M1	M2	M3	M4
H0–3	Scope, repo, demo path	DB choice + first table	Screen 1 + 2 UI	Screen 3 + 4 UI + API keys
H3–9	Integrating, unblocking	Real data + save/read	Wire screens to data	LLM feature
H9–15	Sleep 1st shift (or hold)	Hold	Sleep 1st shift	Hold
H15–18	Cut list, demo path	Bug fixes only	Polish + charts	AI fallbacks + deck
H18–24	Freeze, submit, pitch	README support	Demo insurance video	Rehearse, rehearse

If your team is uneven (e.g. one person is far stronger), put the strongest person on M2+integration, not on the pitch. A demo that runs covers a mediocre pitch; a great pitch over a broken app does not.

You already know architecture. It's just boxes and arrows.

Boxes = components (a screen, a service, a database). Arrows = data moving, labelled with a verb ("save attendance", "ask for message").
Stack the boxes in 3 rows: who uses it (Client) → what thinks (App) → what remembers (Data) + what you borrow (External services). This is a "3-tier diagram" and it is what judges expect.
7–9 boxes maximum. If your diagram needs 20 boxes, your scope is too big — that's useful information.
Label the arrows. An unlabelled arrow is a guessing game; a labelled one is an explanation.

Draw it in 10 minutes: excalidraw.com (hand-drawn, looks friendly) or mermaid.live (paste the code below, screenshot the result). Do this at H19 — not at H2, and never let it change your code.

Your diagram (adapt the labels to your idea)

Layer 1 · Client — who uses it

Teacher / field workermobile web browser

Coordinator dashboarddesktop browser

↓ HTTPS · form submits as JSON ↑ JSON responses, charts

Layer 2 · App — what thinks

Web app / serverless functionsroutes: /attendance /students /message

Auth + row-level rulesteacher sees only their class

Risk scoringsimple transparent rules

↓ SQL read/write · ↓ prompt & receive text · ↓ send alert

Layer 3 · Data + External — what remembers, what you borrow

Postgres (Supabase)students, attendance, flags

LLM APIparent message in local language

SMS / messaging gatewayor an on-screen preview if none

Mermaid source (paste into mermaid.live, screenshot, put on slide 4)

flowchart TB
  subgraph C["1 · Client — who uses it"]
    T["Teacher / field worker<br/>mobile web"]
    D["Coordinator<br/>dashboard"]
  end

  subgraph A["2 · App — what thinks"]
    API["Web app / serverless functions<br/>/attendance /students /message"]
    AUTH["Auth + access rules"]
    RISK["Risk scoring<br/>(transparent rules)"]
  end

  subgraph X["3 · Data + External"]
    DB[("Postgres — Supabase<br/>students · attendance · flags")]
    LLM["LLM API<br/>parent message"]
    SMS["SMS / messaging gateway"]
  end

  T -->|"marks attendance"| API
  D -->|"views at-risk list"| API
  API --> AUTH
  API --> RISK
  API -->|"SQL read/write"| DB
  RISK -->|"flag if score > 0.6"| API
  API -->|"prompt + context"| LLM
  LLM -->|"draft message"| API
  API -->|"send alert"| SMS
  SMS -->|"delivery status"| API

Your 40-second spoken walkthrough (memorise this shape)

"The teacher opens this on a phone and taps attendance — that's a form post to our app layer. The app layer stores it in Postgres and re-runs the risk score, which is just attendance trend plus three flags, so we can explain any number on screen. If a student crosses the threshold, we call one LLM prompt with their context and it drafts the message the teacher would send in the local language. The coordinator's dashboard is the same app layer, filtered to their school. Everything is serverless and free-tier, so the whole thing costs ₹0 per school today."

Notice: it says what data moves, in order, and ends with cost/scale. That's all an architecture slide has to do.

5 slides, 3 minutes, no exceptions

Slide	Time	Content	Speaker
1 Problem	25 s	One photo. One number. One sentence. Not three paragraphs.	M1
2 Today vs ours	25 s	"Today it's a paper register that nobody reads." Then the one-line solution and the 4 screens.	M1
3 LIVE DEMO	80 s	The golden path only. Say what you're clicking as you click it.	M1 or M4
4 How it works	25 s	The diagram + the 40-second walkthrough from tab 5.	M4
5 Impact & next	25 s	Numbers per school, cost (₹0), what you'd build in 3 months, one honest limitation.	M1

Rehearse twice against a timer. If you run 4 minutes in rehearsal, you'll run 5 on stage. Cut slide 5 first, then slide 2.

Demo-day hygiene

Seed the demo account with names and numbers that tell a story, and open the app already logged in.
Never type live if you can paste. Have a text file open with the exact inputs pre-copied.
Two devices: presenter laptop + a phone with the same URL on hotspot. Wifi will fail.
Kill notifications. Do Not Disturb on both. Nothing kills a demo like a WhatsApp preview.
Zoom to 125% so the back row can read it.
Record the backup video at H22.5 and keep it on the desktop, not in Drive needing internet.
If something breaks: don't debug on stage. Say "I'll show you the recorded version of that step" and move on. Judges respect composure.

Q&A — prepare these 8 answers in advance

"How is this AI?" → "One LLM call drafts the parent message in the local language; the risk score is deliberately transparent rules so a teacher can audit why a child was flagged."
"Why not just use Excel?" → "Excel can't alert you. The value is the flag that appears without anyone asking."
"Will teachers actually use it?" → "It's 5 minutes a day on a phone they already have, and it removes the paper register they hate."
"What's your business model / sustainability?" → "₹0 infra on free tiers per school; NGOs already spend on this reporting, so we'd charge the NGO, not the school."
"Privacy of children's data?" → "Access rules mean a teacher sees only their own class; no data leaves the school's tenant."
"What about no internet in rural areas?" → "Attendance queues locally and syncs when online — honest answer: that's our next 3 months of work, not done today."
"What did you not finish?" → Have one honest, specific answer ready. Judges trust teams that name their own gaps.
"Can you show it to me?" → Hand over the running app on the phone. Have it open on the golden path already.

Never say: "this is just a prototype", "we ran out of time" (say what you chose to prioritise instead), or "it works on our laptop". Say what works, show it, then name one limitation.