Hackathon Guide

This hackathon rewards execution — shipping something real that runs locally with a tiny model. Here's how to think about each decision so you spend your time where it matters.

1. Start with a sharp, solvable problem

Don't try to clone ChatGPT. Pick a narrow slice of a real problem and nail it. Look for places where a small model is actually good enough and where on-device operation is a genuine advantage (privacy, offline use, speed, cost).

Bad: "a general-purpose assistant"
Good: "summarize the last 7 days of my emails while offline"
Good: "detect plant disease from a phone photo, no internet needed"
Good: "autocomplete code snippets from a custom style guide, locally"

2. Choose the smallest model that works

The 500M cap is generous for encoders and vision models — it's tight for open-ended text generation. Your job is to shrink the problem so a smaller model solves it well. A 22M parameter MiniLM that's reliable beats a 400M model that's flaky.

Look at the rule book for a model shortlist, and browse independent small models on Hugging Face: ryze-ai.

3. Make the model an implementation detail, not the whole app

Judges care about the application, not the model. Build a real UI, wire the model in as the engine, and focus the user's attention on what the app does. The model is your secret sauce — not your demo.

4. Pick a deployment path early

Commit to one runtime in week one so you stop context-switching later. Common paths for sub-500M on-device inference:

Browser: transformers.js (BERT, DistilBERT), ONNX Runtime Web, TensorFlow.js (MobileNet)
Edge/native: ONNX Runtime, llama.cpp, Core ML, TFLite
Mobile: TensorFlow Lite, PyTorch Mobile

Download/quantize your model before you start coding so it's already warm.

5. Prototype in 48 hours, then polish

Week 1: get the model responding end-to-end in your chosen runtime. Week 2: refine the approach, add guardrails (input validation, fallbacks). Week 3: polish the UI/UX, write a clean README. Week 4: record your demo, do final testing, write tests.

6. Make your demo tell a story

Your demo video should show: problem → your app → result. Show it working on a real example the judges care about. Two minutes only — no setup screens, no "umms." Start with the output, then explain.

7. Treat the README as a contract

Your README is often the judge's first interaction with your project. Start it with the exact required first line, explain what the app does in one sentence, and include clear run instructions. Include the model name, parameter count, and how it runs locally. See submission guidelines for the exact format.