How to Design a Hackathon Kickoff Presentation

The kickoff presentation sets the tone for the entire hackathon. A well-designed kickoff answers every question participants will have before they start building, creates genuine excitement about the challenge, and leaves teams energized to start working immediately. A poorly designed kickoff leaves participants confused about the rules, uncertain about the judging criteria, and behind schedule before they've written a line of code.

The job of the kickoff presentation is to transfer enough information clearly and quickly that teams can get to work.

Before You Design Slides

Answer these questions before writing a single slide:

• What is the hackathon's core challenge or problem statement?
• Who are the participants (skill level, domain expertise, familiarity with each other)?
• What are the judging criteria and how are they weighted?
• What is the timeline, including submission deadlines and judging schedule?
• What resources, datasets, APIs, or tools are available to participants?
• Are teams pre-formed or forming at the event?

Every slide should serve one of these information needs. If a slide doesn't answer a question participants will have, cut it.

Slide Structure

Title and Welcome (1–2 slides)

Event name, date, sponsors (if any), and a brief high-energy welcome. This is the one place where enthusiasm in slide design is appropriate — bold typography, strong colors, the hackathon's visual identity.

Keep this section short. Participants didn't come to watch an introduction.

The Challenge (3–5 slides)

This is the heart of the kickoff. The challenge brief needs to be clear enough that every team understands what they're building toward, while being open enough to allow creative solutions.

The problem statement: State the problem in plain language. Avoid jargon, acronyms, or assumed context. Even if all participants are engineers, a problem statement full of domain-specific language creates ambiguity.

"Design a solution that helps [specific audience] do [specific thing] better, faster, or with less friction."

Context and constraints: What are the boundaries? What is explicitly in scope vs. out of scope? What technology constraints apply (language, platform, existing systems)? Constraints are not restrictions — they focus creative energy. A hackathon with no constraints produces mediocre everything.

The why: Why does this problem matter? What's the impact of a good solution? This motivates participants and gives them a lens for judging their own work: "Does our solution actually address the underlying problem?"

Example scenarios (optional but valuable): Show two or three specific user scenarios that a good solution would address. Not to constrain solutions, but to make the problem concrete. Abstract problems produce abstract solutions.

Judging Criteria (1 slide)

Every participant needs to know exactly how they'll be evaluated. List the criteria explicitly with their weights.

Example:

• Innovation and creativity (30%)
• Technical execution and completeness (30%)
• Potential real-world impact (25%)
• Quality of presentation (15%)

Ambiguous judging criteria produce complaints about unfair judging. Teams build what they think judges want. Tell them clearly.

If there are special prizes (best use of sponsor API, most technically complex, most user-friendly) list those separately with their criteria.

Timeline (1 slide)

A clear timeline displayed visually. Include:

• Kickoff end time (when building starts)
• Milestone check-ins if any (mid-hackathon check-in, mentor office hours)
• Submission deadline — exact time, not "end of day"
• Judging start time
• Demo and award ceremony time

One of the most common hackathon friction points is uncertainty about deadlines. Be precise. Display the timezone if you have remote participants.

Resources Available (1–2 slides)

What tools, APIs, datasets, cloud credits, or infrastructure do participants have access to? Where do they access them? What is the process for getting credentials or access?

List each resource with:

• What it is
• How to access it
• What it's useful for in the context of this hackathon

If you have sponsor APIs or datasets that are especially relevant, give them a moment of attention — but only if they're genuinely useful, not just because a sponsor paid for inclusion.

Rules and Requirements (1 slide)

Keep this concise:

• Team size requirements (minimum, maximum)
• Eligibility requirements if any
• What must be submitted (code repository, demo video, slide deck?)
• Code of conduct reference
• What happens if rules are violated

Avoid legalistic language. Write rules as clear behavioral expectations, not policy statements.

Team Formation (if applicable — 1–2 slides)

If participants are forming teams at the event:

• What is the team size requirement?
• How will team formation work (structured activity, open networking, pre-arranged)?
• Where do teams register once formed?
• What happens to solo participants who don't find a team?

Give participants a structure and a time limit. Unstructured team formation extends indefinitely and starts hackathons late.

Mentors and Support (1 slide)

Who are the mentors, subject matter experts, or organizers available during the hackathon?

• Name, expertise area, and how to reach them
• Office hours schedule if applicable
• General help channel (Slack, Discord, or physical location)

Submission Instructions (1 slide)

Even if participants won't submit for many hours, explain the submission process at kickoff. This reduces last-minute confusion:

• Where to submit (URL, form, platform)
• What the submission must include
• The exact deadline

Let's Build (1 slide)

A clear "go" signal. The final kickoff slide should be unambiguous: time is now, building starts, good luck.

Design Principles for Hackathon Kickoff Slides

Energy through design. Hackathon slides can use bolder typography, more vibrant color, and more dynamic layouts than corporate presentations. Participants are there to build things — lean into the energy.

Large text for the most important information. Deadlines, judging criteria, and the challenge statement should be readable from the back of a large room.

Keep it moving. A kickoff that drags is demoralizing. Total kickoff time should be 30–45 minutes for a multi-day hackathon, 15–20 minutes for a single-day event.

Publish the slides. After the kickoff, share the slides in the participant channel. Participants will refer back to judging criteria and timeline throughout the event. The slides are a resource, not just a presentation.