A hackathon without clear challenges is a room full of talented people staring at blank screens. Challenges give direction, spark ideas, and help teams form around shared goals. This chapter covers how to design great tracks, cultivate projects that actually work, and set participants up for a productive experience.

Your event's theme flows directly from your objective (yes, Chapter 1 again). The theme should be:

Broad enough that multiple approaches are possible. "Build something with AI" allows for healthcare, education, creative tools, developer tooling — many teams can find their angle. "Build a specific chatbot for our customer support" is too narrow and feels like free labour.

Specific enough that participants understand the scope. "Make the world a better place" is too vague. "Build tools that help communities prepare for climate events" gives clear direction while leaving room for creativity.

Relevant to your audience. If your audience is frontend developers, don't set a challenge that requires deep machine learning expertise. Match the theme to the skills in the room.

Most events have 2–5 challenge tracks. Each track should include:

A clear problem statement. What specific problem are participants solving? Write this from the user's perspective: "Community emergency responders currently lack real-time data about which neighborhoods are most affected during flooding events."

Context and why it matters. Help participants understand the real-world significance. This is especially important for themed hackathons where participants may not be domain experts.

Success criteria. What does a good submission look like? Be specific: "A working prototype that demonstrates at least one core feature, plus a 3-minute demo video explaining the problem and solution."

Available resources. APIs, datasets, documentation, starter code, sample projects. The more you provide upfront, the faster teams can get building instead of setting up. For API challenges, ensure documentation is clear and test accounts are ready.

Technical scope. Are there required or preferred tech stacks? What deliverables are expected — a working prototype, a concept deck, a demo video, code in a repository? What about pre-existing code — can teams build on existing projects or must everything be new?

Not every idea makes a good hackathon project. The best events actively cultivate projects before the event starts. Think of this as a checklist for every project coming in:

Clearly articulated. The project has a specific question or problem plus a proposed solution. Vague ambitions ("we want to do something with blockchain") produce vague results. Help teams sharpen: "What exactly will you build in 48 hours?"

Attainable. This is the big one. Teams accomplish roughly 25% of what they think they can in the time available. That's not pessimism — it's a remarkably consistent observation across hundreds of events. Help teams scope down so they leave with a sense of finished progress, not interrupted ambition. Better to complete a small thing than abandon a big one.

Easy to onboard newcomers. The best projects have ready-to-go tasks for people with different skills and at different levels. For code projects, the build environment should spin up in under 20 minutes. Pre-written task lists or GitHub issues are ideal. If a newcomer can't contribute within the first hour, the project isn't ready.

Led by a stakeholder. Someone close to the problem — or a strong proxy — guides the project to real-world relevance. Projects without stakeholder involvement tend to "solve" problems that don't exist. Beware the ideas-person who can't also implement — that's a warning sign.

Organised. For teams of 4 or more, the leader's real job is coordination: making sure every member has something to work on and welcoming new joiners. Technical skill matters less than organisational skill in a project lead.

This is one of the highest-leverage things an organiser can do. If you know who's bringing projects, meet with them 1–2 weeks before the event.

Walk them through the framework above. Help them:

This meeting often takes just 15–30 minutes per project, but the difference in project quality is dramatic.

If your event has a specific theme (sustainability, healthcare, fintech, a sponsor's API), you'll face a common dynamic. Without intervention, the room splits into three groups:

Group #3 is bad. Participants without subject matter guidance will feel lost. To prevent this:

The hardest thing about running a great hackathon is being genuinely welcoming to newcomers and helping them get involved. Most first-timers arrive with imposter syndrome — the feeling that they don't belong because they don't have the right skills or aren't smart enough. They're wrong, but until they feel welcome they won't have a fulfilling experience.

Concrete things that work:

Hold a newcomer orientation session (30–45 minutes, before the main event) covering: what to expect, how to form a team, how to scope a project, a tour of BuilderBase and the communication tools, and Q&A.

Pair newcomers with mentors explicitly — don't leave matching to chance.

Prepare a "ready-to-join" project list so nobody is stranded during team formation. These should have small, clearly-scoped tasks that don't require deep context.

Brief project leaders that they'll need to welcome and onboard newcomers, not just lead.

Invite first-timers to self-identify at the opening (in chat or by a show of hands) and celebrate them. This alone resets the room's tone from "competitive veterans" to "inclusive community."

Open challenges let teams pursue any idea within the event's theme. Great for experienced hackers who arrive with ideas. Risky for newcomers who need structure.

Closed challenges give specific problem statements that teams must address. More direction, less freedom. Great for themed events and newcomers.

Best practice: Offer both. Have 2–4 defined challenge tracks plus an "open" track for teams with their own ideas. This gives newcomers structure while letting veterans run with their vision.

Key takeaways: