12 Hackathon Project Ideas You Can Demo in 48 Hours

Most hackathon projects don't fail on code. They fail at 2am, when a team has six half-built features and none that works from start to finish. Every idea below is scoped so the core flow can work by the halfway mark, with a track it fits, what to demo, the features that matter and a stack hint. Where an idea depends on an outside API or service, the rule that matters was read on that provider's own docs in November 2026.

How to pick an idea you can finish

• Write the demo sentence first. "Upload a receipt, tap names, see who owes what." If you can't write it, the idea is too vague.
• Count the moving parts. One model call plus one database is a 24-hour build. Webhooks, maps and live sync each add a day of risk.
• Get keys and data before the clock starts. API sign-ups and sample files are the classic first-hour time sink.
• Fake the hard part, then replace it. Hard-code sample output so the screens work, then swap in the real call.

Our guide to AI coding workflows for hackathons covers how to run the event itself: scoping, task splits, testing and the pitch. This post is about what to build.

All 12 ideas at a glance

The ideas in detail

1. Lecture notes to practice quiz

Build first: one text box that turns pasted notes into five questions, each with the sentence it came from. Data: your own notes; ask before using a lecturer's slides. Watch out for answers the model invents, which is why every question should quote its source. Stack hint: any front end plus a model API that returns JSON.

2. Receipt splitter from a photo

Build first: the split screen with typed-in items, then the photo step. Both Anthropic and OpenAI document image input for their models. Watch out for misread prices: make every line editable before anyone pays, and crop card details out of sample photos.

3. Meeting transcript to task board

Build first: transcript in, a JSON list of owner, task and due date out. Data: a transcript you wrote or one your team records on the day. Watch out: tasks with no clear owner should land in an "Unassigned" column, and the model must leave a date blank rather than guess one.

4. Fridge photo to meal plan

Build first: an editable ingredient list from a photo, then recipes that use what expires first. Watch out: ask about allergies before suggesting anything, and expect the model to mislabel some items, so the list must be easy to fix.

5. Plain-English accessibility auditor

Build first: a server route that loads a URL in a headless browser and runs axe-core, Deque's open-source accessibility testing engine (MPL-2.0). Then add the plain-English layer. Watch out: axe-core marks some results incomplete when it can't be certain, and its README says those need manual review, so never present a clean scan as proof a site is accessible.

6. Neighborhood help board on a map

Build first: post and claim requests in a list, then add the map with Leaflet. If you use the standard OpenStreetMap tiles, the tile usage policy requires visible attribution and forbids bulk downloading or prefetching tiles. Watch out for privacy: show an approximate area, never a home address.

7. Clean-air walking route

Build first: a map showing the latest readings from sensors near two points. Data: the OpenAQ API, which needs an API key sent in an X-API-Key header and enforces rate limits. Watch out: sensors can be sparse, so show how old each reading is and don't present the result as health advice.

8. Ask questions of a city open-data file

Build first: load one CSV, such as service requests from your city's open-data portal, into a database, and let the model write a SQL query for a typed question. Watch out: run generated SQL only against a read-only copy, and show the query next to the answer so judges can check it.

9. Pull request explainer bot

Build first: a small server that receives GitHub's pull_request webhook event, fetches the diff and posts a comment. GitHub's webhook docs describe the X-Hub-Signature-256 header sent when you configure a secret; check it so strangers can't trigger your bot. Watch out for secrets in diffs before you send code to a model.

10. Voice symptom diary

Build first: speak an entry, see the text, tag symptom, time and severity. The browser's SpeechRecognition API has limited availability, MDN says, and in Chrome the audio goes to a server, so it won't work offline. Watch out: health data is sensitive. Keep it on the device, and say on screen that the app does not diagnose.

11. Live classroom quiz game

Build first: a host screen and a join-by-code player screen with one question. For live updates, Supabase Realtime offers Broadcast for low-latency messages and Presence for tracking who is online. Watch out: venue wifi. Test with twenty phones and keep a recorded backup of the demo.

12. Docs answer bot with citations

Build first: ingest one public docs site, split it into sections, embed them and answer only from the top matches, with links. Supabase stores embeddings in Postgres through the pgvector extension. Watch out: the bot should refuse when nothing relevant comes back, and you should respect the docs site's terms when you copy its content.

If an AI idea grabs you but you'd rather build it over a few evenings, our AI project ideas and weekend AI projects go further, and the weekend games list suits a gaming track.

First prompts to try

These open the build for three of the ideas. Paste one into an AI app builder or a coding assistant, replace the [square brackets], and get the screens working before you connect any real API.

First prompt: receipt splitter

Builds the whole demo path in one pass. Wire in the real model call after the screens work with fake data.

Build a mobile-first web app called [app name] that splits a restaurant bill.
Screen 1: upload or take a photo of a receipt.
Screen 2: show the extracted line items (name, quantity, price) in an editable table, plus tax and tip fields.
Screen 3: add up to 6 people by name, tap items to assign them, and allow an item to be shared between several people.
Screen 4: show what each person owes, with tax and tip split in proportion to their items.
For now, fake the extraction step with this sample receipt: [paste 5 to 8 sample line items].
Keep all data in the browser. No login.

First prompt: accessibility auditor

Keeps the scan and the explanation as separate steps, so you can show the raw findings next to the plain-English version.

Create a web app with one input: a URL.
When submitted, a server route opens the page in a headless browser, runs axe-core and returns the violations as JSON (rule id, impact, help text, affected HTML).
Group the results by impact (critical, serious, moderate, minor) and show a count for each.
For each violation, add a button "Explain" that sends the rule id and affected HTML to [model provider] and shows: what is wrong, who it affects, and the corrected HTML.
Show items axe-core marks as incomplete in a separate list labelled "Needs a human check".

First prompt: neighborhood help board

Sets up the data model and the privacy rule on day one, which is the part teams usually patch in at 3am.

Build a neighborhood help board.
Data: requests with title, category (groceries, ride, repair, other), approximate area, status (open, claimed, done), created time.
Pages: a map of open requests using Leaflet with OpenStreetMap tiles and visible attribution, a list view, a form to post a request, and a button to claim one.
Privacy rule: never store or show an exact address. Snap each pin to the center of a [500 m] grid square.
Use [Supabase or your database] for storage and email sign-in. Seed it with 15 realistic sample requests around [city].

A 24-hour and 48-hour plan

1. First 10 percent of the time: write the demo sentence, sketch the screens, get every key and sample file.
2. To the halfway point: the core flow works end to end with real data, even if it's ugly.
3. Next quarter: fix what breaks the demo, then add one feature that makes the result clearer.
4. Last quarter: freeze features, deploy, record a backup video and rehearse the pitch three times.

At 24 hours, stay with an easy idea. At 48 hours, a medium idea is realistic for a team of three or four. Save the docs answer bot for a team that has built search or embeddings before.

How to choose

Match the idea to the track first, then to your team. A designer-heavy team should pick something with a strong visual result, such as the receipt splitter or the map board. A backend-heavy team can take the pull request bot or the open-data tool, where the demo is a correct answer, not a pretty screen. If a sponsor offers an API prize, choose the idea where that API does the visible work. Still undecided? The 12 vibe coding projects list has more builds sized for a weekend.

Frequently Asked Questions

What is a good hackathon project idea for beginners?
Pick one of the easy ideas, such as the lecture-notes quiz, the receipt splitter or the meeting-notes task board. Each has one input, one AI call and one screen to show, so a beginner team can finish it and still have time to rehearse the demo.

How big should a hackathon project be?
Small enough that the core flow works end to end by the halfway point. Scope one user, one job and one happy path. Everything else, such as accounts, settings and extra pages, waits until the demo path works twice in a row.

Which hackathon ideas use AI without being a chatbot?
Most of the ideas here use a model behind a normal interface: reading a receipt photo, turning a transcript into tasks, explaining accessibility issues, summarizing a pull request or answering from documentation with citations.

Do I need an API key for these projects?
Usually yes. Model providers need an account and key, and so does OpenAQ for air quality data. Get keys before the event starts, keep them in server-side environment variables and never ship them in front-end code.

How do I make a hackathon demo that judges remember?
Show a real input producing a visible result in under a minute, say who it is for in one sentence, and keep a recorded backup in case the venue network fails. Judges remember the moment the thing worked, not the slide about your stack.