Inspiration
The brief asked for a specific person in a specific moment. I picked Ravi, Fieldday's production manager, at the moment the running order breaks: a band stuck in traffic, a storm rolling in, a five-person team and up to 15,000 people waiting.
My first idea was a tool that suggests new set times. Then I realised generic scheduling tools already exist; dentists use them every day. So I set myself a test: if a feature would work just as well for a dentist, it isn't specific enough.
The problem
A dentist moves one appointment for one person. At Riverside, one late band ripples through every later set, the City's noise curfew, the headliner's fixed livestream slot, and thousands of people moving between stages. Some of those decisions aren't even Ravi's: if a storm is coming, pausing the show is Mo's call as safety lead. Ravi has minutes to replan and get everyone on the same page.
What Shufflr does
Shufflr is a phone app for Ravi with four tabs:
- Main: every text, radio call and weather warning lands here. Shufflr reads each one, files the noise, adds to-dos, and only interrupts Ravi when the running order is at risk. Then it gives him two or three clear choices, each one line until he taps it.
- Schedule: all three days. Previewing a plan shows exactly which sets move.
- Team: one plan becomes a different message for each person: a text for the band's manager, a radio call for the stage crew, a notice for the crowd screens. Ravi sends them, and Shufflr tracks who has confirmed.
- Binder: contracts, riders, the City permit and Mo's standing rules, each clause with an id. Ravi can add documents by file or photo.
How AI is used
The AI classifies incoming messages, plans new running orders, explains what it ruled out, and writes each message for its recipient. What makes it more than a chatbot:
- It plans inside specialised data. Every option cites the binder clauses it relies on, like a band's contract minimum or the choir's earliest start.
- A checker verifies every plan against the curfew, changeovers, contracts and Mo's calls before Ravi sees it. AI mistakes get flagged, not hidden.
- It's honest when nothing fits. If a storm pause means someone has to be cut, Shufflr says so and shows the least-bad trade-offs.
Who decides
Everything outside Ravi's control is a constraint: artists' limits, the City's curfew and Mo's safety calls.
| Decision | Who | Shufflr |
|---|---|---|
| Pause or stop the show | Mo | Treats it as a fixed rule |
| Is a big crowd move safe? | Mo | Asks, then waits |
| The new running order | Ravi | Suggests, cites, checks |
| Who gets told, and what | Ravi | Drafts, sends nothing |
Only Mo can make safety calls, and that's enforced in code, not just in the prompt: a weather warning from anyone else is noted, never acted on.
Ideas I considered
- The Ground Control track. I started there, then moved to Backstage because managing artists and performances was the sharper problem.
- A paste-in rescheduling tool. Too generic; it failed the dentist test.
- Fairness across three days, and confirmation texts. Not unique: dentists schedule months ahead and already send yes/no texts.
- Judging who's texting. Unnecessary. Ravi's work phone only hears from contacts swapped during advancing.
What survived was weather and crowds. Melbourne's December weather, including thunderstorm asthma season, can stop a whole festival at once, and one change can move thousands of people. That led to the core insight: Ravi doesn't work alone, so Shufflr is a coordination tool, not a scheduling tool.
How I built it
A single web page in HTML, CSS and JavaScript, built with Claude. Inside claude.ai it runs on Claude; anywhere else it can use a Gemini key. The full demo is tested end to end with a mock AI.
The page is a guided sandbox: Ravi's phone on the left, and a story panel on the right that walks through the evening one step at a time. Everything inside the phone is what Ravi sees. The panel is the outside world, where you can text Ravi as anyone he knows.
What's simulated: the incoming messages are scripted (you can add your own), team replies are simulated, and document reading is shown with a sample contract rather than real file parsing.
Challenges
My first prototype was a dashboard that made sense to me and nobody else. I rebuilt it as a phone plus a story panel, then cut the words back hard: options went from dense cards to three one-line choices you can expand.
I also had to work out what Mo actually cares about. At first every change to a big act needed his approval, which made him a bottleneck. Now it's only big moves: a 6,000+ act shifted more than 30 minutes, moved to another stage, or cancelled.
What I learned
The hard part of an AI product isn't the AI call. It's deciding what the AI should and shouldn't decide, and making that visible to the person using it.
Built With
- altman
- darioamodei
- mythos5.1
- opus6.7
- tokenmaxxed
Log in or sign up for Devpost to join the conversation.