Start Here
The fastest way to frame a useful community hackathon.
Purpose
HackKit helps organizers create practical, welcoming hackathons where builders can move from idea to demo without needing a private planning archive.
Public starter frame
- Pick one clear builder outcome.
- Keep the format small enough to explain in one minute.
- Publish only participant-facing expectations.
- Keep private operations outside this public repository.
Event Formats
Pick the simplest format that supports the builder outcome.
Good public formats
- Mini-hack: two to three hours, one focused prompt, lightweight demos.
- Sprint day: a longer build session with mentor checkpoints.
- Showcase night: short demos, peer feedback, and open discussion.
- Workshop plus build: guided workflow first, then hands-on shipping.
Selection rule
Choose the smallest format that lets participants leave with a working artifact or a clearer next step.
Timeline
A simple public timeline for planning without exposing operations.
Suggested public timeline
- Four weeks out: publish theme, format, and participation path.
- Two weeks out: share prep materials and accessibility notes.
- One week out: confirm public agenda and demo expectations.
- Event day: orient, build, checkpoint, demo, recap.
- After event: publish public recap and reusable lessons.
Keep private
Budgets, vendor coordination, staff assignments, and partner discussions should stay outside the public repository.
Organizer Checklist
A public-facing checklist for repeatable event quality.
Before the event
- State the theme and expected participant outcome.
- Publish the agenda and demo rules.
- Prepare public resources and starter links.
- Make accessibility and code of conduct expectations easy to find.
During the event
- Welcome people clearly.
- Explain the build window.
- Offer lightweight checkpoints.
- Keep demos short and supportive.
After the event
- Share public highlights.
- Thank participants and volunteers.
- Add lessons learned to HackKit.
Team Roles
Lightweight roles that help teams build without over-managing.
Suggested team roles
- Driver: keeps the prototype moving.
- Navigator: tracks the plan and next decision.
- Demo lead: prepares the final story.
- Research lead: validates user need and examples.
Guidance
Roles should help teams communicate. They should not become private assignments or attendance records in this public site.
Judging & Pitches
Clear demo expectations and public-safe judging guidance.
Pitch shape
- Problem: what changed for the user?
- Demo: what works now?
- Workflow: where Codex or AI helped.
- Next step: what would improve with more time?
Judging lens
Use transparent criteria: usefulness, clarity, working demo, learning value, and responsible execution.
Templates
Reusable public templates for organizers and participants.
Template set
- Event checklist
- Run of show
- Judging rubric
- Pitch rules
- Speaker instructions
- Post-event follow-up
Publishing rule
Templates should be generic enough for public reuse and specific enough to help an organizer act.
Lessons Learned
Public learning loop for improving each event.
Capture publicly useful lessons
- What made participants build faster?
- Which instructions reduced confusion?
- Which format choices improved demos?
- What would another organizer reuse?
Avoid
Do not publish private critiques, personal participant details, partner notes, budgets, or internal retrospectives.