Open Innovation: Solve a Real Problem You Care About — Hackcache
Pick a real problem that you or the people around you face, show that it's real, and build a working prototype that makes it easier.
- Track: Open Innovation: Solve a Real Problem You Care About
Full problem statement (paste into the editor)
Domain: Open. Any area, any users.
The Challenge
The best ideas often come from problems you have lived with: something that wastes time at your college, confuses your parents, holds back a shop in your town, or makes life harder for someone you know. Open Innovation is for those problems.
Pick a real problem faced by real people, show that it is real, and build a working prototype that makes it noticeably easier for them. It can be in any area and for anyone, as long as you can explain who it helps and why your approach is better than what they do today.
What Makes a Strong Entry
A real problem, not a technology looking for a use. "Students in our hostel only find out the mess has run out of food when they get there" is a problem. "An AI app for students" is not.
A specific person. Say exactly who you are building for: their age, where they live, the phone they use, the language they are comfortable in.
Evidence. Talk to at least three people who have the problem, or bring data, and tell us what you learned.
One journey that works end to end. A focused prototype where the main flow fully works beats ten half-built features.
Better than today. Explain what people do now and why your solution is easier, faster, cheaper or fairer.
Responsible by design. Handle personal data carefully, state limitations honestly, and design for people with different abilities, languages and devices.
Directions to Spark Ideas
These are only starting points. You are free to choose anything.
Learning and students: finding the right study material, preparing for practicals and vivas, keeping track of deadlines, getting help from seniors.
Farming and rural life: crop prices, weather, finding and applying for schemes, selling directly to buyers.
Climate and environment: waste segregation, water and energy use at home, local pollution.
Accessibility: tools for people with visual, hearing, motor or learning disabilities.
Local businesses and work: small shops going digital, finding local jobs, learning new skills.
Safety: road safety, safer commutes, community alerts.
Older people and families: medicines, avoiding scams, staying connected, everyday tasks on a phone.
Indian languages: making something useful available to people who don't read English.
Expected Outcome
Build a working prototype that shows one complete journey, from a person facing the problem to that problem being solved or made noticeably easier, backed by evidence that the problem is real.
What to Submit
Description: a short problem brief covering who has the problem, what it is, your evidence, what people do today, your solution, and what is real and what is simulated in your prototype.
Demo link: a working prototype the judges can open.
Code repository link.
Video: a demo of up to 3 minutes showing the main journey.
Slides (optional): problem, evidence, solution, impact and next steps.
Important
Build your prototype during the hackathon. If you build on something you made before, say clearly what already existed.
If your idea answers one of the other problem statements, enter it under that statement instead.
Use made-up data for anything personal. Do not collect real passwords, ID numbers, financial details or health records.
A copy of an existing app without a meaningful improvement will not score well on originality.
If your solution gives health, legal or financial information, show where it comes from and do not present it as professional advice.
Evaluation Criteria
Solutions will be evaluated on:
Problem and Evidence: Is the problem real, specific, and backed by what users said or by data?
Originality: Is the approach new, or a meaningful improvement on what already exists?
Usefulness and Impact: How much better off would the intended users be, and how many people could it reach?
Working Prototype: Does the main journey work end to end?
User Experience and Accessibility: Can the intended users, including people with different abilities, languages and devices, use it easily?
Responsible Design: Is personal data handled carefully, are limitations stated honestly, and are risks thought through?
Feasibility: Is there a credible path from this prototype to real use?
Build it with AI
- Idea · Find a problem worth solving: Help our team find a problem worth solving for a hackathon's Open Innovation track. About us: [our college and city, what we study, our skills, e.g. web development, design, data] Places and people we know well: [e.g. our hostel, our village, a parent's shop, the local bus stand] Time we have to build: [e.g. 36 hours] 1. Ask me 5 short questions about everyday frustrations we and the people around us have. Wait for my answers. 2. From my answers, list 10 specific problems. For each: who has it, how often, what they do about it today, and what it costs them (time, money or stress). 3. Score each from 1 to 5 on: how painful it is, how many people have it, whether we can talk to people who have it this week, and whether a working prototype is possible in our time. Show a table, best first. 4. Recommend the top 3, and for each, what we need to learn from real people before committing to it. Don't suggest any app ideas yet. Stay on problems.
- Idea · Check the problem is real: We think this is a real problem: [the problem, and who has it]. Write a 10-minute conversation guide for talking to someone who has it. - Ask about the last time it happened to them, what they did, and what it cost them. Ask about the past, not what they would do in future. - Don't describe our idea, and never ask "would you use an app that...": people say yes to be polite. - At most 8 questions, in English and Hindi, in plain words. - Then give me a one-page sheet to fill in after each conversation: what they said, short quotes, how they deal with it today, and how painful it is (1 to 5). After I paste what we wrote down from at least 3 conversations, tell me honestly whether the problem looks real and painful, what surprised us, and whether we should change the problem or the person we're building for.
- Idea · Write the problem brief: Write a one-page problem brief for our hackathon entry from what I give you below. Plain words, no buzzwords. - Who has the problem: one specific person first, then roughly how many people are like them - The problem, in two sentences - Evidence: what the people we spoke to told us (with short quotes), and any data - What they do today, and why that falls short. List the existing apps or services you know of that try to solve it, and mark any you're not sure exist so I can check them. - Our solution in three sentences, and the one journey our prototype shows end to end - What will be real and what will be simulated in the prototype - How we'd know it's working: one or two things we could measure - Risks (privacy, safety, or anyone it could leave out) and what we'll do about each Here's what we have: [paste your problem, what you learned from conversations, and your idea]
- Plan · Cut it down to what you can build: Our idea: [paste the problem brief, or describe the idea]. We have [number of hours] and [number] people with these skills: [skills]. 1. Pick the ONE journey that proves the idea, from the first screen to the moment the user's problem is solved. Write it as 5 to 8 steps. 2. Sort everything else into: must-have for that journey, nice to have, and leave out. Be strict. 3. Say what we should simulate (other users, data, payments, messages, outside systems) and what must truly work. 4. List the screens, the sample data we need, and anything risky to build (AI, camera, maps, payments), with a simpler fallback for each. 5. Split the work between us hour by hour, with a working version by the halfway point.
- Build 1 · The whole prototype: Build a working web app prototype for a hackathon. Build the whole thing, not a plan: every screen should work when I open it. OUR IDEA (fill this in) - App name: [name] - The problem: [two sentences] - Who it's for: [one specific person: age, where they live, their phone, their language, how comfortable they are with apps] - The one journey that must work end to end: [5 to 8 steps, from opening the app to the problem being solved] - Other features, if there's time: [list them, or write "none"] - What to simulate: [e.g. other users, payments, messages, data from outside systems] BEFORE YOU WRITE CODE List, in no more than 15 lines, the screens you'll build, the sample data, and the files. Then build all of it straight away, without waiting for me. HOW TO BUILD IT - React + Vite + Tailwind CSS, plain JavaScript (no TypeScript), React Router. No backend unless the journey truly needs one. Save data in localStorage, with a "Reset demo" button. - Keep all sample data and settings in files under src/data, and all interface text in src/i18n/en.js and src/i18n/hi.js. - Use only made-up people and data. Never collect real passwords, ID numbers, bank or card…
- Build 2 · Finish what's missing: Go through the app you built, and check it against the plan you wrote at the start and the list below. For each item, say whether it is done, partly done or missing. Then build everything that is partly done or missing, one item at a time, and keep everything that already works exactly as it is. - Every screen in your plan, and every step of the main journey working end to end - Sample data or start fresh, Reset demo, and the "How it works" screen - All data in src/data, all text in the translation files, English and Hindi - Settings: language, text size, high contrast, read aloud - Empty, loading and error states on every screen - API keys only on the server, with a demo result when there's no key - Works at 360px wide, at the largest text size, after a reload, with no console errors When you're done, go through every screen once more so spacing, buttons and wording are consistent, and list anything still not finished.
- Add-on · Add AI responsibly: Add an AI feature to our app: [what it should do, e.g. "read a photo of a crop leaf and suggest what to ask the agriculture officer"], using [your AI provider, e.g. Gemini, OpenAI or Claude]. - Never put the API key in the frontend. Add a small server endpoint (a serverless function if we deploy to Vercel or Netlify) that reads the key from an environment variable, listed in a .env.example file. - Give the AI a system prompt that says what it's for; what it must never do [e.g. diagnose, give legal or financial advice, make up facts]; to answer in the user's language, in plain words; and to say when it isn't sure. - Send only what the feature needs. Never send names, phone numbers or ID numbers, and tell the user what is sent. - Show the AI's answer as a suggestion the user can check or correct, never as a final decision. - Keep a fallback for when the server fails, and limit input size and requests per minute. - Then give me 10 test inputs, including 3 tricky ones meant to make it misbehave, with what a good answer looks like for each.
- Add-on · Reach more people: Make our app work for more people. - Add [Tamil] as a third language: every string, every piece of sample content and every message, with each language's name in its own script in the picker, and nothing left in English. - Voice: a microphone button on text fields and search, where the browser supports it, and Read aloud on every main screen. - Slow connections and older phones: make the app installable and usable offline after the first visit (with Vite, use vite-plugin-pwa), keep the first load small, and say clearly when something needs a connection. - Accessibility: go through every screen for screen readers, keyboard use, contrast, text size and tap targets. List each problem with its fix, most important first, then fix them.
- Submit · Description, link, video and slides: Get this ready to submit to the hackathon. Our submission has a title, a description, a demo link, a code repository link, a video link and a slides link. 1. Write the submission description, under 300 words: who has the problem, what it is, our evidence, what people do today, our solution, the main journey, what's real and what's simulated, and what we'd build next. 2. Write a README.md with the same content, plus how to run it. 3. Tell me step by step how to put it online on Vercel or Netlify from a GitHub repo, so the judges can open a link. Include the setting that stops a page refresh from showing a 404. 4. Write a 3-minute demo video script for judges who score problem and evidence, originality, usefulness and impact, the working prototype, user experience and accessibility, responsible design, and feasibility. Spend 30 seconds on the problem (with one real quote from someone we spoke to), 2 minutes walking through the journey, and 30 seconds on what comes next. 5. Outline 6 slides: problem, evidence, solution, demo screenshots, impact, next steps. 6. List anything that could go wrong during a live demo, and how to avoid it.
- Debug · An error message: I'm getting this error: [paste the full error message from the terminal or the browser console] It happens when: [what you did, e.g. pressed Save, ran npm run dev] The file it points to: [paste the file, or the part the error names] Explain in two lines what is causing it. Then fix only that: give me the corrected code for each file that changes, with its file name, and don't change anything unrelated. Tell me how to check it's fixed.
- Debug · Blank white screen: The app shows a blank white screen. The browser console (right-click the page, Inspect, Console) shows: [paste any red text, or write "nothing"] The terminal shows: [paste it] What I changed last: [describe it] Find the cause step by step: the console error first, then the entry files (main.jsx and App.jsx), the routes, any import that might be wrong, and saved data in localStorage that no longer matches what the code expects (and make Reset demo clear it). Fix the cause, not the symptom. Also add a simple error screen, so a crash in one screen shows a message instead of a blank page.
- Debug · A feature isn't working right: [The screen or feature] isn't working properly. What I expected: [what should happen] What happens instead: [what actually happens] Steps to make it happen: [1, 2, 3] Read the code for this feature and work out why it behaves this way before changing anything. Explain the cause in plain words, then fix it with the smallest change that works, and tell me exactly how to test it.
- Debug · The AI feature misbehaves: Our AI feature gave a bad result. What went in: [paste the input] What came out: [paste the answer] What a good answer would have been: [describe it] Work out whether the problem is the system prompt, what we send to the AI, how we read its reply, or the server call itself (check the status code and response in the browser's Network tab). Fix it, and keep the fallback working when the AI call fails. Then run the 10 test inputs again and show me input, answer, and pass or fail.
- Debug · It broke after my last change: Everything worked until my last change. Now [what's broken]. The change I made, or asked you to make: [describe it or paste it] Compare the code before and after that change and find what broke. Fix it so the new change and everything that worked before both work. If the change can't work without breaking something, tell me and suggest another way to do it.
- Debug · The AI keeps going in circles: Stop. We've tried to fix this several times and it still isn't fixed. Don't write any more code yet. The problem: [describe it] 1. List what we've already tried, and why each attempt didn't work. 2. List three possible root causes, most likely first, and what would confirm each one. 3. Tell me exactly what to check or log (one console.log, or one thing to look at) to find out which it is. Once I tell you the result, make one focused fix.
- Debug · Broken on a phone: The app looks broken on a phone: [describe it, e.g. a table runs off the side of the screen]. Fix the layout so every screen works at 360px wide and at the largest text size in Settings: - nothing scrolls sideways, and no text is cut off - wide tables become stacked cards on a phone - buttons are at least 48px tall and don't overlap - long Hindi words wrap Check every screen, not only the one I named, and tell me which ones you changed.
- Debug · Broken after deploying: The app works on my laptop but not after deploying to [Vercel / Netlify / GitHub Pages]. What happens: [e.g. a blank page, a 404 when I refresh a page, the AI feature doesn't answer] The build log or browser console shows: [paste it] Check the usual causes one by one: - the build command and output folder - the base path - a rewrite so every route serves index.html - file names whose capital letters differ from their imports (my laptop may ignore case, but the server doesn't) - environment variables that exist on my laptop but were never added to the host - if we have a server, whether the app points at the server's live address instead of localhost Tell me exactly which settings to change and where.