Hackathon Project Ideas

Last updated: September 2026.

Picking a hackathon theme is easy—scoping a challenge brief well enough that teams don’t waste the first six hours guessing is the hard part. Most hackathon project lists give developers a single sentence like “build an AI mental health app” and wonder why 70% of submissions stall out on day two. Vague prompts create decision paralysis, feature creep, and half-baked pitch decks.

At Kreativdistrikt, whether we are structuring high-stakes challenges for the European Commission, De Nora, or Tietoevry, we enforce one rule: a great hackathon project idea is a scoped product brief, not a wishlist.

Why Scoped Briefs Outperform Free-Form Ideation Every Time

Allowing teams to “build whatever they want” sounds liberating, but in practice, it creates decision paralysis. When we facilitated the Internet of Water (IoW) Ideathon with De Nora, success didn’t come from open-ended brainstorming. It came from establishing tight technical boundaries around real-world water management problems before a single participant entered the room.

When designing problem statements for your event, your briefs must pass three core operational tests:

1. The 48-Hour Feasibility Test: Can a cross-functional team build a testable, live-demoable micro-prototype in two days? If the project requires real-time integration with legacy utility billing or regulatory compliance sign-offs, downscope the prompt to focus purely on the core algorithmic or user interface layer.

2. The “Domain Expert” Constraint: Does the project force technical talent to collaborate with non-technical subject matter experts? In civic or ESG challenges—such as our work on the EU CodeWeek and Blue-Cloud hackathons—the strongest builds come from pairing machine learning developers with field domain experts who actually understand the end-user workflow.

3. The Pilot-Readiness Boundary: Is there a clear path to turn the winning prototype into a post-event pilot? The goal isn’t to invent hypothetical solutions to world hunger; it’s to validate a specific mechanism that your organization or sponsors can incubate on day 3.

Project Ideas For Inspiration

#1 Decentralised Peer-to-Peer Energy Trading Platform:

 

Develop a blockchain-based platform that lets homeowners with solar panels trade excess energy with their neighbours. What teams build: a working demo of the transaction flow — a homeowner listing surplus output, a neighbour buying it, a smart contract or ledger entry settling the trade. Team mix: one blockchain/smart-contract developer, one energy-domain advisor (even someone who’s just read up on net metering rules), one product/UX person to make the flow understandable to a non-technical homeowner. Realistic 48-hour scope: a simulated trade on a testnet with 2-3 mock households — not a live integration with real smart meters or utility billing, which is a multi-month regulatory problem on its own.

 

#2 AI-Powered Mental Health Chatbot for Adolescents:

 

Create a chatbot designed to support teenagers with mental health concerns, using NLP and machine learning. What teams build: a conversational prototype that recognizes a handful of common distress signals in text and responds with a safe next step — not diagnosis or crisis counseling, just routing to a real resource. Team mix: one NLP/ML developer, one person with genuine familiarity with adolescent mental health safeguarding guidelines. This is the one idea on this list where getting the guardrails right matters more than the tech. Realistic 48-hour scope: a scripted-flow demo with a small set of tested conversation paths and hard-coded escalation to real hotlines — not an open-ended chatbot, which raises safety questions no hackathon prototype should try to solve alone.

 

#3 Smart Urban Farming Systems:

 

Design an IoT-enabled urban farming solution that uses AI to optimise plant growth in small city spaces. What teams build: a sensor rig (real or simulated) feeding light/moisture/temperature data into a simple model that recommends watering or lighting adjustments for one specific crop in a constrained space. Team mix: one IoT/hardware-comfortable developer, one data/ML person for the optimization logic, one person with basic horticultural knowledge — it changes what “optimise” actually means in practice. Realistic 48-hour scope: a working dashboard with live or simulated sensor readings and recommendations for one crop type — not a fully autonomous growing system.

 

#4 Personalised Learning Paths for Special Needs Education:

 

Build a platform that uses AI to create customised educational content for students with special needs. What teams build: a demo that takes one defined learning need (e.g. dyslexia-friendly reading pacing, or a specific IEP-style goal) and adapts a small set of practice materials to match it. Team mix: one ed-tech/AI developer, one person with real special-education experience or direct familiarity with an existing framework (IEP structures, UDL principles). Good intentions without domain input tend to produce something well-meaning but unusable here. Realistic 48-hour scope: content adaptation for one need and one subject area, demoed against a handful of sample student profiles — not a platform covering every disability category.

 

#5 Autonomous Waste Sorting and Recycling Robot:

 

Develop a robotic system that can autonomously sort and recycle household waste. What teams build: a computer-vision model that classifies 5-6 common waste categories from a camera feed, paired with either a physical sorting mechanism or a simulated one. Team mix: one computer-vision/ML developer, one hardware/robotics person if attempting a physical build, one person to curate a realistic training/test image set — sourcing decent data is usually the actual bottleneck, not the model. Realistic 48-hour scope: reliable classification on a narrow item set with a live camera demo. A full physical sorting robot in two days isn’t realistic — target the vision layer and mock the physical sorting.

 

#6 AI-Driven Urban Mobility Solutions:

 

Create an AI-based platform to optimise urban transportation. What teams build: a model addressing one specific mobility problem — bus-schedule optimization for a known route, bike-share rebalancing, or congestion prediction for one corridor — not “transportation” broadly. Team mix: one data/optimization developer, one person to source or realistically fake transit data, one person to frame the actual decision the tool supports — what would a planner do differently because of this? Realistic 48-hour scope: a model and visualization for one route or zone using real or realistic public transit data — not a citywide system.

 

#7 Real-Time Wildlife Monitoring and Poaching Prevention:

 

Build a network of smart cameras and sensors in wildlife reserves to monitor animal movements. What teams build: an image or audio classification demo distinguishing target species (or human presence) from a sample dataset, with a basic mockup of the alert flow when something’s detected. Team mix: one computer-vision or audio-ML developer, one person to handle the alert/notification flow, ideally someone with conservation-sector context — real deployments have connectivity and power constraints most teams won’t think of. Realistic 48-hour scope: a classification-accuracy demo on a curated sample dataset plus a mocked alert dashboard — not a live sensor network, which is a hardware deployment problem beyond hackathon scope.

 

#8 Adaptive Fitness App for the Differently-Abled:

 

Develop a fitness application tailored for people with disabilities. What teams build: a workout-adaptation demo for one specific constraint (limited lower-body mobility, visual impairment) rather than “disabilities” as one category — the right adaptations differ enormously by need. Team mix: one app developer, one accessibility-focused designer (screen-reader compatibility, motion alternatives), and real input from someone with lived experience of the constraint being designed for — even a short conversation before day one changes the output. Realistic 48-hour scope: a working adapted routine for one defined constraint, demoed live — not a comprehensive app covering every disability type.

 

#9 Smart Disaster Response System: 

Design an integrated platform that uses drones, IoT devices, and AI to coordinate disaster response efforts. What teams build: a coordination dashboard for one disaster type (flood, wildfire, earthquake) that ingests one defined data feed (simulated drone imagery, sensor readings, or crowd-sourced reports) and prioritizes response actions. Team mix: one full-stack/data developer, one person for the mapping/visualization layer, ideally someone with emergency-management or logistics background to keep the prioritization realistic. Realistic 48-hour scope: a working dashboard for one scenario and one data feed — not a genuinely multi-sensor, multi-agency system, which real platforms take years to build.

 

#10 Circular Economy Marketplace:

Create a digital marketplace that promotes the circular economy by connecting consumers with businesses. What teams build: a listing-and-matching flow for one specific material or product category (commercial textile offcuts, used electronics components) rather than a general marketplace — liquidity problems are category-specific. Team mix: one full-stack developer, one person to define the matching/pricing logic, one person to sanity-check the business case against a real circular-economy use case. Realistic 48-hour scope: a functioning listing-and-matching demo for one category with realistic mock listings — not a live multi-category marketplace with real transactions.

 

#11 AI-Powered Web Accessibility Scanner: 

Build a tool that scans a live website and flags real WCAG violations — missing alt text, poor color contrast, unlabeled form fields — with a plain-language fix suggestion for each. What teams build: a scanner that crawls a handful of pages and produces a prioritized, non-technical findings report. Team mix: one front-end/automated-testing developer, one accessibility specialist or screen-reader user who can validate the findings are real, not just rule-matching. Realistic 48-hour scope: a working scan of 3–5 pages on one real or test site with an exportable report — not a full enterprise accessibility-monitoring platform.

 

#12 Blockchain Supply Chain Transparency Tracker: 

Create a system that lets a buyer trace one product back through its supply chain using a shared, tamper-evident ledger. What teams build: a demo tracking one product category (coffee, electronics components) through 3–4 defined supply-chain stages, with each stage logging a verifiable entry. Team mix: one blockchain/backend developer, one person to map a realistic supply-chain flow, one UX person to make the trace readable to a non-technical buyer. Realistic 48-hour scope: a simulated trace through a handful of stages with mock but realistic data — not integration with real logistics or customs systems.

 

#13 Remote-Team Burnout Early-Warning Dashboard: 

Build a tool that surfaces early burnout signals from anonymized, opt-in workplace data (meeting load, after-hours activity, sentiment in check-ins) without becoming invasive surveillance. What teams build: a manager-facing dashboard flagging a handful of early-warning patterns for a sample team. Team mix: one data/dashboard developer, one person with real HR or occupational-psychology context to keep the signals genuinely useful instead of creepy. Realistic 48-hour scope: a dashboard built on a realistic synthetic dataset for one sample team — not a system connected to real employee data.

 

#14 AR Wayfinding for Visually Impaired Pedestrians: 

Design an app that gives audio-first turn-by-turn guidance through indoor or dense outdoor spaces, built around real accessibility needs rather than a visual AR overlay. What teams build: a working audio-guidance demo for one defined route (a building floor, a transit station). Team mix: one mobile/AR developer, one audio-UX person, ideally someone with direct experience navigating with low vision to sanity-check the guidance actually helps. Realistic 48-hour scope: a guided walkthrough of one pre-mapped route — not a general-purpose indoor-mapping product.

 

#15 Food Waste Redistribution Matching App: 

Build a marketplace that matches surplus food from restaurants/grocers with local charities or individuals before it’s thrown out. What teams build: a listing-and-claim flow for one neighborhood or one partner business, with a simple pickup-coordination step. Team mix: one full-stack developer, one person to map realistic food-safety and logistics constraints, one person to think through the charity/recipient side of the match. Realistic 48-hour scope: a working listing-and-claim demo for a handful of mock donors and recipients — not a citywide logistics network.

 

#16 Voice-First Civic Issue Reporting Tool: 

Create a voice-based way for residents to report a civic issue (a broken streetlight, a pothole) without needing to fill out a form or use an app fluently. What teams build: a voice-to-structured-report pipeline that captures location, issue type, and description from a short spoken description. Team mix: one speech/NLP developer, one person to define the structured report format local governments can actually act on. Realistic 48-hour scope: a working voice-to-report demo for 3–4 issue categories — not integration with a real municipal ticketing system.

 

#17 Gamified Financial Literacy App for Teens: 

Build a game-like app that teaches one specific financial skill (budgeting, understanding compound interest, spotting a scam) through short interactive scenarios rather than lecture-style content. What teams build: a playable demo covering one skill with a handful of scenarios and a simple progress mechanic. Team mix: one app developer, one game/UX designer, ideally someone with teaching or financial-literacy curriculum experience to keep the scenarios accurate. Realistic 48-hour scope: a playable demo of one skill module — not a full curriculum covering every financial topic.

 

#18 Predictive Maintenance Dashboard for Small Manufacturers: 

Design a tool that flags when a piece of factory equipment is likely to fail soon, using sensor data small manufacturers can actually afford to collect (vibration, temperature) rather than enterprise-grade IoT. What teams build: a model that predicts failure risk for one machine type from a sample sensor dataset, shown on a simple dashboard. Team mix: one data/ML developer, one person with real manufacturing or maintenance background to validate what signals actually matter. Realistic 48-hour scope: a working risk-prediction demo on a realistic sample dataset for one machine type — not a live sensor deployment.

The Importance

A good hackathon project idea list isn’t a brainstorm — it’s a set of decisions already made for the team, so they can spend their 48 hours building instead of arguing about scope. That’s the standard we hold every brief to when we design hackathon experiences for clients like the European Commission, De Nora, and Tietoevry, and it’s why each idea above spells out the team mix and the realistic 48-hour boundary rather than leaving teams to figure that out mid-event. The ideas themselves matter less than how tightly they’re scoped — a loosely-defined “build an AI app for healthcare” prompt produces ten half-finished demos, while a scoped brief produces ten comparable, judgeable prototypes. That’s also what makes these ideas a strong starting point for team-building events specifically: a well-scoped brief forces the kind of cross-functional collaboration — technical and non-technical team members working from the same constraints — that makes the day memorable for reasons beyond the code itself.

Frequently Asked Questions

What makes a good hackathon project idea? 

A good hackathon project idea is a scoped brief, not a theme. It defines what a team needs to have working in 48 hours, who should be on the team to pull it off, and — just as important — what’s explicitly out of scope. A one-line prompt like “build an AI app for X” isn’t a project idea; it’s a starting point that still needs the actual scoping work done.

How many project ideas should a hackathon offer? 

Enough for real choice without diluting focus. Most events Kreativdistrikt runs offer 15–20 scoped briefs across a handful of themes — enough that every team has more than one viable option, while keeping the briefs similar enough in scope that judges can compare submissions fairly.

Can beginners use these hackathon project ideas? 

Yes. Every idea above includes a “realistic 48-hour scope” line specifically so a first-time team can see what to cut, not just what to build — that’s usually the harder skill for beginners than the technical build itself.

Conclusion

Eighteen ideas, but the same test applies to all of them: could a team read this brief on day one and know exactly what they’re building, who they need on the team, and what “done” looks like in 48 hours? That’s the difference between an idea list and a brief.