HackKit

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.

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.

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.

Purpose

Use this hackathon organizer checklist to keep a community event clear, practical, and repeatable. It is written for public planning pages, not private operations docs, so every item should be safe for participants, speakers, volunteers, and partners to read.

The checklist works best when the event has one clear builder outcome, a short demo format, and a public follow-up plan.

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.
• Confirm the public description matches what participants will actually do.
• Link public templates such as the run of show, pitch rules, and judging rubric.
• Remove private contacts, budget notes, staffing plans, and internal partner details from public copy.

During the event

• Welcome people clearly.
• Explain the build window.
• Offer lightweight checkpoints.
• Keep demos short and supportive.
• Remind teams what a useful demo looks like.
• Keep announcements focused on information every participant can use.
• Capture public-safe highlights only after participants understand what may be shared.

After the event

• Share public highlights.
• Thank participants and volunteers.
• Add lessons learned to HackKit.
• Publish approved demo links or summaries only when teams opt in.
• Turn repeated questions into public resources.
• Keep internal retrospectives and private feedback outside the public repository.

Public page review

• The event page has one clear purpose.
• The agenda is understandable without private context.
• Demo expectations are visible before the build starts.
• Resource links are public and stable.
• No private phone numbers, emails, budgets, or assignments appear in the content.
• Partner or sponsor language is public-facing and does not reveal private terms.

Related resources

• Use Run of Show Template to publish the agenda.
• Use Judging Rubric to set fair demo criteria.
• Use Pitch Rules to help teams prepare short demos.
• Use Post-event Follow-up Templates to publish a useful recap.

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.

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.

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.

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.