A beginner-friendly session · No coding experience needed to follow along
Hackathons in the Age of Agentic AI
From idea to working solutions — how to prepare, build, manage your time and team, and use AI coding tools to ship something real.
Meet your speaker
I build products — and I win hackathons by finishing, not by starting big.
Touhidul Alam Seyam — Software Engineer at Agentic Institute and Hello World Communications Ltd. Full-stack, backend and applied AI since 2021. B.Sc. CSE, BGC Trust University Bangladesh (final year).
Solo team “Huntrix”. Built Huntrix Delta: offline identity, inventory, delivery proof and routing.
Smart-campus response system with live dashboards and real-time alerts.
With Abtahee Kabir. Also finalist and top-5 finishes at IUT ICT Fest GameJam and IIUC NextGen.
TypeScript · Python · React · Next.js · Node.js
FastAPI, PostgreSQL, Docker, Vercel, machine learning and AI agents. Ten research works, including published papers on AI visual assistance and plant-disease detection (AgriScan).
Today I will share the exact system behind those wins — in simple words, with pictures.
seyamalam41@gmail.com · linkedin.com/in/touhidulalamseyam
Roadmap
One journey, seven stops.
By the end, you will know what to do before, during and after a hackathon — and how to make AI tools do the heavy lifting without losing control.
One promise: everything today uses simple words. If I use a hard word, I will explain it first — then use it.
Stop 1 · Understand
A hackathon is a short race to turn an idea into a working thing.
“Hack” here means build creatively, not break into computers. “Marathon” means you keep going for a set time — usually 24 to 48 hours.
is given"] --> B["Form a
team"] --> C["Pick one
idea"] --> D["Build a
working demo"] --> E["Show it
to judges"] --> F["Feedback
+ prizes"] style A fill:#111,stroke:#333,color:#fff style D fill:#fff,stroke:#fff,color:#000 style F fill:#111,stroke:#333,color:#fff
A problem + a deadline
Example: “Help farmers detect plant disease.” The deadline forces you to finish, not just dream.
A demo, not a perfect product
Judges want to see it work. A small thing that works beats a big thing that is half-broken.
Skills, friends, proof
A project link, new teammates, and proof you can ship — useful for jobs even if you do not win.
Stop 1 · Understand
Not all hackathons are the same. Pick the right race.
| Type | Time | Who joins | Good for |
|---|---|---|---|
| University / local | 12–24 hours | Students, small teams | Your first one. Friendly, mentors nearby. |
| National / theme | 24–48 hours | Mixed teams, one topic | Real problems, bigger prizes. Example: HackFusion. |
| Online / global | 2 days – 2 weeks | Anyone, anywhere | Flexible time. You must manage yourself. |
| Company / API | 24 hours – 1 week | Builders using one tool | Learn one platform deeply. Often hiring happens here. |
| Game jam | 48–72 hours | Game makers | Make a small playable game. Fun first. |
Rule of thumb: if the event gives a theme, your idea must fit the theme. If it gives a problem list, pick from the list. Never ignore the theme — judges score on it.
Stop 1 · Understand
How long is the race? Your plan changes with the clock.
| Format | How it feels | Build this much | Freeze at |
|---|---|---|---|
| 8 hours · sprint | One school/work day. No sleep break. | 1–2 features, one screen if possible. Use a template. | Hour 6 |
| 12 hours · one day | Morning to night. Most common local format. | 2–3 MUST features. Demo path only. | Hour 9–10 |
| 24 hours · overnight | The classic. One night inside. | 3–5 MUST features. Sleep in shifts. | Hour 19–20 |
| 36–48 hours · weekend | Two days. More polish possible. | 5 features + SHOULD list. Real data if easy. | Last 6–8 hours |
| 1–2 weeks · online | A little every day. Self-discipline race. | Bigger scope, but weekly demo checks. | Last 2 days |
Idea + plan
slides or short doc
many teams enter"] --> B{"Judges
select"} B -- Pass --> C["ROUND 2
Build
working demo
fewer teams"] B -- No --> X["Out — learn,
join next event"] C --> D{"Mentor /
mid check"} D -- Pass --> E["FINAL ROUND
Live demo + Q&A
top teams present"] style C fill:#fff,stroke:#fff,color:#000 style E fill:#fff,stroke:#fff,color:#000 style A fill:#111,stroke:#333,color:#fff style X fill:#111,stroke:#333,color:#888
Round 1 tip
They judge the idea and plan, not code. One clear problem sentence + who it helps + what you will demo.
Mid-check tip
Show something working, even if ugly. “We planned a lot” does not survive a cut. A clickable demo does.
Final tip
Only finalists present live. Rehearse the 3-minute demo. Keep a backup video — finals Wi-Fi fails too.
Stop 1 · Understand
Judges score a working story, not lines of code.
Most score sheets look like this. Notice: “does it work?” and “is it clear?” matter more than fancy tech.
Judges ask 4 questions
- What problem is this?
- Who has this problem?
- Show me it working.
- What would you build next?
The painful truth
If the demo breaks in front of judges, nothing else matters. Protect the demo. That idea returns in every part of this session.
Stop 1 · Understand
AI agents changed what one small team can finish.
| Before (typing by hand) | Now (with AI agents) | |
|---|---|---|
| Writing code | Slow. Every line by hand. | Fast. Agent drafts, you review. |
| Hard part | “How do I code this?” | “What exactly should I build?” |
| Team size needed | 4–5 people | 1–3 people can ship a lot |
| Biggest risk | Not enough time to type it | Building the wrong thing, fast |
| Winning skill | Fast typing | Clear thinking + checking work |
New rule: the agent is a fast junior builder. You are the manager and checker. If you cannot explain what “done” looks like, the agent cannot build it.
Stop 1 · Understand
An agent is an AI that can act, not just chat.
A chatbot answers. An agent can read files, write code, run commands, see errors, and fix them — in a loop, until the task is done or it gets stuck.
a clear task"] --> B["Agent reads
your project"] --> C["Agent writes
or edits code"] --> D["Agent runs it
tests / commands"] --> E{"Works?"} E -- No --> C E -- Yes --> F["You check
+ approve"] --> G["Commit
save progress"] style A fill:#fff,stroke:#fff,color:#000 style F fill:#fff,stroke:#fff,color:#000 style E fill:#111,stroke:#555,color:#fff
It can
Create files, fix bugs, run tests, search your code, explain errors in simple words.
It cannot
Know your idea unless you write it down. It guesses — and guesses can be wrong or unsafe.
Your job
Give small clear tasks. Check the result. Say “yes, continue” or “stop, wrong way.”
The big picture
From sign-up to stage — the full journey.
Learn + set up tools"] --> B["DAY 0 · FIRST 2 HOURS
Pick problem, cut scope"] B --> C["BUILD IN SMALL LOOPS
Task → Agent → Check → Save"] C --> D["HALFWAY
Demo to each other"] D --> E["LAST 20% OF TIME
Test, fix, freeze"] E --> F["FINAL HOUR
Rehearse + submit"] style B fill:#fff,stroke:#fff,color:#000 style E fill:#fff,stroke:#fff,color:#000 style A fill:#111,stroke:#333,color:#fff style C fill:#111,stroke:#333,color:#fff style D fill:#111,stroke:#333,color:#fff style F fill:#111,stroke:#333,color:#fff
If you remember one shape, remember this: plan small → build in loops → stop early → polish.
Stop 2 · Prepare
Prepare before the clock starts. The clock is too precious to waste on setup.
Set up once, reuse forever
- Install Git, Node.js (or Python), and a code editor
- Create GitHub account. Learn: clone, commit, push
- Install ONE AI coding tool (next slides). Log in and test it
- Make a tiny demo project and deploy it free (Vercel / Netlify)
- Charge laptop, bring charger, headphones, water bottle
Remove every surprise
- Read the rules, theme, and scoring sheet twice
- Check team size limit and submission format
- Test internet backup: phone hotspot works?
- Prepare empty repo, README, and folder structure
- Sleep well. A tired brain makes bad scope choices
Never do this on hackathon day: install tools for the first time, create accounts, or learn Git. That is how teams lose 3 hours before writing line one.
Stop 2 · Prepare
Learn the 20% that builds 80% of hackathon projects.
HTML, CSS, one language
JavaScript or Python"] --> L2["2 · One framework
Next.js / React or FastAPI
pick ONE, go deep enough"] L2 --> L3["3 · Data
Show, save, read data
simple database or local file"] L3 --> L4["4 · Ship it
Git + free deploy
Vercel, share a link"] L4 --> L5["5 · AI tools
Prompt, check, fix
one agent, used well"] style L1 fill:#111,stroke:#333,color:#fff style L5 fill:#fff,stroke:#fff,color:#000
Must learn
- How a web page talks to a server (request → answer)
- How to run a project and read an error message
- Git basics + how to undo a bad change
- How to write a clear task for an AI agent
Skip for now
- Three frameworks “just in case”
- Complex cloud setup, Kubernetes, micro-services
- Building your own login system from zero — use a ready one
- Perfect code style. Working beats pretty today
Stop 2 · Prepare
One boring stack, used by the whole team.
A stack is just your set of tools. Boring is good: boring means fewer surprises at 3 a.m.
| If you know… | Build with | Save data in | Deploy on |
|---|---|---|---|
| JavaScript | Next.js + Tailwind CSS | SQLite / Supabase | Vercel (one click) |
| Python | FastAPI + simple HTML page | SQLite | Render / Railway |
| Almost nothing yet | One Next.js template + AI agent help | Local file / browser storage first | Vercel |
| Mobile idea | Web app that works on phones (PWA) | Same as above | Vercel — no app store wait |
Use ready pieces
Login, payments, maps, AI chat — use a ready service or library. Do not rebuild what exists.
Fake it when safe
No real data yet? Use sample data that looks real. Judges judge the idea and flow.
One stack per team
Two stacks = double setup pain. Agree on day zero, write it in the README.
Stop 3 · Plan
Small team, clear jobs. Everyone builds, one person steers.
guard time + scope
make final calls"] --- B1["Builder A
screens people see"] CAP --- B2["Builder B
data + logic behind"] CAP --- ST["Storyteller
demo script, slides,
testing with fresh eyes"] B1 <-->|"talk every hour"| B2 ST -->|"test like a judge"| CAP style CAP fill:#fff,stroke:#fff,color:#000 style B1 fill:#111,stroke:#333,color:#fff style B2 fill:#111,stroke:#333,color:#fff style ST fill:#111,stroke:#333,color:#fff
Good team rules
- 2–4 people is the sweet spot. Solo works, 6+ gets slow
- Mix skills: one design eye, one logic brain, one presenter
- Captain is not “the boss” — captain protects time and says “cut it”
Bad team signs
- Everyone does “a bit of everything”, nobody owns anything
- Two people edit the same file at the same time
- Decisions by long debate. Decide in 5 minutes, move
Stop 3 · Plan
Pick a small problem you can explain in one sentence.
Use this sentence: “[Who] struggles with [problem], so we built [thing] that [result].” If you cannot fill it, the idea is not ready.
theme?"} -- No --> X1["Drop it"] B -- Yes --> C{"Can we demo it
in 2 minutes?"} -- No --> X2["Shrink it"] C -- Yes --> D{"Data + tools
available?"} -- No --> X3["Fake the data
or drop it"] D -- Yes --> E["BUILD IT"] style E fill:#fff,stroke:#fff,color:#000 style X1 fill:#111,stroke:#ee0000,color:#ff7b72 style X2 fill:#111,stroke:#f5a623,color:#f5d48a style X3 fill:#111,stroke:#f5a623,color:#f5d48a
Good signs
You know a real person with this problem. You can name them.
Warning signs
“It is like Uber, but for everything.” Too big. Too vague.
My test
Can a stranger understand it in 30 seconds? If not, simplify the words, then the idea.
Stop 3 · Plan
Scope means: what you will NOT build. That list saves you.
The demo path
3–5 features only. The exact clicks your demo will show, start to finish. Nothing else matters if this breaks.
Nice extras
Better design, one extra screen, real data instead of sample data. Only after MUST works.
The cut list
Payments, chat, admin panel, perfect login. Write them down as “future work” for your pitch.
brainstorm, no judging"] --> B["Keep: helps the
2-minute demo?"] --> C["Keep: can we build
it in 2 hours?"] --> D["YOUR PLAN
3–5 must-have features"] style D fill:#fff,stroke:#fff,color:#000 style A fill:#111,stroke:#333,color:#fff
The MVP rule: MVP = Minimum Viable Product = the smallest version that still solves the problem. Build the bicycle, not the car. You can describe the car in your pitch.
Stop 3 · Plan
Every project has the same 6 parts. Plan each in one line.
taps / clicks"] --> FE["Screens
what they see"] FE --> API["Middle layer
checks + decides"] API --> DB[("Saved data
database / file")] API --> EXT["Outside help
maps, AI, email APIs"] FE --> DEMO["Demo + pitch
how judges see it"] style FE fill:#fff,stroke:#fff,color:#000 style U fill:#111,stroke:#333,color:#fff style API fill:#111,stroke:#333,color:#fff style DB fill:#111,stroke:#333,color:#fff style EXT fill:#111,stroke:#333,color:#fff style DEMO fill:#111,stroke:#333,color:#fff
| Part | Ask this | One-line example |
|---|---|---|
| 1 · User | Who, exactly? | “A small shop owner with a cheap phone.” |
| 2 · Screens | What do they tap, in what order? | Home → Add stock → See list → Done. |
| 3 · Logic | What does the app decide? | “Warn when stock is below 5.” |
| 4 · Data | What must be saved? | Item name, amount, date. |
| 5 · Outside help | What do we borrow? | AI to read a photo of a receipt. |
| 6 · Demo | What is the story? | “Watch: no internet, still works.” |
Stop 5 · Manage
Time is your real budget. Spend it like money.
For a 24-hour hackathon. For 36 or 48 hours, stretch the middle — never stretch planning or the final freeze.
Hour 0–2"] --> B["BUILD DEMO PATH
Hour 2–8"] --> C["TEAM DEMO
Hour 8–9"] --> D["FINISH
Hour 9–16"] --> E["TEST + POLISH
Hour 16–20"] --> F["FREEZE + PRESENT
Hour 20–24"] style A fill:#111,stroke:#333,color:#fff style C fill:#fff,stroke:#fff,color:#000 style F fill:#fff,stroke:#fff,color:#000
Stop 5 · Manage
Split work into cards. One card, one owner, one “done”.
Owner: Builder A"] end subgraph CHECK["CHECK · test it"] C1["Low-stock warning"] end subgraph DONE["DONE · saved in Git"] DN1["Home screen ✓"] end TODO --> DOING --> CHECK --> DONE style DOING fill:#111,stroke:#555,color:#fff style DONE fill:#fff,stroke:#fff,color:#000
Good card
“Add-item form: name + amount, saves, shows in list.” One owner. Done in under 2 hours. You can see when it is done.
Bad card
“Do backend.” Nobody knows what done means. Split it into 4 small cards.
The 2-hour rule
Card taking over 2 hours? Stop. Split it, ask for help, or cut it. Silence wastes the team's time.
Free boards: GitHub Projects, Trello, Notion — or paper cards on a wall. Paper is fastest on day one.
Stop 5 · Manage
Most teams do not fail on code. They fail on talking.
The check-in
- Done — what works now? Show it, do not just say it.
- Doing — what is next, in one sentence?
- Blocked — what is stuck? Who can unblock it in 15 minutes?
Five agreements
- One shared chat. Decisions go there, not in side chats
- Commit + push every 1–2 hours. “Works on my laptop” is not saved
- Never edit a file someone else is editing. Say it first
- Disagree for 5 minutes max. Captain decides. Move on
- Sleep in shifts. One awake brain beats three zombies
always works"] --> A["Builder A branch
screens"] M --> B["Builder B branch
data + logic"] A --> R["Merge back
run it together"] --> M B --> R style M fill:#fff,stroke:#fff,color:#000 style A fill:#111,stroke:#333,color:#fff style B fill:#111,stroke:#333,color:#fff
If conflict happens (Git says “merge conflict”): stop, call the other person, fix it together on one screen. Never delete the other person's work to “fix” it fast.
Stop 4 · Build with AI
Never ask the agent to “build the whole app”. Loop small.
small card"] --> B["2 · Write the task
clear + small"] --> C["3 · Agent builds
watch what it changes"] --> D["4 · YOU test it
click it yourself"] --> E{"Good?"} E -- No --> B E -- Yes --> F["5 · Commit
save in Git"] --> A style A fill:#fff,stroke:#fff,color:#000 style F fill:#fff,stroke:#fff,color:#000 style E fill:#111,stroke:#555,color:#fff
30–90 minutes of work
“Add the add-item form” — good. “Build inventory system” — too big, split it.
Run it. Click it. Break it.
Read the list of changed files. If you do not understand a change, ask the agent to explain it simply.
Commit after every win
Small saves = easy undo. One giant save at midnight = no way back when it breaks.
Stop 4 · Build with AI
Same job, different style. Pick ONE main tool and learn it well.
| Tool | Where it lives | Best for | Good to know |
|---|---|---|---|
| Muse Code | Editor + terminal (T3 Code app) | Guided building, plans, checks, many helpers | Strong step-by-step flow. Good if you like seeing the plan. |
| Claude Code | Terminal (Anthropic) | Deep project work, long tasks | Reads CLAUDE.md. Very good at big refactors. |
| Codex | Terminal + editor (OpenAI) | Fast tasks, tests, parallel jobs | Reads AGENTS.md. Can run tasks in the cloud. |
| OpenCode | Terminal (open source) | Choice of models, free to run | Open source. Bring your own model/API key. |
| Cursor / Windsurf | Full editor with AI inside | Seeing code while AI edits | Easiest first day. AI sits inside your editor. |
| Chat AI (ChatGPT / Claude) | Browser chat | Ideas, explaining, small snippets | Cannot touch your files. You copy-paste. Slow for big builds. |
Beginner pick: use the one your team can all install and log into today. The best tool is the one that is already working on your laptop — not the “most powerful” one you fight for 2 hours.
Stop 4 · Build with AI
Match the tool to the job, not the hype.
edit files + run tests?"} -- No, just ideas --> CH["Chat AI
brainstorm, explain, draft text"] A -- Yes --> B{"Whole project task
or one small fix?"} B -- "Whole feature / many files" --> AG["Agent in terminal
Muse Code · Claude Code
Codex · OpenCode"] B -- "One file, I want to watch" --> ED["Editor AI
Cursor / Windsurf
edit beside your code"] B -- "Many small tasks at once" --> PA["Parallel agents
one branch per task
only if you know Git well"] style AG fill:#fff,stroke:#fff,color:#000 style CH fill:#111,stroke:#333,color:#fff style ED fill:#111,stroke:#333,color:#fff style PA fill:#111,stroke:#333,color:#fff
One main agent
Let it own the build loop. You steer with tasks and checks.
Chat as a second brain
Stuck on words? Pitch, README, naming, explaining an error — chat is great here.
Parallel = advanced
Two agents at once need two Git branches. Powerful, but easy to tangle. Skip on your first hackathon.
Stop 4 · Build with AI
A good prompt is a good task ticket, not magic words.
“Build me a stock app. Make it good.” Missing: who, what screens, what done means, what to avoid.
Result: the agent invents everything. You get a surprise, not a plan.
Goal: Add-item form for shop stock. User: shop owner on a phone. Do: fields Name + Amount, Save button. On save, item appears in the list below. Do not: no login, no photos yet. Done when: I can add “Rice, 10” and see it in the list after refresh. Stack: Next.js, keep style like Home page.
one sentence"] --> B["WHO + WHERE
user, page, file"] --> C["DO
exact behaviour"] --> D["DO NOT
limits"] --> E["DONE WHEN
how to test"] --> F["STACK / STYLE
match the project"] style A fill:#fff,stroke:#fff,color:#000 style E fill:#fff,stroke:#fff,color:#000
Extra moves that help: paste the exact error message · attach a screenshot · say “explain your plan first, wait for my OK” for big tasks · say “keep the change small” when fixing.
Stop 4 · Build with AI
Write your rules ONCE. Every agent reads them on every task.
Each tool reads a rules file in your project root. Different name, same idea — this is the highest-value 15 minutes of your hackathon.
| Tool | Rules file |
|---|---|
| Claude Code | CLAUDE.md |
| Codex · OpenCode · Muse Code* | AGENTS.md |
| Cursor | .cursor/rules/ |
*Check your tool's docs — support changes. Tip: keep one AGENTS.md and copy it to the other name. Same rules everywhere.
# AGENTS.md — copy + edit this Project: Shop stock app for small shops. Stack: Next.js + Tailwind + SQLite. Run: npm run dev Test: npm test · Build: npm run build Rules - Keep changes small. One task = one feature. - Reuse existing components. Match Home page style. - Never delete files or rewrite whole pages unless I ask. - After each task: run tests, tell me what changed in 3 simple lines. - No new libraries without asking me first.
Also optimize
Plan first: “Give me a plan, wait for OK” on big tasks. Small tasks: one card per prompt. Fresh chat when the agent gets confused — long chats drift.
Context is king
Point to the exact file/page. Paste the error. Close or ignore files the agent does not need. Less noise = better answers.
Model choice
Use the strong model for planning + hard bugs. Use the fast/cheap model for small edits and text. Save the strong one for where it counts.
Stop 4 · Build with AI
Three habits separate good agent users from frustrated ones.
Show, don't describe
- Paste the full error, not “it broke”
- Name the file and page: “in app/stock/page.tsx”
- Screenshot the broken screen
- Start a fresh session when the agent repeats mistakes — old chat = old confusion
Don't burn budget on noise
- One clear prompt beats five vague retries
- Ask for a plan before a huge build — catch wrong turns cheap
- Fast model for small fixes, strong model for design + hard bugs
- Stop a run going the wrong way early. Don't watch it dig
Always have an undo button
- Commit before a big agent task
- Review changed files before accepting
- Never accept “delete / rewrite everything” without reading it
- Keep secrets (passwords, API keys) out of code and chats — use .env, never commit it
working version"] --> B["You: give ONE
small task"] --> C["Agent: edit
+ run tests"] --> D["Agent: report
3 simple lines"] --> E["You: run it,
click it, read diff"] --> F{"Good?"} F -- Yes --> G["Commit
save progress"] --> B F -- No --> H["Undo to last
good commit"] --> B style A fill:#111,stroke:#333,color:#fff style G fill:#fff,stroke:#fff,color:#000 style H fill:#111,stroke:#f5a623,color:#f5d48a
Stop 6 · Test
Testing means: try to break your own app, on purpose, early.
do the whole story by hand
FEW — but do it often"] --> B["Feature checks
each must-have, clicked by a human
SOME"] B --> C["Automatic tests
agent writes + runs them
MANY — fast, repeatable"] style A fill:#fff,stroke:#fff,color:#000 style B fill:#111,stroke:#333,color:#fff style C fill:#111,stroke:#333,color:#fff
Ask the agent to test
“Write a test: adding ‘Rice, 10’ shows Rice in the list. Run all tests. Fix failures. Tell me results in simple words. Do not change features, only fix.”
Also ask: “Test empty input, very long text, and no internet. What breaks?”
Test by hand — the judge test
- Give the app to someone who did NOT build it. Watch silently
- Where do they pause or tap wrong? That is a design bug
- Test on a phone, slow internet, and a fresh browser
- Click everything twice. Submit empty forms. Go back mid-flow
Freeze rule: in the last 20% of time, only fix bugs that break the demo. Small visual flaws can stay. A broken demo cannot.
Stop 6 · Test
Bugs are normal. Panic-editing is the real bug.
- Stop and save. Commit what works. Note what you just changed.
- Copy the exact error. Full message + what you clicked right before it.
- Ask the agent to explain first: “Explain this error in simple words. List likely causes. Do not edit yet.”
- Fix ONE cause. Smallest change. Run. Test. Then the next.
- Stuck after 2 tries? Undo to last good commit. Try a smaller task. Ask a mentor with the error in hand.
Good bug prompt
“Error after clicking Save:
TypeError: items is not iterable
File: app/stock/page.tsx
Expected: item appears in list.
Explain simply, then fix with
the smallest change. Run tests.”Never do this
- “Fix everything” with no error pasted
- Accept 10 file changes for a 1-line bug
- Keep retrying the same prompt 6 times
- Let the agent delete code “to make the error go away”
Stop 6 · Test
Seven ways teams lose — and the one-line fix for each.
| Mistake | What happens | Fix |
|---|---|---|
| Scope too big | Everything 80% done, nothing demo-ready | 3–5 MUST features. Cut list on paper. |
| Giant prompts | Agent builds the wrong app, fast | One card, one prompt, one check. |
| No Git saves | One bad edit erases a day | Commit every 1–2 hours. |
| No demo until the end | First real test is in front of judges | Team demo at halfway. Freeze at 80%. |
| Two agents, one project | Files overwrite, chaos, conflicts | One main agent. Branches if parallel. |
| New tool on game day | 3 hours lost to setup and login | Install + test everything a week before. |
| Secrets in code | Keys leaked on GitHub — accounts abused | .env file, listed in .gitignore. Always. |
Notice the pattern: none of these are “not smart enough”. All of them are process — and process is learnable today.
Stop 7 · Present
Judges remember a story, not a feature list.
a real person,
a real pain · 30s"] --> B["0:30 SOLUTION
one sentence
what you built · 20s"] B --> C["0:50 LIVE DEMO
click the happy path
slowly · 90s"] C --> D["2:20 WHY IT MATTERS
who benefits,
what is next · 40s"] style C fill:#fff,stroke:#fff,color:#000 style A fill:#111,stroke:#333,color:#fff style B fill:#111,stroke:#333,color:#fff style D fill:#111,stroke:#333,color:#fff
Demo rules
- Rehearse twice, out loud, with a timer
- Pre-load data. Never type long forms live
- Record a backup video. If Wi-Fi dies, play the video
- Deploy early — demo from the live link, not “it works on my laptop”
- One driver, one narrator. Never swap mid-demo
Submission checklist
- Repo link + live demo link both work in a private window
- README: what, who, how to run, screenshots
- Submit 30+ minutes early. Portals crash at deadlines
- Slides are backup — the live demo is the star
Try it yourself
12 simple hackathon problems. Pick one, build the small version.
Every problem fits the 3–5 MUST-features rule. Start with the “Build this” line only. The “If time” line is your bonus — skip it until the demo works.
Shop stock tracker
Problem: small shops lose track of stock on paper.
Build this: add item (name + amount), list items, warn when amount is below 5.
Demo: add “Rice, 10”, sell 6, show the low-stock warning.
If time: search items. Data: browser storage.
Class routine helper
Problem: students forget classes and rooms.
Build this: today's classes list, add a class, highlight the next class.
Demo: show “next class in 20 minutes”.
If time: reminder colour when class is near.
Lost and found board
Problem: lost items on campus never find owners.
Build this: post a found item (name + place + photo emoji/text), list, “claim” button.
Demo: post keys, claim them, item marked claimed.
If time: search by place.
Queue number display
Problem: people crowd counters asking “my turn?”.
Build this: staff clicks “next”, big screen shows current number.
Demo: press next 3 times, number updates big and clear.
If time: sound beep on next. Great first project.
Safe water finder
Problem: people don't know the nearest clean water point.
Build this: list of water points (sample data), distance label, “nearest first” sort.
Demo: tap “near me”, nearest point on top.
If time: map view with free map library.
Medicine reminder
Problem: patients forget daily medicine.
Build this: add medicine + time, today's list, tick when taken.
Demo: add 2 medicines, tick one, progress shows 1 of 2.
If time: weekly history view.
Try it yourself
Six more — a little AI, a lot of heart.
Explain-it-simple
Problem: textbook text is hard for new students.
Build this: paste hard text, AI replies in simple words + one example.
Demo: paste a hard paragraph, show the simple version side by side.
If time: “explain like I'm 10” level switch.
Plant leaf helper
Problem: farmers notice leaf disease too late.
Build this: upload leaf photo, AI suggests possible issue + next step. Say clearly: “not a final diagnosis.”
Demo: upload sample leaf photo, show advice.
If time: history of checked leaves.
Receipt splitter
Problem: friends argue over shared bills.
Build this: type items + who ate, app splits cost per person.
Demo: 3 friends, 4 items, show each person's total.
If time: photo of receipt read by AI.
Campus help button
Problem: students don't know who to call in trouble.
Build this: big buttons (security, medical, fire) with number + location note form.
Demo: tap medical, show number and “report sent” screen (sample data).
If time: admin list of reports.
Report dirty place
Problem: dirty public places stay dirty, nobody reports.
Build this: report with place + description, list with “cleaned” tick by staff.
Demo: report a place, mark cleaned, list updates.
If time: photo upload, area filter.
30-second quiz race
Problem: study revision is boring alone.
Build this: 10 questions, timer, score, best-score board (same device).
Demo: play one round, beat the best score.
If time: AI writes questions from pasted notes.
How to choose in 2 minutes: pick the problem where you can name one real person who has it. Then cut it to one form + one list + one happy-path demo. That is your whole hackathon.
Take this with you
Your hackathon checklist. Screenshot this slide.
- Tools installed + tested
- One stack chosen
- Repo + deploy works
- AGENTS.md / CLAUDE.md written
- Team roles named
- One-sentence idea
- 3–5 MUST features only
- Small loops: task → check → commit
- Check-in every 2–3 hours
- Team demo at halfway
- Freeze at 80% time
- Judge-test with fresh eyes
- Backup demo video
- Submit 30 min early
- Rehearse twice, timed
The one idea to keep: agents made building fast. Winning is now about choosing small, checking often, and finishing. You do not need to be the best coder in the room. You need to be the clearest thinker with a working demo.
Questions? Find me after — or reach me any time.