How we run an AI hackathon at a school (anatomy of a build day)

The first time a head of school asks if we can run a full-school AI hackathon, there's always a pause.

"Two hundred students, all building at the same time, in our gym?" they ask. "Isn't that going to be chaos?"

It's a fair question. And the answer is no — but not because we're miracle-workers. It's because a well-designed hackathon day has a rhythm that makes focus inevitable. By 10:30 AM the energy in the room shifts, and from then on the only sound is keyboards and quiet conversations between teammates.

Here's what actually happens.

A hackathon day, hour by hour

This is what a typical full-school Pathwise AI hackathon looks like at a primary or secondary school. Day one of a one- or two-day event. Times shift a bit by school schedule, but the shape is consistent.

8:00 AM — Setup

We arrive an hour before students. Tables are arranged in pods of 4–6 (we coordinate this with your facilities team a week ahead). Each pod has a small theme card and one of our mentors floating to a cluster of pods. Wifi tested. Coffee on. Sound system checked.

9:00 AM — Opening assembly (30 minutes)

Whole school in the hall or theatre. Short, high-energy opening from one of our lead instructors. Not a lecture — a live demo. We build a tiny working app in 8 minutes in front of everyone. The room goes from polite-attention to "wait, can I do that?" in under five minutes. That's the unlock.

We then explain the theme of the day (more on that below), reveal the prize categories, and send the students to their pods.

9:30 AM — First build session (90 minutes)

Pods get a structured prompt sheet (we provide). It walks them through: pick an idea, sketch it, start building. Mentors circulate continuously, unblocking. Every 20 minutes we ring a soft bell and check in — "raise your hand if you've shown your idea to someone outside your pod. Now go do it."

By the 60-minute mark, every pod has a half-working version of something. Some look amazing. Some are still finding their footing. Both are fine — this is the part where we want raw experimentation, not polish.

11:00 AM — Quick demos (30 minutes)

Each pod stands up and gives a 60-second show-and-tell of where they are. The point isn't to compete yet. The point is exposure to other people's ideas — most pods leave this session pivoting or expanding what they're building, having seen what's possible.

11:30 AM — Break (30 minutes)

Snacks. Movement. Outside if there's a courtyard. We deliberately don't keep them inside the whole day — energy comes back stronger after a real break.

12:00 PM — Build session two (90 minutes)

The longest unbroken work block of the day. Now they know what they're building, who their teammates are, and what's possible. We see real apps starting to come together. Mentors shift from "unblocking" to "pushing for polish." If a pod is ahead, we ask harder questions. If a pod is behind, we help them re-scope to something they can ship.

1:30 PM — Lunch

Provided by school as agreed in the brief.

2:00 PM — Final build + deploy (75 minutes)

The deploy session. Every pod gets their app on the internet, with a real URL. This is the bit students remember forever. "Wait — my Auntie in Canada can actually open this on her phone right now?" Yes. She can. Send her the link.

3:15 PM — Showcase (45 minutes)

Closing assembly. We pick 6–10 standout pods to present to the whole school (we identify them during the day). Each presents in 90 seconds. We project their app live. The room responds.

Then prizes — usually 3–5 categories: most-creative, most-useful, best-collaboration, judges'-favourite, audience-favourite. Every pod that presented gets recognised in some way.

4:00 PM — End of day

The hall empties. Phones come out. Group photos. Students texting URLs to parents. Teachers wandering up to ask "how did you get them to focus like that for six hours?"

We pack down. We're out by 5.

What the school provides vs what we bring

This is the question every head of school asks, so here's the clean version:

The worries that come up (and the real answers)

Heads of school, in my experience, ask versions of the same five questions. Let me answer them straight.

"Our teachers don't know AI well. Will they be embarrassed?"

No — but only because of how we run it. Teachers aren't expected to lead anything technical. Our mentors do that. The teachers' role is what they're already great at: pastoral, watching for kids who need a check-in, helping with classroom flow. Many tell us afterward they learned more about AI by walking the room than they would have in a teacher-training day.

"What if a student gets stuck and feels left out?"

This is the worry parents ask too. Our pod structure is designed for it — every pod has at least one student who's faster on the keyboard and at least one who's quicker with ideas. Mentors are watching for the disengaged kid and re-engaging them with a job (the "designer" role, the "tester" role, the "demo presenter") that suits how they actually contribute.

It's rare for a student to fully check out on a hackathon day. The energy in the room is too high. But when it happens, we catch it within 10 minutes.

"We're nervous about what they might make"

A legitimate concern. We use AI tools with strong content guardrails and we monitor outputs throughout the day. Inappropriate content is essentially never an issue — and when something edge-case comes up (a 13-year-old asking the AI something silly), our mentors catch it and have a quick teaching moment with that pod.

We can also share our approach to safe AI tool usage with your safeguarding lead ahead of time. Many schools want this documented.

"How do we tie this to our curriculum?"

We theme the day around your school's priorities. If you're a sustainability-focused school, the theme is "build an app that helps the planet." If you're STEAM-heavy, "build a tool that solves a problem you've noticed in school." If you're tying it to a year-long inquiry, we map the theme to it. The students get a structured prompt that funnels the creativity into something on-curriculum.

"How long does it take to organise?"

A clean hackathon day takes about 6–8 weeks from signed brief to event day. That covers theme scoping, mentor briefing, tooling provisioning, photo permissions, classroom prep, and a parent-comms package. Tighter timelines are possible but tighter than 4 weeks gets uncomfortable.

Outcomes (the bit that matters)

A few things you can expect by the end of a Pathwise hackathon day:

• Every student has built something real. Not a worksheet. Not a poster. A live, working web app on the internet.
• Every student has a URL they can show parents, grandparents, friends. This is the bit that makes it feel real to families. Many parents tell us afterward this was the first time their kid had created something on the internet that worked.
• The school has stories. The press-ready recap (photos, demos, a couple of pod highlights) is something you can put in newsletters, on Open Day, and in your next round of admissions communications.
• Teachers leave more curious than they came in. This is the underrated outcome. A successful hackathon shifts how teachers see AI — from "the thing students are using to cheat" to "the thing students are using to build."

If you're thinking about it

We run hackathons at schools across APAC — single-year-group events, full-school days, multi-day intensives. Primary and secondary, with curriculum tailored per age.

The fastest way to see if it's right for your school is a free 30-minute discovery call. We'll ask about your priorities, you'll ask whatever you want, and we'll send a written proposal a few days later.

Or browse our school programs for the full menu of options — weekly afterschool, holiday camps, residencies, and full-school hackathons.

The students will surprise you. They always do.

— Mr. Brown