Zero to demo in 5 hours: a survival guide for your first AI hack day

A developer published a five-hour survival guide for first-time AI hack day participants, recommending a 10-minute prior-art search on GitHub and Hugging Face, a one-sentence scoping template of "[Who] pastes [input] and gets [output]," and shrinking oversized agent ideas down to a single script. The guide compares three setup routes — local open-weight models via LM Studio, hosted open-weight models on Groq or OpenRouter, and AI coding assistants — and reports that on an integrated-graphics laptop, local models such as gemma-4-12b-qat and qwen3.5-9b ran slowly enough to leave for a cup of tea, with the context window rather than speed being the real limit.

It is 10:00 on Saturday morning. You open your laptop, look at a blank editor, and realize you have no idea what to build. Time is ticking down, and you feel tempted to plan a massive application that takes weeks to construct. You do not need a complex architecture or a full product to succeed today. This survival guide gives you a practical framework to scope an idea, set up tools, build a working prototype, and present it in five hours. If you are near Baku, you can join us for Hacktoberfest Hack Day Baku x Tea && Compile https://events.mlh.com/events/15529-hacktoberfest-hack-day-baku-x-tea-compile . We gather on Saturday, 17 October 2026, to build small open-source AI projects together and practice our skills. Whether you are attending an event or hacking alone at home, these steps will keep you on track. Before committing to an idea, search GitHub, Hugging Face, and the web for similar projects for 10 minutes. This 10-minute search is my most recommended habit. If you find an existing project, you have three clear options: use it as a base, copy its approach with your own twist, or build your own version. Building your own version is a valid choice and a great way to learn. It often results in a tool that is simpler or more convenient for your own needs. Searching first ensures you make this choice on purpose instead of accidentally duplicating effort without knowing it. To keep your project manageable, write your goal in one simple sentence using this fill-in template: " Who pastes input and gets output ." Here are three right-sized example ideas that fit this template perfectly: Now consider an idea that is too big: an automated AI agent that scans your entire repository, writes missing tests, creates pull requests, and updates your deployment scripts. To shrink this oversized idea into a realistic five-hour project, drop the background workers, automated triggers, database connections, and pull request creation. Reduce it to a single script or web interface: a developer pastes one function and gets two unit tests. That smaller scope gives you a clear target you can finish and demo before time runs out. When you focus on a single input and output, you cut complexity and make a working feature much more likely. If setup takes more than 30 minutes, switch to a simpler route. | Route | What it needs | Who it suits | Main catch | |---|---|---|---| | Local open-weight model LM Studio | Local memory and storage | Developers prioritizing privacy | Downloads large files before starting | | Hosted open-weight model Groq, OpenRouter | Internet connection and API key | Anyone needing quick responses | Dependent on active network connection | | AI coding assistant as pair programmer | Code editor extension | Developers seeking boilerplate code | Generates code that requires debugging | Hugging Face Spaces is a different kind of hosted route: a place to publish and share a demo of your project. I am not sponsored by, paid by, or affiliated with any tool or company named in this article. My laptop has integrated graphics, shown in Windows Task Manager as AMD Radeon 650 TM . On this machine, I ran several models locally in LM Studio: google/gemma-4-12b-qat , google/gemma-4-e4b , qwen/qwen3.5-9b , mistralai/mistral-nemo-instruct-2407 , and mistralai/mistral-7b-instruct-v0.3 . The QAT in google/gemma-4-12b-qat stands for quantization-aware training, a method that makes a model smaller so it needs less memory. These local models were slow. They were slow enough that you could leave, make another cup of tea, and come back to compile the code. Even so, they were usable for long work, and I could keep giving them tasks for a whole day. The real limit was the context window, which did not last a full day of continuous work. Slow local models suit patient tasks that run in the background, while a hosted route is usually the better choice when you need quick back-and-forth during a five-hour hack day. For hosted options, I have used Hugging Face Spaces and Groq for my own projects. OpenRouter also offers free models as an option for readers. To finish a functional project in five hours, break your time into structured blocks and commit your code about every 30 minutes. At our event, check-in, the opening and the demos use part of the day, so the build window is closer to three hours. Keep the same order and shrink each block: an end-to-end version in the first hour, and features frozen about 45 minutes before the wrap-up. Spend the first 30 minutes on preliminary planning and setup: complete your 10-minute search, write your one-sentence idea, choose your toolbox route, and set up a public repository. From 0:30 to 1:30, focus entirely on building the ugliest end-to-end version possible. This version only needs to take sample input, send it to a real model, and print the raw output on screen. Do not spend time styling buttons or polishing text. From 1:30 to 3:30, refine the core logic so it works on real input. Fix basic execution errors, clean up output parsing, and ensure your core user flow completes reliably every time. From 3:30 to 4:15, freeze all new features. Stop adding extra buttons or options, and focus on fixing the specific path you plan to show in your demonstration. From 4:15 to 5:00, finish documentation and presentation details. Write your minimum README, push your final code, run through two full rehearsals to check your timing, and record a clear backup video. Create a public repository within your first 30 minutes, right after your idea check, rather than waiting until the end of the day. Publishing early encourages you to write clean code, keep secrets safe, and maintain a clear commit history throughout the event. Pick an open-source license early by reviewing choosealicense.com https://choosealicense.com/ . An open-weight model shares its trained weights, while open-source software grants full rights to inspect and modify code. License terms vary across model providers, so always check the license before building. Your README file needs four essential elements: a clear statement of what the project does, step-by-step instructions on how to run it locally, one screenshot showing the output, and the exact model identifier you used. Keeping a tidy README makes it easy for other participants to understand your work. Never commit API keys or secret credentials to a public repository. Store secrets in a local environment file and block that file from git tracking with a .gitignore file. Create both before your first git add . This simple setup prevents secret leaks and ensures anyone can clone your project safely: The .env file: API KEY=your secret key here The .gitignore file: .env First, create an empty repository on GitHub, with no README or license file on the GitHub side, so your first push is not rejected. Then run these commands in your project folder, using the HTTPS address that GitHub shows you: git init git add . git commit -m "initial commit" git branch -M main git remote add origin https://github.com/username/repository.git git push -u origin main After that, push small updates on a regular schedule. A great project can fail if the presentation is messy. Structure your two-minute presentation using a strict timing script: To protect yourself against live technical failures, prepare one specific input that you know works perfectly. Do not test a new query live on stage. Shared venue Wi-Fi can be slow when many people use it at once. Record a screen video of your working demonstration before the final deadline. If the local Wi-Fi drops, you can play your backup recording and present your project without interruption. Avoid these five common failure modes during your build day: Use this checklist to track your progress throughout the five hours: ☐ One-sentence idea checked against a 10-minute search ☐ Public repository created with a minimum README ☐ Working end-to-end version completed by the 1:30 mark ☐ API keys and private secrets excluded from the repository ☐ One reliable demo input tested and ready ☐ Backup screen recording saved locally If you are in Baku, come join us for Hacktoberfest Hack Day Baku x Tea && Compile https://events.mlh.com/events/15529-hacktoberfest-hack-day-baku-x-tea-compile . We are meeting on Saturday, 17 October 2026, from 10:00 to 15:00, at CoffeeLea Atatürk in Baku. The event is free to attend for ages 18 and over. Seats are limited, so register on the MLH event page first. I host this event to promote open-source models and open-source ideas in Baku, and to let people try them by building something real. If you cannot attend in Baku, follow these steps wherever you are. Share what you build in the comments below so we can see your work.