We Built Angry Birds in 30 Minutes: Inside the Claude x Supabase Dublin Meetup

Hen's Teeth sits in Dublin 8 behind a wall of records, neon and a hi-fi system that is far too good for a tech meetup. It is a strange room to run lightning talks in, and that is exactly why it works. Doors opened at six with food and drinks, and by half past the place had that specific hum you only get when a room is full of people who came to build rather than to be sold to.

The evening ran in partnership with Supabase, and the running order was deliberately tight: three lightning talks of twenty minutes each, a thirty-minute build challenge, then networking until the venue moved us on. The speakers were Pedro Rodrigues, AI Tooling Engineer at Supabase, Teemu Kinos, Supabase Champion and co-founder at Skene, and myself. Ant Wilson, co-founder and CTO of Supabase, made a guest appearance and stayed for the whole night, which tells you something about the crowd.

What I keep noticing about the Dublin community is how mixed it has become. There were people in the room who ship production systems for a living sitting next to people who opened a terminal for the first time that week, and the gap between what those two groups could produce in half an hour was far smaller than it would have been two years ago. That is the whole story of this era, compressed into one evening.

Before any of the build talk, here is the night itself. Arrivals, the talks, the room heads-down through the build challenge, and the part afterwards where nobody wanted to leave. Use the arrows or your keyboard, or jump around with the thumbnails.

1 / 94

The Hen's Teeth logo etched on the venue window before doors opened

My favourite thing in that set is not any of the stage shots. It is the run of photographs in the middle where forty-odd people are hunched over laptops at the same time, with plates of food going cold beside them. That is what a good meetup looks like at the halfway mark.

The build challenge is simple and slightly cruel. Thirty minutes, Claude Code, and whatever you can get to actually run by the end. No slides about what you would have built. It either works on the projector or it does not.

I picked a physics game on purpose. A dashboard can look finished and be quietly wrong; nobody in a dark room can tell whether your totals reconcile. A slingshot game is the opposite. The moment the first bird arcs across the screen and a tower fails to collapse convincingly, every single person watching knows it is broken. It is the most honest possible demo, which is precisely why it is worth doing in front of an audience.

Here is the part people always want to skip. The thirty minutes was not thirty minutes of typing hopeful sentences into a chat box. It was thirty minutes of execution against a specification I had already thought through: which physics engine, what the material properties should be, how damage should be calculated, how the files should be laid out, what was explicitly out of scope. That document did the heavy lifting. Claude Code did the typing.

Those non-goals earned their place more than anything else on the list. Every one of them removed an entire category of thing that could go wrong on a projector in front of a hundred people. No asset pipeline means no missing sprite. No network calls means the venue wi-fi cannot embarrass you. The constraint that looks like a limitation is the reason it shipped. If you want the longer version of this argument, I wrote it up in how to build a real app from one prompt.

This is the actual build from the night, running in your browser, right now. Not a video of it. Not a screenshot. Drag back from the slingshot, let go, and see whether you can three-star The Citadel.

Six levels, in order: First Blood, Tower, Glass House, Stone Fort, TNT Yard and The Citadel. Four birds, each with one ability you trigger by clicking mid-flight — Red does nothing special, Chuck dashes forward at more than double speed, the Blues split into three, and Bomb detonates. Eighteen stars available in total, and the game remembers how you did.

A note on the obvious: this is a fan-made clone written as a live coding demo, and it is not affiliated with or endorsed by Rovio Entertainment, who own Angry Birds. It exists to show what half an hour of specified, reviewed AI-assisted building looks like.

This is the whole trick, and it is the only artefact from the night worth copying. Not the source code — the source code is just what fell out the other end. One prompt, pasted once, with the clock starting the moment it was submitted.

Idea: I want to build the most realistic copy of the game Angry Birds. This should be a browser application that I can play directly in my browser using the mouse to control the game.

Research: I want you to research everything about game design, how to make it look as close to the original as possible, game physics, absolutely everything needed.

Plan: Once you have research completed, I want you to build a PRD to build this game.

Build: When the PRD is created, build it as quickly as possible.

Improve: When the first iteration is complete start it on a local server. Then figure out the methodology of improving, create a 2nd, 3rd version etc on subfolders of the app, run them separately on their own dev servers.

Conditions: This is for a workshop I am running, we have 25 minutes in total. So each of the iterations / agents etc, all have to be aware that the 25 minute counter starts when I put in this prompt, each agent etc has to be aware of the time constraints, the current time, all should stop when 25 minutes is complete. The end idea is to have the most accurate version of Angry Birds when the timeframe is over.

Method: Build this as quickly as possible, as accurate as possible with as many agents as possible using an ultracode workflow, 100's of agents allowed if necessary. For each section spend some time to figure out the most optimal methodology. Keep everything simple and conscise.

Read it again and notice what it is not. It never says how to write the game. It does not name a physics engine, a colour palette, a file layout or a single function. It describes a process, and then it describes the constraints that process has to survive. Everything else was delegated.

Why it is structured in seven labelled blocks

Each heading is doing a specific job, and dropping any one of them measurably degrades the result.

The deadline is a feature, not a caveat

The Conditions block is the part people skip when they reuse this, and it is the part that makes it work in front of an audience. Telling every agent the wall-clock deadline, and telling them the counter started when the prompt was submitted, changes their behaviour: they scope down, they stop researching, they ship the version that runs. A build with no deadline produces something more ambitious and less finished, which is exactly the wrong trade when you have a room watching a projector.

What came back was a working game with six levels, four birds, destructible wood, stone and ice, procedural artwork, synthesised sound and three-star scoring — no image files, no audio files, no build step. You have already played it. If you want to run the same prompt yourself, copy it above; the only edits worth making are the game you are cloning and the number of minutes you have. The method behind it is written up in full in how to build a real app from one prompt.

The headline is the thirty minutes, but the thirty minutes is the least interesting part. Here is what was genuinely worth carrying home.

None of this is specific to games. Swap the physics engine for a payments API and the material table for a pricing model and the method is identical. That is the reason we keep running these evenings: the format teaches a way of thinking that transfers straight into the work people do on Monday. If your team wants that in a structured form, it is what the Echofold training programmes are built around, and the consulting side covers the same ground on real systems.