TL;DR

• Start planning six weeks out. The schedule, not the technology, is what makes or breaks the day.
• Keep the theme narrow enough that a team can start in five minutes, and open enough for ten different answers.
• Build balanced teams of three to four on purpose. Do not let friend groups self-select.
• Publish the judging rubric before anyone writes a line of code, and weight "does it work" over polish.
• Reward effort, teamwork and a clear demo, not just the fastest coders.

What a school hackathon actually is

A school hackathon is a short, focused event where students form small teams, pick a problem, and build a working prototype against the clock. That is the whole idea: a lot of making, a fixed deadline, and a demo at the end. It can run in a single morning or spread across a few club sessions, and it works from upper primary right through high school as long as you match the scope to the age.

The recipe is easy to describe and easy to get wrong. Give students a clear theme, balanced teams, a rubric they can see, and just enough hardware to build something real. Everything below walks that recipe from six weeks out to prize-giving.

Choose a format that fits your school

Decide the shape of the event before anything else, because it drives your whole timeline. A hackathon does not have to mean a marathon. For most schools the honest choice is between three formats, and each buys you something at a cost.

Format	Good for	Upside	Watch out for
Half-day sprint (about three hours)	First-timers and younger grades	Easy to staff, fits one morning, low stakes	Teams barely finish, so keep the brief tiny
Full school day	A whole grade or a club showcase	Time for a real build and proper demos	Energy dips after lunch, so plan breaks and food
Multi-session (a few weeks of club time)	Deeper, more ambitious projects	Less rushed, room to iterate and test	Momentum leaks between sessions, and half-built projects need safe storage

If this is your first attempt, run the half-day sprint. A small event that finishes cleanly teaches more than a weekend that collapses at hour six.

The six-week countdown

Most of the work is logistics, and logistics reward a calendar. Here is a countdown that assumes a single event during term three, but the phases scale to any date.

Six to four weeks out

Lock the date, the room, and the format. Clear it with anyone who shares the space, and check it against tests and sports fixtures. Draft the theme and the rubric now, while you have time to think, not the night before. Work out roughly how many students you expect and how many adults you can put in the room. Aim for one mentor per three or four teams so nobody sits stuck for twenty minutes.

Three to two weeks out

Open sign-ups and form teams. Send families a short note about timing, food and what to bring. Count your hardware and charge everything at least once so you find the dead battery now, not on the day. Recruit judges early, because busy adults need notice. Print or share the rubric so students can read it before they arrive.

The final week

Do a dry run of the exact tech students will use: log in, open the editor, connect one board, run one program. If it fails on your machine it will fail on thirty. Prepare a simple run sheet with times, and stick it on the wall. Sort out spare kits, cables and chargers, and label a box for them.

On the day

Start with a ten-minute briefing: the theme, the rules, the rubric, and when the clock stops. Then get out of the way. Keep a visible countdown, call the halfway point, and give a firm fifteen-minute warning before code freeze. Reserve the last block for demos and judging so the day does not run over.

Set a theme with guardrails

A good theme is a fence, not a cage. Too vague ("build something cool") and half the teams spend an hour deciding what to do. Too tight ("build a line-following robot that turns left twice") and every project looks the same. Aim for a prompt with a clear subject and a lot of room, such as "help someone in our school", "make our classroom safer", or "something that reacts to its surroundings".

Give each team a one-page brief with the theme, the constraints, the deadline and the rubric on it. Add two or three example directions so nervous teams have a starting point, and make clear those are seeds, not the only options.

Build teams on purpose

Teams of three to four are the sweet spot. Pairs run out of ideas and roles; fives leave someone idle. Resist letting students pick their own groups, because friend clusters tend to sort themselves into the confident and the left-out. Mix experience levels and give every team at least one student who has coded before and one who has not.

Assign light roles so nobody hides: a builder, a coder, a note-taker and a presenter, rotating if you like. Roles matter most for the demo, when a quiet team with a great project can still lose because no one prepared to explain it.

Judge with a rubric students can see

The single biggest fairness upgrade is showing the rubric before students start. It turns judging from a mystery into a target. Keep it to a handful of criteria, score each on a small band such as zero to five, and weight the ones that reward real work.

• Does it work? A rough thing that runs beats a beautiful thing that does not. Weight this most heavily.
• Problem fit. Does the build actually address the theme, or did the team drift into a flashy side-quest?
• Creativity. Reward an unusual approach, not just more features.
• Teamwork. Could every member explain part of it? This quietly discourages one student doing everything.
• Demo. A clear ninety-second explanation with a live run.

Brief your judges to ask questions rather than hunt for bugs, and to treat every team the same way. Two judges per team, scoring independently and then comparing, smooths out the harsh marker and the soft one.

Hardware and logistics

Hardware is where good plans quietly die, so treat it as its own job. Work out what each team needs, then add a margin. A class set of ten kits for eight teams means two spares when, not if, something breaks. Charge everything the day before, label cables, and keep a repair box with spare leads, a screwdriver and tape.

Programmable boards keep a hackathon physical instead of trapping it on a screen. A consistent set, such as the sheenbot∞ board, means one set of instructions and one login flow to teach, rather than five different setups to debug at once. If you are topping up a class set or replacing worn leads, the spares and kits in the store save a scramble the week before. Whatever you use, standardise on one platform so your mentors are not translating between systems all day.

One power note for South African rooms. Plan for load shedding: know your slot, charge in advance, and keep an unplugged fallback task ready so a two-hour cut does not sink the event.

Prizes that matter

Prizes set the tone, so be careful what you reward. If the only trophy goes to the slickest build, you teach everyone else that they wasted their day. Spread recognition across categories so more teams leave feeling seen: best solution to the theme, most creative idea, best teamwork, best demo, and a judges' pick for the team that recovered from a disaster.

Keep the prizes themselves modest. Certificates, a small kit component, or the right to demo at assembly all work. What students actually remember is being called up and having their work named, not the value of the item.

Common failure modes

• Scope creep. Teams plan a cathedral and finish a doorframe. Push everyone to name a "smallest working version" in the first half hour.
• The silent freeloader. Roles and the teamwork criterion catch this, but a mentor should also spot the student who has gone quiet and pull them back in.
• Tech that fails at the start. Ninety minutes lost to logins is the classic. Your final-week dry run exists to prevent exactly this.
• Judging that feels random. A visible rubric and two judges per team fix most of the grumbling.
• No time to present. If teams build until the bell, the demos vanish and the learning with them. Protect the final block ruthlessly.

Takeaway

A school hackathon is mostly project management with a countdown clock. Start six weeks out, pick a format you can actually staff, set a theme with guardrails, build teams on purpose, and judge against a rubric everyone has seen. Get those right and the technology mostly takes care of itself. If you would rather watch the rhythm before you run your own, our holiday workshops use the same build-and-demo shape on a smaller scale, and you can read more organiser notes on the newsroom.

FAQ

How long should a first school hackathon be?

Half a day. About three focused hours is enough for younger teams to build something and demo it without burning out, and short enough that you can staff it and recover if the tech misbehaves. Stretch to a full day only once you have run one and know your bottlenecks.

Do students need to know how to code first?

Not everyone. Mixed teams work best, with at least one student who has coded before to unblock the rest. If most of your students are new, run a short warm-up session on the same tools a week ahead so the hackathon is about ideas, not learning to log in. A single trial class is a low-commitment way to gauge where a group is before you plan the event.

How many mentors do I need?

Roughly one adult per three or four teams. Fewer than that and students sit stuck; mentors are there to ask questions and nudge, not to build. Senior students and a couple of willing parents all count.

What if the power goes out mid-event?

Assume it will and plan around it. Charge boards and laptops the day before, know your load-shedding slot, and keep an unplugged task ready, such as sketching the design or planning the demo, so a cut becomes a pause rather than the end of the day.

Should there be a single winner?

Prefer several categories over one grand prize. Best theme fit, most creative, best teamwork and best demo let more teams leave with something, and they reward the behaviours you actually want. A single winner tells every other team the day was wasted.