Your working demo in 48 hours — Hackcache
A plan for the whole weekend, whether or not you code: pick a problem, build it with AI tools, and hand in all four things the judges ask for.
Who this is for
Everyone entering HackCache '26: first-timers, people who have never written a line of code, and developers who want a plan that gets them over the line. Everything below is based on what hackathon judges say they reward, and on the official documentation of the tools we recommend. It is checked as of September 2026.
The short version: build one thing that works from start to finish, get it online on day one, and keep the last eight hours for the video and the deck.
What you hand in
You submit from your HackCache dashboard (the "Open your dashboard" link on the event page). The form asks for a project title, a description, the problem statement you picked, and four links:
Repo URL: a public GitHub repository with your project's code.
Demo URL: a live link anyone can open and use.
Video URL: a demo video of 5 minutes or less.
Deck URL: your pitch deck, as a link (a Google Slides link, or a PDF on Google Drive shared with "Anyone with the link").
Submitting is final. Once you press submit, nothing can be edited, so check every link in a private window first. Submissions close at midnight IST at the end of Saturday 24 October.
How you are judged
All six judges score every submission independently on five criteria, each out of 10. The average decides the ranking.
Innovation: is the idea fresh, or a genuinely new angle on an old problem?
Technical Execution: does it actually work, start to finish, without falling over?
Design & UX: can someone use it without you explaining it to them?
Impact: who does it help, and how much would it matter to them?
Presentation: do the video and the deck make the value obvious within minutes?
What experienced hackathon judges say, in their own words:
"A project that really stands out is one that was clearly considering the judging criteria." Re-read the five criteria above before every big decision.
"A strong project with a confusing demo loses to a simpler project that the judges understand."
Show something working within about 90 seconds of your video starting.
Be honest about what is simulated. Judges read transparency as confidence, and a slick homepage over a thin app costs you credibility.
The most common way teams lose with AI tools: they let the AI build the one clever part, then cannot explain how it works.
Pick your tool now, and know its limits
AI app builders turn plain English into a working web app with a public link, so you do not need to code to compete. All four below have free plans, and every one of them has a limit that can stop you in the middle of the hackathon if you do not plan for it.
Lovable ( lovable.dev ). The easiest place to start. The free plan gives 5 credits a day, but no more than 30 in a calendar month , and daily credits reset at 5:30 a.m. IST. A small change costs about half a credit, a big one up to 2, and each message in Plan mode costs 1. Publishing to a lovable.app address and connecting GitHub work on the free plan.
Bolt ( bolt.new ). The free plan gives 300,000 tokens a day and 1 million a month . Every message re-reads your project, so each prompt costs more as the app grows. Publishing goes to a bolt.host address.
v0 by Vercel ( v0.app ). The free plan gives $5 of credits a month and 7 messages a day . It publishes to Vercel and syncs with GitHub.
Replit ( replit.com ). The free Starter plan gives a daily Agent allowance, the exact size of which Replit does not publish, and one published app . On the free plan, a published link goes down after 30 days , so publish close to the event.
The October trap. Lovable's 30 credits a month reset on the 1st. Every credit you practise with in October comes out of the same 30 you need on 23 and 24 October. Practise in September if you can. If it is already October, practise on a different tool and save your Lovable allowance for the event.
How to make a small allowance last:
Plan in a regular AI chat first. Use ChatGPT, Claude or any assistant to think through your idea and write your prompts. Only paste the final, clear prompt into the builder. A thought-through prompt costs the same as a vague one and gets far more done.
One change per prompt , checked before the next one. Two half-built features cost more to repair than to build properly.
Use every teammate's allowance. Each account has its own. When you hit the day's limit, hand over: in Bolt, a teammate can import your GitHub repository into their own account; in Lovable, they can Remix (copy) the project into their own workspace from Project settings. Work one at a time, never in parallel, and connect GitHub from whichever copy you finish in.
Lovable gives 10 automatic "Try to fix" repairs every 24 hours . Use that button first when an error appears.
Limits change often. Check the pricing page of your chosen tool the week before the event.
Before the event
Tick these off before 23 October, so the 48 hours go on building rather than signing up for things.
Create a GitHub account at github.com . If you are a student, apply for the GitHub Student Developer Pack now; verification can take a few days, and it includes GitHub Copilot.
Choose one builder from the list above, and do a practice run: build a tiny app, publish it, connect it to GitHub, and open the link on your phone. Now you know the whole path works.
Pick your recording tool and record a 30-second test with your voice (see "The 5-minute demo video").
Agree on roles if you are a team (next section).
Join the WhatsApp group for announcements, and to find teammates if you need them.
Block out the time. You do not need to be at your desk for all 48 hours, but decide now when you will be.
On Thursday 22 October, registered teams receive the problem statements, along with the prompt pack, playbooks and pitch deck templates.
Split the work
For a team of three, this split works:
Builder: owns the app and the tool. Every change goes through them, so the project does not break in three places at once.
Designer and tester: writes the words on every screen, tries every button on a phone, and keeps a running list of what is broken.
Storyteller: owns the deck, the video script and the README from the first hour, and finds the facts that make the problem feel real.
For two people, merge the last two roles. Solo, follow the plan below in order and cut your scope harder than feels comfortable.
The 48-hour plan
The clock starts at midnight IST as Friday 23 October begins, and stops at midnight at the end of Saturday 24 October. Treat these times as targets.
Thursday 22 October, evening: choose the problem. Read every problem statement, pick one, write your one-sentence pitch, and sketch your 3 screens on paper.
Friday morning: first working version, online. Build the bare main journey with sample data, publish it, connect GitHub, and open the link on a phone. It will be plain. That is fine.
Friday afternoon to night: build it out. One feature at a time, testing after each. Sleep in this window; tired people break working apps.
Saturday morning: stop adding features. Fix what is broken, load realistic data, and polish the main screen.
Saturday afternoon: record the video and finish the deck. Devpost, which hosts thousands of hackathons, warns that uploading a video can take anywhere from minutes to hours.
Saturday by 8 p.m.: submit. The last four hours are for whatever goes wrong.
Choosing your problem
The projects that win are usually small ideas done completely, not big ideas done halfway. Judges consistently say the best ones start from a real annoyance, not from a cool tool looking for a use.
A good pick has one user, one painful moment, and a result you can show in 30 seconds. Write it as one sentence before you build anything. A worked example, which we will follow through the rest of this guide:
For first-time applicants who make wasted trips to government offices because they brought the wrong papers, Kagaz asks three questions and gives them the exact document checklist for their case, which they can share on WhatsApp.
If your sentence needs "and" twice, you have two projects. Pick one.
More examples of the right size, one per theme (the real problem statements will be different):
Social Impact: a tool that turns a local NGO's volunteer list into a weekly shift schedule volunteers confirm from their phones.
Banking & Finance: a first-salary planner that splits one income into rent, savings and spending, and warns when a month drifts off track.
Open Innovation: anything that passes the one-sentence test.
Building it with an AI app builder
1. Let it plan before it builds
Before spending build credits, ask the builder to plan. In Lovable this is Plan mode; in the others, just ask. Lovable's own documentation recommends ending with this line:
Ask me any questions you need in order to fully understand what I want from this feature and how I envision it.
2. Your first prompt, written out in full
Describe the person, the journey, the screens and the style, and say what not to build. This is a complete first prompt for the Kagaz example. Copy its shape for your own idea:
Build a mobile-first web app called Kagaz.
It helps people in India find out exactly which documents
they need before visiting a government office, so they
don't waste a trip.
Who it is for: Riya, 19, applying for her first passport,
and her father Suresh, 52, applying for an income
certificate. Both have made a wasted trip before.
The main journey:
1. Home: a search box and five large buttons: Passport,
Income certificate, Domicile certificate, Driving
licence, PAN card.
2. Questions: 2-3 short yes/no questions for the chosen
service (for example "First application or renewal?").
3. Checklist: the documents for their exact case, each
with a one-line tip, a tick box, and a "Share on
WhatsApp" button that sends the list as a message.
Use realistic sample data: at least 6 documents for each
service. Label the data "Sample data" in the footer.
Style: clean and friendly, large readable text, deep blue
and white, works one-handed on a phone.
Do not add sign-in, payments or a settings page.
Build the three screens with sample data first.
3. Build in steps and protect what works
Lovable's documentation suggests this pattern for every new feature:
Build a "Save my checklist" feature in steps, and wait for
me to confirm each one:
1) create the page, 2) add the UI with sample data,
3) connect the data, 4) add logic and edge cases.
Only change the Checklist page. Keep the existing styling.
Say what must not change: "only change the Checklist page", "do not touch the home screen".
When something works, bookmark or save that version . If a later change breaks it, restore the working version instead of prompting yourself into a deeper hole.
To check that saving really works, open the app in two browser tabs, save something in one, and refresh the other. If it is there, your data is real.
4. Make it look real
Judges score what they see. Replace "test test test" with believable content:
Replace all sample data with realistic entries for India:
20 volunteers with a mix of common Indian names, phone
numbers in the format 98XXXXXX01, areas in Jammu such as
Gandhi Nagar and Trikuta Nagar, and shifts across a week.
Do not change the layout.
5. When something breaks
Describe what is broken, where, what you expected and what happened, with the exact error. For example:
On the Checklist page, when I tap "Share on WhatsApp",
nothing happens. I expected WhatsApp to open with the
checklist as a message. The browser console shows:
"TypeError: Cannot read properties of undefined (reading 'map')".
Fix only this. Do not change the layout or any other page.
If two fixes fail, stop repeating the request. Lovable's documentation warns that "repeated blind fixes tend to pile up code that hides the real problem". Ask why it happened instead ("What is the root cause of this error?"), or restore the last working version.
6. Skip these
Sign-in. Judges want your idea, not a password screen. Start the demo already inside the app.
Real payments, emails and notifications , unless they are the whole point. A screen that says "Payment received" is enough, as long as you say it is simulated.
Settings pages, profile pages and dark mode. Nobody scores them.
7. Know what you built
The rules allow AI, but you must be able to explain your project. Before you record, ask:
Explain how this app works to someone non-technical, in
6 short points: what happens when a user taps "Share on
WhatsApp", where the data is saved, which parts are real
and which are simulated, and what would need to change to
handle 10,000 users a day.
Make sure every teammate can say the answer in their own words. It also writes most of your "How it's built" slide.
If you do write code
Use what you already know. A hackathon is not the time to learn a new framework. Start from a template with routing and styling done, and deploy it in the first hour.
Fake anything outside the main journey: pre-fill forms, seed sample data, mock outside services. Judges' advice: remove every point where a live demo can fail.
Commit often with clear messages, and keep API keys in environment variables, never in the code you push.
For AI help in your editor, GitHub Copilot has a free plan, and verified students get a Student plan through the Student Developer Pack.
Getting it on GitHub and online
The live link (Demo URL)
Lovable: click Publish (top right), edit the suggested lovable.app address if you like, and click Publish again.
Bolt: click Publish (top right), then Publish in the menu. Changes are not published automatically: after each change, open the menu and click Update .
v0: click Publish (top right), confirm the project name, then Publish Changes .
Replit: use Publish . Remember the free plan allows one published app.
Then open the link in a private or incognito window, and on a phone. If it asks you to sign in or shows a blank page, it is not public yet.
The repository (Repo URL)
Lovable: open Project settings → Git → GitHub . The first time, click Add account , choose your GitHub account and click Install & Authorize . Then click Connect , and Lovable creates the repository and keeps it in sync.
Bolt: click the GitHub icon (top right), then Create a repository .
v0: use its GitHub sync.
Lovable and Bolt both create the repository as private. Open it on GitHub and make it public: Settings → General → Danger Zone → Change visibility . A private repository cannot be judged.
If your tool cannot connect: download the project as a zip and unzip it. On GitHub, create a New repository , set it to Public , click uploading an existing file and drag the files in. The browser accepts up to 100 files at a time and 25 MB per file. Leave out any folder called node_modules.
Check the repository in a private window. If you see a 404, it is still private.
The README
The README is the repository's front page, and judges open it. A complete one for the Kagaz example:
# Kagaz: the right papers, first time
Live app: https://kagaz.lovable.app
Demo video: https://youtu.be/...
Problem statement: Reimagine Government
People make wasted trips to government offices because
they don't know which documents to bring. Kagaz asks
three questions and gives the exact checklist for their
case, shareable on WhatsApp.
Built with: Lovable (AI app builder), Lovable Cloud for
data. AI generated most of the code from our prompts.
Real: search, questions, checklist, WhatsApp sharing.
Simulated: document lists are sample data, not official.
Team: Riya Sharma (build), Aman Gupta (design, testing),
Sara Khan (pitch, video)
The 5-minute demo video
Judges often watch this first, and back to back with dozens of others, so say what your project does within the first few seconds.
Structure (aim for about 4 minutes):
0:00–0:20, the one-line pitch and the problem. One real person, one real moment of pain.
0:20–3:00, the demo. Walk through the main journey once, start to finish, with realistic data. Show it working instead of listing features.
3:00–3:45, how it's built. The tools, where the data lives, and what is real versus simulated.
3:45–4:15, what's next. Who would use it, and the one thing you would build next.
The last few seconds: the project name and the live link on screen.
An opening you can model yours on (use a real story from someone you actually asked):
"Last month Riya queued for two hours at the passport office, and was sent home for one missing photocopy. Kagaz makes sure that never happens. You tell it what you are applying for, answer three questions, and get the exact checklist for your case. Here it is working."
Recording, step by step:
Windows 11: press Windows + Shift + R to open Snipping Tool's recorder, turn on the microphone icon before you press Start, and select the browser window. The video saves to Videos → Screen Recordings.
Mac: press Cmd + Shift + 5 , choose Record Selected Portion , and pick your microphone under Options before recording.
Loom: the free plan records up to 5 minutes per video , which fits the limit exactly. Share the Loom link as your Video URL.
OBS Studio ( obsproject.com ) if you want more control.
Tips from judges and Devpost:
Write the script yourself and rehearse twice. Don't speed up your audio to fit the time limit; cut content instead.
Sound matters more than picture. Record in a quiet room with an earphone mic close to your mouth.
Zoom the browser to 125% so text is readable, and turn on Do Not Disturb.
Pre-fill everything. Log in, load the data and open the right page before you press record.
Subtitles help. YouTube can generate them automatically; check them before submitting.
Uploading:
YouTube: upload, choose "No, it's not made for kids" (you must answer), then set visibility to Unlisted . Unlisted videos can be watched by anyone with the link, no Google account needed.
Google Drive: upload, click Share , and under General access choose Anyone with the link .
Open the link in a private window to check it plays.
The pitch deck: 7 slides
Submit it as a link: share a Google Slides deck, or upload a PDF to Google Drive, and set both to Anyone with the link .
Title: "Kagaz: the right papers, first time". Team name and your one-line pitch.
The problem: who has it and what it costs them. One fact, or a quote from a real person you asked.
The solution: what your app does, in one sentence and one screenshot.
How it works: the main journey in 3 screenshots.
How it's built: tools, data, and what is real versus simulated.
Impact and next steps: who would use it, roughly how many of them, and what you would build next.
Team and links: names, roles, the live link and the repository.
Use one idea per slide, large text, and real screenshots instead of stock images. Start from the templates we send on 22 October if you like them.
Test it like a stranger
Before recording, hand your phone to someone who has never seen the app and watch them use it without helping. Then check:
Every page, including empty ones (what does the checklist show before anything is chosen?).
Every button, with wrong or empty inputs.
Refresh after saving, to confirm the data stays.
The whole journey on a phone, not only on a laptop.
Common ways teams lose points
The live link only works when someone is signed in, or the repository is private.
The video runs past 5 minutes, or is set to Private instead of Unlisted.
Half the weekend went on sign-in pages and a landing page.
Three teammates built three pieces that never joined up.
The demo is full of "test test test" instead of realistic data.
The team pressed submit before checking the links, and could not fix them afterwards.
The team started uploading at 11:50 p.m.
Final checklist
Open every link in a private window before you press submit:
The Demo URL opens without signing in, on a laptop and on a phone.
The Repo URL is public and has a README with the live link.
The Video URL plays, is under 5 minutes, and is Unlisted, not Private.
The Deck URL opens for someone who is not signed in.
You picked the right problem statement in the form.
Every teammate can explain how the project works.
It is at least four hours before the deadline.
Every team that submits gets a verifiable certificate, so finishing always counts.
Further reading
How to win a hackathon: advice from 5 seasoned judges (Devpost)
How to win a hackathon: notes from the judging table (JetBrains)
6 tips for making a winning hackathon demo video (Devpost)
Prompting best practices and Debugging (Lovable)
Adding a file to a repository (GitHub)
Stuck?
Ask in the WhatsApp group, or use Contact Us on the event page. Ask early: a question at hour 10 costs you minutes, and the same question at hour 46 can cost you the submission.