BUILD / HACKATHONS

Build fast.
Learn faster.

Hackathons are time-bounded build environments where people come together around a problem, idea or opportunity and turn capability into a working response through rapid collaboration and experimentation.

Academy principle: A hackathon is not simply a competition. It is a compressed learning-and-building environment where ideas become visible through action.
48:00BUILD WINDOW
TEAM / ADISCOVER · DESIGN · BUILD
TEAM / BTEST · ITERATE · DEMO
FRAMEMAKETESTSHOW
IDEAPROTOTYPEFEEDBACKDEMO
One problem. Many possibilities. Collaborate · experiment · build · learn from the result.
Time creates focus. Collaboration creates possibility. Building creates evidence.Problem · Team · Sprint · Prototype · Demonstration
01 / HACKATHON PHILOSOPHY

Compress the cycle.
Expand the learning.

A Hackathon deliberately shortens the distance between a question and a working response. The value is not only the final prototype; it is the learning created through collaboration, decisions, iteration and demonstration.

H01

Start with a meaningful problem.

The challenge should give teams something worth exploring, building or demonstrating within the available time.

H02

Make time a design element.

A fixed sprint creates focus and forces teams to decide what matters now, what can wait and what must be tested first.

H03

Build something observable.

A prototype, experiment, model, workflow, analysis, experience or other tangible response makes learning visible.

H04

Collaboration is part of the capability.

Teams learn to divide work, communicate assumptions, resolve disagreements and integrate contributions under pressure.

H05

The demo closes the loop.

Teams explain what they built, what they learned, what evidence supports it and what they would do next.

02 / THE BUILD SPRINT

A short cycle.
A real outcome.

Hackathons can be designed as one intensive session or a multi-day sprint. The architecture stays consistent: frame the opportunity, build quickly, test continuously and demonstrate clearly.

01 / FRAME

Understand the brief.

Clarify the problem, users, opportunity, constraints and definition of success.

02 / FORM

Build the team.

Bring together complementary capabilities, roles and perspectives.

03 / IDEATE

Choose a direction.

Generate possibilities, test assumptions and select a response worth building.

04 / BUILD

Make the first version.

Move quickly from concept to prototype, model, workflow or working demonstration.

05 / TEST

Learn from reality.

Gather feedback, inspect behaviour, challenge assumptions and refine the response.

06 / DEMO

Show the evidence.

Communicate the response, evidence, learning, limitations and next step.

03 / HACKATHON FORMATS

Different sprint designs.
One build mindset.

A hackathon can be adapted to the learner, organisation, capability and problem. The timebox and build requirement remain central.

01 / LEARNER

Capability Hackathon

Learners apply newly developed skills to a defined problem with mentoring and a final demonstration.

02 / CROSS-DOMAIN

Innovation Hackathon

Teams combine capabilities from different disciplines to explore a new product, service or operating idea.

03 / ORGANISATION

Business Problem Sprint

Teams work on a real organisational problem and develop evidence-backed responses within a fixed window.

04 / TECHNOLOGY

Build Hackathon

Technical teams prototype applications, data solutions, AI experiences, integrations or digital services.

05 / SOCIAL

Impact Hackathon

Teams address a community or societal challenge while balancing feasibility, inclusion and measurable value.

06 / ACADEMIC

Research-to-Prototype Sprint

Participants move from a question, insight or research finding toward an experiment, model or demonstrable application.

04 / TEAM DESIGN

Diverse capability.
Shared ownership.

The strongest hackathons are not collections of identical skills. Teams are designed so different forms of capability can meet around one problem and produce a coherent response.

TEAM CAPABILITIES

Bring different strengths together.

A team can combine technical, analytical, creative, business, domain and communication capability depending on the challenge.

  • Problem framing
  • Research and evidence
  • Design and creativity
  • Technical building
  • Business and domain understanding
  • Storytelling and demonstration
TEAM PRACTICES

Make collaboration visible.

The sprint should help teams practise the behaviours required to build together under real constraints.

  • Rapid alignment
  • Role clarity
  • Decision ownership
  • Short feedback loops
  • Integration and review
  • Respectful disagreement
05 / WHAT GETS BUILT

The prototype is only part of the evidence.

A hackathon outcome should make both the response and the learning visible. Not every sprint needs a production-ready solution; it does need a credible demonstration of what was attempted and learned.

01

Working prototype

A demonstrable product, model, workflow, experience or technical proof of concept.

02

Decision trail

The key assumptions, alternatives and choices that shaped the build.

03

Evidence

Tests, user feedback, analysis, experiments or observations that support the team's claims.

04

Demo narrative

A concise explanation of the problem, response, value, limitations and next step.

05

Learning record

What the team discovered about the problem, capability, collaboration and approach.

06 / BUILD ECOSYSTEM

From capability
to creation.

Hackathons sit alongside Labs, Challenges and Project Labs. They add a distinctive ingredient: an intense shared build window in which collaboration and speed become part of the learning experience.

01 / LEARN

Programme

Build concepts, methods and foundational capability.

02 / PRACTISE

Hands-on Lab

Develop repeatable performance with feedback.

03 / TEST

Challenge

Apply capability under constraints and ambiguity.

04 / SPRINT

Hackathon

Collaborate rapidly to build and demonstrate a response.

05 / CREATE

Project Lab

Develop a more sustained solution with deeper ownership.

07 / QUALITY & RESPONSIBILITY

Move fast.
Keep the standard.

Speed should not remove responsible practice. Hackathons should make authorship, data use, intellectual property, tool use, accessibility, safety and evaluation expectations clear.

PurposeThe sprint has a clear problem, audience and intended learning or innovation outcome.
InclusionTeam participation and contribution are designed so different capabilities can matter.
IntegritySources, data, AI assistance, code and other contributions are handled transparently.
EvidenceTeams demonstrate what they built and what supports their claims.
ASTRAAL MIND ACADEMY · BUILD

Give people a problem.
Give them a team.
Let them build.

Explore applied learning across the Academy, or work with Astraal to design a focused hackathon around a capability, business challenge or innovation opportunity.