The prize goes to the project that best combines a real problem, a nail
-tight demo, and solid execution. The model size is a constraint, not a feature.
Don't show off the model — show off what the app does for the user.
Pick the right problem (week 1)
- Narrow is better. One well-solved edge case beats ten half-solved general cases.
- Value on-device. Choose a problem where offline / privacy / low-latency matters. That's the angle.
- Avoid open-ended generation. Under 500M params, chat is unreliable. Classification, extraction, embeddings, and vision tasks are stronger bets.
Choose your model for reliability, not size (week 1)
- Pick the smallest model that reliably solves your problem. A 22M MiniLM that's 95% accurate beats a 400M model that hallucinates.
- Quantize early and test the quantized version. If accuracy drops unacceptably, you've learned that before week 4.
- Bundle a fallback for when the model fails. A graceful "I'm not sure" is better than a wrong answer.
Ship an honest MVP (week 2)
- Get the full path — input → model → output — working end-to-end before you polish anything.
- Measure real performance on real inputs (latency, accuracy, memory). Your "it works on my laptop" demo needs to work on the judge's machine.
- If the model can't hit your accuracy bar, pivot the problem — don't fight physics for four weeks.
Polish the experience (week 3)
- Make the first 10 seconds of your demo count. The judge should see value immediately.
- Remove all friction: one-click install/run, one-command demo, no account signups for the judge.
- Write a README that a smart person could follow in under 5 minutes. Treat it as part of your submission.
- Record your demo video twice: once thinking, once for real. Cut the thinking.
Demo and README (week 4)
- Demo = storytelling. Show problem → your app → result. Cut setup screens. Start with the payoff.
- README = contract. Start with the required first line. Then one sentence answering: what is this?
- Prove on-device: include a line in your README stating the model parameter count and confirming inference is local.
Stand out on the axes that matter
The judging rubric rewards four things. Here's what wins each:
| Axis | How to win it |
|---|
| Impact & Utility | Pick a problem someone actually has. The smaller and sharper, the better. |
| Creativity & Novelty | Flip a common assumption. "Offline X" is the theme — make the constraint the feature. |
| Technical Execution | Clean code, reliable inference, documented model/license. Make it runnable first try. |
| Presentation & Demo | A two-minute video that shows, doesn't explain. Ship the demo, not the slide deck. |
Logistics checklist
- ☑ Join the Discord (required)
- ☑ Register with your email on the site
- ☑ Create a public GitHub repo after Sep 10
- ☑ README first line:
This project was submitted to the ryze.ai hackathon by [NAME].
- ☑ Submit via the site form (GitHub URL + email only)
- ☑ Ship by Oct 27
