System Collapse Hackathon
72-Hour Build Sprint
72-Hour Build Sprint
The Premise
The Premise
The Premise
The question is simple: Can you create something that gets more interesting when it starts to break?
System Collapse is about building things that don’t just survive instability, they use it.
Every system breaks eventually. Some fail gracefully. Some cascade spectacularly. Between rigid order and total chaos lies the sweet spot where interesting things happen—where patterns either dissolve into noise or evolve into something unexpected.
What We're Actually Asking You to Build
What We're Actually Asking You to Build
What We're Actually Asking You to Build
The key principle: Your project should live in the zone between control and collapse. Not stable. Not random. Somewhere in between where emergent behaviour happens.
You have 72 hours and a laptop. No hardware. No VR. Just code, creativity, and whatever libraries you fancy.
You have 72 hours and a laptop. No hardware. No VR. Just code, creativity, and whatever libraries you fancy.
This could be:
- A simulation where the rules gradually drift
- An interface that degrades beautifully under stress
- A game where the physics rewrite themselves
- A data visualisation that mutates based on user interaction
- An algorithm that evolves by consuming its own output
Here’s what we want: a digital system that responds to disorder instead of fighting it.
Important: These tracks are examples and strong recommendations for implementing interesting instability mechanics. But they’re not mandatory templates—if you have a completely different idea that fits the "controlled collapse" philosophy, build that instead. We care about the concept, not the category.
That said, these five mechanics are proven ways to create emergent behaviour in 72 hours, so they’re a solid starting point.
That said, these five mechanics are proven ways to create emergent behaviour in 72 hours, so they’re a solid starting point.
Features to Implement (Pick At Least One)
Features to Implement (Pick At Least One)
Features to Implement (Pick At Least One)
Mechanics
(01)
The system consumes its own output and evolves.
Grounded Examples:
— A drawing app where your previous strokes influence the brush behaviour
— A music generator that remixes its last 10 seconds into the next phrase
— A chatbot that slowly adopts phrases from your conversation history
— A data dashboard where clicking nodes changes the algorithm that generates them
— A drawing app where your previous strokes influence the brush behaviour
— A music generator that remixes its last 10 seconds into the next phrase
— A chatbot that slowly adopts phrases from your conversation history
— A data dashboard where clicking nodes changes the algorithm that generates them
The interface represents disorder as aesthetic experience.
Grounded Examples:
— A to-do list where completed tasks decay into glitch art
— A particle system that slowly drifts from order to beautiful chaos
— A colour scheme that mutates based on time spent on the page
— Grid layouts that distort the more you interact with them
— Text that gradually scrambles or drifts across the screen
— A to-do list where completed tasks decay into glitch art
— A particle system that slowly drifts from order to beautiful chaos
— A colour scheme that mutates based on time spent on the page
— Grid layouts that distort the more you interact with them
— Text that gradually scrambles or drifts across the screen
Logic that rewrites itself based on context or stress.
Grounded Examples:
— An API wrapper that changes rate limits based on load patterns
— A Conway’s Game of Life variant where the rules mutate every N generations
— A sorting visualisation that switches algorithms when it detects patterns
— A physics sandbox where gravity direction shifts based on object density
— A form validation system that gets stricter or looser based on user behavior
— An API wrapper that changes rate limits based on load patterns
— A Conway’s Game of Life variant where the rules mutate every N generations
— A sorting visualisation that switches algorithms when it detects patterns
— A physics sandbox where gravity direction shifts based on object density
— A form validation system that gets stricter or looser based on user behavior
Simple rules producing complex, unpredictable outcomes.
Grounded Examples:
— Boids/flocking simulation where agents develop unexpected patterns
— A multiplayer canvas where individual pixels follow simple rules but create complex art
— A cellular automaton that generates music from visual patterns
— A network graph where nodes self-organise into clusters you didn’t program
— Agent-based trading sim where simple buy/sell rules create market crashes
— Boids/flocking simulation where agents develop unexpected patterns
— A multiplayer canvas where individual pixels follow simple rules but create complex art
— A cellular automaton that generates music from visual patterns
— A network graph where nodes self-organise into clusters you didn’t program
— Agent-based trading sim where simple buy/sell rules create market crashes
Intentional resets that spawn new states.
Grounded Examples:
— A code editor that "crashes" and reformats your code in a new style
— A game world that resets when population hits zero, but terrain remembers previous runs
— A data viz that explodes and reassembles with new relationships when overloaded
— A collaborative drawing board that wipes every 5 minutes but saves ghost traces
— A task manager that periodically shuffles priorities forcing reorganisation
— A code editor that "crashes" and reformats your code in a new style
— A game world that resets when population hits zero, but terrain remembers previous runs
— A data viz that explodes and reassembles with new relationships when overloaded
— A collaborative drawing board that wipes every 5 minutes but saves ghost traces
— A task manager that periodically shuffles priorities forcing reorganisation
Pro tip: Combining 2−3 of these mechanics creates something properly interesting. A drawing app with feedback loops AND entropy visuals? Now we’re talking.
Dreamware Hackathon — 72 hours to build something surreal, emotional, and alive ✦ Make people feel something real through something unreal ✦ Dreamware Hackathon — 72 hours to build something surreal, emotional, and alive ✦
What This Looks Like In Practice
What This Looks Like In Practice
What This Looks Like In Practice
Unstable
(02)
You’re free to build in any direction, but here are formats that work well in 72 hours:
The medium doesn’t matter. What matters is how your system behaves when it starts to break.
Dreamware Hackathon — 72 hours to build something surreal, emotional, and alive ✦ Make people feel something real through something unreal ✦ Dreamware Hackathon — 72 hours to build something surreal, emotional, and alive ✦
- A working demo (hosted, runnable, or documented with clear video/screenshots)
- A system with clear rules that interact with randomness or instability
- Emergent behaviour that surprises even you, the creator
- Evidence of iteration (doesn't need to be perfect, but should show thought)
After 72 hours, we expect to see:
- Live link (Vercel, Netlify, GitHub Pages, Replit, etc.) OR executable demo OR YouTube video walkthrough
- Brief README explaining the concept and how to interact with it
- 2-3 minute video or GIF showing the system in action (YouTube links encouraged)
- Source code (public GitHub repo)
You'll submit:
What Success Looks Like
What Success Looks Like
What Success Looks Like
Deliverables
(03)
Timeline
Timeline
Timeline
Follow the full journey — from the first spark of creation to the final moment when the dream becomes reality.
Roadmap
(04)
30 January
2026
2026
30 January
2026
2026
Registration closes, hackathon begins
00:00 GMT
The dream begins — creators from around the world join to build surreal, living digital experiences.
2 February
2026
2026
2 February
2026
2026
Final submissions due
(strict 72-hour cutoff)
(strict 72-hour cutoff)
00:00 GMT
Time’s up — all projects must be submitted, marking the end of 72 hours of creative intensity.
3 February 2026
— 9 February 2026
— 9 February 2026
3 February 2026
— 9 February 2026
— 9 February 2026
Judging period & community voting
The evaluation starts — judges and the community explore every project, looking for originality, emotion, and innovation.
10 February
2026
2026
10 February
2026
2026
Winners announced
Dreams come true — the best creators are revealed, celebrating imagination, technology, and emotion in perfect harmony.
The key judges shaping the vision of the System Collapse Hackathon.
Prime Jury
Prime Jury
Prime Jury
Masters
(05)
The Prime Jury Lineup
Build something that thrives on instability — 72 hours, pure chaos, controlled collapse, and unexpected beauty ✦
Note: We’re not looking for polish. We’re looking for interesting systems. A rough prototype with brilliant emergent behaviour beats a beautiful app with boring mechanics.
%
30
30
%
%
40
- Originality of approach to instability
- Aesthetic impact (visuals, sound, motion, UI)
- Memorability (will we remember this in 6 months?)
- Risk-taking and boldness of concept
- Does it work smoothly under load or chaos?
- Code quality and implementation cleanliness
- Performance optimisation for the concept
- Proper use of tools and libraries
- Clarity and elegance of the underlying rules
- How well order and chaos interact
- Conceptual depth (did you think this through?)
- Does it actually embody "controlled collapse"?
Creativity & Expression
Technical Execution
System Design
How your project will be evaluated — from system logic and technical execution to creativity and expression.
Evaluation Criteria
Evaluation Criteria
Evaluation Criteria
Judging
(06)
$ 500
Community Choice Award
For the project that sparks curiosity, conversation, and collective excitement.
$ 200
For a creative system that stands out through originality and thoughtful design.
Third Place
$ 300
Second Place
Recognizing bold experimentation and strong technical execution.
$ 1000
First Place
For the project that best captures the essence of controlled collapse — innovative, alive, and beautifully unstable.
Total: $2,000 in prizes
The total prize pool rewarding innovation that thrives on instability.
The total prize pool rewarding innovation that thrives on instability.
Awards & Recognition
Awards & Recognition
Awards & Recognition
Prize Pool
(07)
What We're NOT Looking For
What We're NOT Looking For
What We're NOT Looking For
❌ Static websites or apps with no dynamic behaviour
❌ Simple randomness without underlying systems
❌ Projects that claim to be "chaotic" but are just buggy
❌ Overly complex ideas that can’t be demoed in 72 hours
❌ Anything requiring hardware, VR, or non-standard setup
❌ Simple randomness without underlying systems
❌ Projects that claim to be "chaotic" but are just buggy
❌ Overly complex ideas that can’t be demoed in 72 hours
❌ Anything requiring hardware, VR, or non-standard setup
To be crystal clear, here’s what won’t score well:
By the end of this hackathon, we want you to have built something that makes you think: "I didn’t expect it to do that."
That moment when your creation surprises you? That’s the sweet spot. That’s what we’re looking for.
Your system should feel alive—not in a creepy AI way, but in the way a Conway’s Game of Life grid feels alive. Autonomous. Unpredictable. Interesting.
One More Thing
One More Thing
One More Thing
Organized solely for social good [and fun] and designed by Hackathon Raptors. A non-profit community — UK [C.I.C] — 15 557 917.
Build a laptop-friendly digital system that thrives on instability. 72 hours. Pick 1+ mechanics from above. Make it do something you didn’t explicitly program. Show us the demo. Win money.
Now go break something beautiful. 🔥
Now go break something beautiful. 🔥
TL;DR for skimmers:
Community Interest Company — 15557917
Organised by Hackathon Raptors
Get In Touch
Get In Touch
Get In Touch
