Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersHackathon ideas: 12 projects that demo well in 24 to 48 hours
A good hackathon idea shows its whole value in a three-minute live demo: one input, one visible result, one person who needs it. Pick a project where the input can be a photo, a voice note, a QR scan or a broken deploy, because judges can watch those work. Below are 12 hackathon project ideas, each with the customer, the problem, a first version you can finish in 24 to 48 hours, a demo script, a way it could earn money later and the hard part.
What makes a good hackathon idea?
A hackathon rewards the project people can understand in under a minute and watch work once. That is a different test from a good startup idea. A startup idea survives months of use. A hackathon idea has to survive a three-minute slot, a conference Wi-Fi network and a judge who walks up halfway through your sentence.
So the filter is not “is this big?” but “can I show it working with one real input?” The ideas below all pass the same five checks.
| Check | Passes | Fails |
|---|---|---|
| One input | A photo, a voice note, a QR scan, a pasted error | A setup screen with six fields |
| One visible result | A filled form, a map pin, a text message that arrives | A dashboard that needs a week of data |
| One named person | “A site inspector with muddy gloves” | “Businesses” or “everyone” |
| Fakeable data | You can seed realistic sample data in an hour | It needs a partner's private data |
| Survives bad Wi-Fi | A recorded fallback clip or an offline path exists | The demo dies if one API is slow |
Each idea also has a hard part. Say it out loud in your pitch before a judge finds it. A team that names its own weakest point reads as having thought about the problem; a team that is caught by it reads as having hidden it.
How should you spend 24 to 48 hours at a hackathon?
Most teams lose the weekend by building features. The teams that demo cleanly fix the demo path first, then add. Use this split for a 48-hour event and halve each line for a 24-hour one.
| Hours | Do | Skip |
|---|---|---|
| 0–3 | Write the one-sentence pitch, the customer and the demo script. Agree what is fake. | Choosing a logo, debating frameworks |
| 3–20 | Build the single path from input to result, with real code on the middle step | Login, settings, second user type |
| 20–32 | Handle the two ways it fails on stage; seed sample data; add the one extra feature | Refactors |
| 32–42 | Record a backup video of the full demo; rehearse three times with a timer | New features |
| 42–48 | Fix only what rehearsal broke; write the submission text; submit early | Anything that touches the deploy |
0:00 One sentence: who has the problem and what it costs them today. 0:20 Show the problem on screen in the old way (10 seconds, no talking). 0:35 Do the real thing live with one real input from the audience or a judge. 1:30 Show the result and say what it replaced. 2:00 Name the hard part and what you did about it. 2:20 One sentence on who would pay and why. 2:40 Stop. Leave 20 seconds of silence for questions.
If you build with an AI coding tool, give it the demo script as the definition of done. A prompt that ends with “done when the script above runs without edits” keeps it from adding screens nobody will see. The AI coding prompt builder turns the idea, the customer and the demo into a prompt you can paste, and the guide to scoping an MVP covers what to cut.
Which hackathon project ideas demo well?
These 12 are sorted from the most physical demo (a person, a phone, a room) to the most technical. Every demo script assumes you have one laptop, one phone and one volunteer. Pricing lines are things to test after the event, not forecasts.
01 Voice-to-form for site inspectors
An inspector talks through a room and a checklist form fills itself in, with the photo attached to the right line.
- Customer
- A property or construction inspector walking a site with gloves on and a phone in one hand.
- Problem
- Notes are taken on the spot and typed into a form at night, so details are lost and the evening is gone.
- First version
- A web page with a fixed 12-line checklist. Hold a button, speak, and speech-to-text plus one model call places each sentence under the matching line.
- Makes money
- A monthly price per inspector, to test around USD 30 a month, or a fee per report.
- Hard part
- Background noise, and the model assigning a note to the wrong line. Show the transcript beside the form so a human can correct it.
The demo works because the audience can see the form fill as you talk. Seed a fake room on a table (a cracked cup, a stained napkin) so the judges watch a real inspection take place. After the event, the extension is a custom checklist builder and a PDF export, not more AI.
Say: "Inspectors type their notes at night. Watch." Tap record. Say aloud: "Window two, hairline crack in the lower left pane, no water damage." Show the form line for window two filling in and the photo attaching. Say: "The hard part is noise, so the transcript sits right there to correct."
02 Whiteboard photo to tickets
Photograph a whiteboard covered in sticky notes and get a list of tasks with owners and rough order, ready to paste into a tracker.
- Customer
- A small team lead who ends every planning session with a whiteboard nobody will transcribe.
- Problem
- The plan lives on the wall until someone wipes it or a cleaner does.
- First version
- Upload a photo, send it to a vision model with a strict output format (title, owner if written, group) and render an editable table with a copy button.
- Makes money
- A flat team price, or free with a paid export to a tracker's import format.
- Hard part
- Handwriting and arrows. Do not promise dependencies; list groups by position and let the user drag.
Ask a judge to write three tasks on a sticky note before your slot. A live, unseen input is stronger than any screenshot. The extension is an integration that creates the tickets directly, which is also the thing to leave for after the weekend.
Hand a judge three sticky notes before you start. Stick them up, take one photo. Show the table with the judge's own words in it. Say: "Handwriting is the hard part, so every row is editable before it goes anywhere."
03 Doorbell and alarm listener for deaf and hard-of-hearing users
A phone app that listens for a short list of household sounds and sends a strong vibration and a large on-screen message.
- Customer
- A deaf or hard-of-hearing person living alone or with hearing family out at work.
- Problem
- Doorbells, smoke alarms and kettles give no signal other than sound.
- First version
- A web page using the microphone and an open sound-classification model for three sounds. When it matches, show a full-screen message and vibrate.
- Makes money
- Hard. Test a one-off price for the app, or sell a licence to housing associations and care providers.
- Hard part
- False negatives. A smoke alarm app that misses once is dangerous, so state clearly it is a convenience and not a safety device.
Play a doorbell recording from a second phone on stage and let the first phone react. Do not claim it replaces a certified alarm; say what it does in one sentence, and keep the three sounds you can test reliably. Involve a person from the community in the weekend if you can, because the judges will ask whether you did.
Say: "Most home alerts are sound only." Place the app on the table, screen up. Play a doorbell clip from a second phone. The app flashes and vibrates. Say: "It misses sounds sometimes, so it is a helper, not a safety device."
04 Join-by-QR audience game
The judges scan a code and play a 60-second game on their own phones, with scores on the big screen.
- Customer
- A teacher, event host or conference organiser who wants everyone playing, not watching.
- Problem
- Quiz tools need accounts, app installs or a code typed in, and half the room gives up.
- First version
- One page per room. Phones open the link, enter a nickname, answer a question. A server pushes scores to the host screen over a websocket or a realtime channel.
- Makes money
- A host plan for larger rooms, or a fee per event.
- Hard part
- Forty phones joining at once on poor Wi-Fi. Test with five browser tabs and keep the first screen tiny.
This is the safest hackathon demo because the judges are the users. The same mechanic powers a group poll that closes itself from the board, where the point is the ending rather than the game. Pre-load the questions and keep a mobile-data hotspot ready as a fallback.
Show the QR code on the big screen. Say: "Scan it. No app, no account." Wait ten seconds. Show the player count rising. Run one question. Show scores updating. Say: "The hard part is a full room on bad Wi-Fi, so the first screen is under 10 KB."
05 Duplicate-merging live Q&A
Audience questions arrive from phones and similar ones are grouped, so the speaker sees five themes instead of fifty lines.
- Customer
- A conference speaker or class lecturer with a big room and ten minutes for questions.
- Problem
- The same question is asked six ways, and the loudest wording gets answered.
- First version
- A submission page, an embedding or one model call that groups questions, and a host view showing groups with counts and an Answered button.
- Makes money
- A per-event price, or a seat for a university department.
- Hard part
- Over-merging two different questions. Show the original wordings under each group.
Seed fifteen questions before the demo, three of which are the same question in different words. Then let the judges add theirs live. The extension is moderation and an anonymous mode, which is where real events spend their time.
Show the seeded list of 15 questions. Click Group. Five themes appear with counts. Ask a judge to submit one new question from their phone. It lands in the right group. Say: "Each group lists the original wordings, so nothing gets merged silently."
06 Soil sensor that texts you
A cheap moisture sensor on a microcontroller sends a message when the plant needs water, and one more saying how long it will last.
- Customer
- A person with a balcony garden, an office plant or a community-garden plot.
- Problem
- Plants die between visits, and an app full of graphs is harder than a text.
- First version
- One board, one sensor, a small server that reads a value every hour and sends a message when it crosses a threshold you set during the demo.
- Makes money
- Sell kits, or sell the alert service to offices that already pay for plant care.
- Hard part
- Calibration. Sensors drift and soils differ, so the first version needs a two-point calibration step.
Hardware demos win attention because they are physical, and fail because of cables. Bring a spare board and pre-flash it. Dip the sensor in a glass of water during the pitch and have the text arrive within seconds by lowering the polling interval for the demo only.
Hold up the dry plant with the sensor. Say: "This one has not been watered for a week." Show the phone with the text already received. Water the plant. Show the next reading rising. Say: "Calibration is the hard part, so setup takes two readings: dry and wet."
07 Plain-language rewriter for official pages
A browser extension that rewrites a confusing government or insurer page into short sentences, keeping the original beside it.
- Customer
- A person reading a tax, benefits or insurance page in a second language or under stress.
- Problem
- The page is correct and unreadable, and a wrong guess about it costs money.
- First version
- An extension with one button that sends the visible text to a model with a rule: simpler words, same facts, nothing added, list every number and date unchanged.
- Makes money
- Sell to charities and advice centres, which already explain these pages by hand.
- Hard part
- The model silently changing a number or a deadline. Highlight every digit string and diff it against the source.
The number diff is what makes this a real project and not a prompt in a box. Show a failing case on purpose: a rewrite where the checker catches a changed date. Judges remember a team that demonstrates its own safety net.
Open a real, dense public page. Say: "Nobody reads this." Click Rewrite. Show the short version beside the original. Point to the green line: "All 7 numbers and dates match." Show a second page where the checker flags a mismatch. Say: "That is the part that matters."
08 Council meeting chapters
Paste a link to a long public meeting recording and get a titled, time-stamped list of what was decided.
- Customer
- A local resident, journalist or neighbourhood group tracking planning and budget votes.
- Problem
- Meetings run for four hours and decisions are buried in the third.
- First version
- Transcribe one recording ahead of time. A model returns chapters with start times and a list of motions, each linking to the exact second.
- Makes money
- A paid alert for a specific topic or street, or a licence to a local news outlet.
- Hard part
- Speaker names and who voted how. Only report what the transcript says and link to the second so a person can check.
Pick a real recording from your own town so a judge can check it. The line that lands is “click this vote and hear it”, because every claim links to the audio. The extension is topic alerts by email.
Say: "This meeting is 3 hours 40 minutes." Show 9 chapters. Click the one titled with a vote. Play the 20 seconds of audio at that timestamp. Say: "Every claim links to the moment it was said, so you do not have to trust us."
09 Hint ladder for homework photos
Photograph a maths or physics problem and get three levels of hint, each one revealed only on request, and never the answer.
- Customer
- A parent or tutor who wants to help without doing the work, or a student stuck at 9 pm.
- Problem
- Answer-giving tools teach nothing, and parents no longer remember the method.
- First version
- Upload a photo, extract the problem, return hint 1 (what kind of problem), hint 2 (the first step), hint 3 (the method with a different example) as three collapsed cards.
- Makes money
- A family subscription, or a licence to a tutoring centre.
- Hard part
- Leaking the answer in a hint, and getting the maths wrong. Test it against ten problems with known answers and show the results.
Bring ten problems with known solutions and run them live for the first minute of Q&A. A judge asking “what if it is wrong?” gets a table of results instead of an apology.
Photograph a printed algebra problem. Show hint 1 only. Tap hint 2. Tap hint 3. Say: "It never shows the answer." Show the test table: 10 problems, how many hints leaked the answer, how many were wrong.
10 Lost-and-found matcher
Staff photograph a found item; an owner describes or uploads a photo of what they lost; the system ranks likely matches.
- Customer
- A venue, campus or transit desk that holds a box of unclaimed umbrellas, bottles and chargers.
- Problem
- Finding the item means a person digging through the box while a queue forms.
- First version
- An intake page that stores a photo and a model-written description, and a search page that ranks items by description match with the photos shown.
- Makes money
- A monthly price per venue, which the venue weighs against desk time.
- Hard part
- Identity and false claims. A match is a suggestion; the desk still checks a detail only the owner would know.
Bring five real objects. Photograph them before the demo, hand the phone to a judge and say “you lost a blue bottle”. The extension is a notification when a matching item is handed in later.
Place five items on the table. Photograph three in the app. Hand a judge the phone: "You lost a blue metal bottle with a dent." Show the ranked matches, the right one first. Say: "The desk still asks for a detail only the owner knows."
11 Broken deploy to plain-English incident note
Break a small app live; the tool reads the logs and the last change and writes a three-line incident note for non-engineers.
- Customer
- A small team where the person who understands the error is not the person who has to tell the customer.
- Problem
- Status updates written at 2 am are vague or wrong, and the log is unreadable to everyone else.
- First version
- A script that takes the last 200 log lines and the latest commit diff and returns: what broke, who is affected, what we are doing, in under 60 words.
- Makes money
- A seat price for on-call teams. Compare it with tools they already pay for.
- Hard part
- Guessing impact it cannot see. Only state what the logs support, and write unknown where it does not know.
A live break is the best opening in a developer track. Keep a one-line change ready that causes a 500 error, run it, and let the tool write the note. The extension is posting to a team chat channel. If you want a related idea to build, the board has one about which env var changed between two deploys.
Push a change that breaks the page. Show the 500 error. Run the tool. Show the three-line note. Point to the word "unknown" next to impact: "It does not guess what it cannot see."
12 Post-storm neighbour check-in map
After an outage or storm, neighbours tap one of three buttons on a map and the block organiser sees who still needs help.
- Customer
- A block or building organiser, and the residents who are home and cannot reach anyone.
- Problem
- Group chats become noise, and older neighbours with no smartphone are invisible.
- First version
- A page with a map, three buttons (fine, need help, can help), a list sorted by need, and a printable street sheet for people offline.
- Makes money
- Not obvious. Test with housing associations, local councils or a paid emergency-planning kit.
- Hard part
- Trust and privacy. Show only a block, never an exact address, and say clearly that it is not an emergency service.
The printed street sheet is what makes the judges nod. It shows you thought about the person without a phone. Make the demo about the organiser's view: ten pins appear as a room full of people tap in.
Ask the room to scan a QR code and tap one button. Show pins appearing, with red ones at the top of the list. Print the street sheet and hold it up. Say: "This is not an emergency service. It tells you who to knock on first."
What should you do with a hackathon project afterwards?
Most hackathon projects stop on Sunday night. That is fine, but three small steps keep the option open. First, write down the customer and the hard part while you remember them. Second, show the demo to five people who match the customer, not to other developers. Third, decide within a week whether you are building it, selling it to a better-placed team or letting it go.
If you know you will not build it, post it where a builder can find it. Post your build ideas takes the idea without an account and gives it a build prompt anyone can paste into an AI coding tool. If you want a project that already has a written problem, browse the developer tools ideas. To judge whether a project deserves another weekend, use the validation guide.
Frequently asked questions
What are good hackathon project ideas for beginners?
Pick a single-input project: a form filled by voice, a QR game, a photo turned into a list. These need one page, one outside service and one live demo path. Avoid anything with accounts, payments or hardware you have not used before. The first three or four ideas above are built around exactly that limit.
How long should a hackathon project take to build?
A usable demo takes roughly half the available time. In a 48-hour event, aim to have the full input-to-result path working by hour 20, then spend the rest on failure cases, sample data and rehearsal. In a 24-hour event, that moment is hour 10. Late features rarely survive the stage.
Should a hackathon project be a startup idea?
It does not have to be, but judges often ask who would pay. Prepare one sentence naming the customer and a price you would test. A project that is only a clever demo can still win; a project with a named buyer is easier to continue afterwards.
Can you use AI coding tools at a hackathon?
Many events allow them, but rules vary, so read the event's rules page and ask the organisers if it is unclear. If allowed, use the demo script as the definition of done in your prompt so the tool builds the demo path first and does not add extra screens.
What should you prepare for the demo?
Prepare sample data, a backup video of the full demo, a second device on mobile data and a three-minute script rehearsed three times with a timer. Decide in advance which parts are faked and say so if asked. Judges respect honesty about limits more than a demo that quietly fails.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.