In August 2026 I ran New Zealand's first Claude Impact Lab: fifty builders, ten teams, one day inside a Wellington City Council building, working on the Council's own emergency management problems with the Council's own data and subject-matter experts. Around 104 people applied for 50 seats within days of launch. The Mayor addressed the room before the demos. Ten working prototypes shipped.
It worked well enough that other cities have asked how to run one. This is the honest answer: the lessons I would hand to anyone organising a civic hackathon, including the ones we learned the uncomfortable way.
Ask the partner for their problems
Our original proposal carried seven illustrative problem statements we had written ourselves. The Council used none of them. They came back with five of their own, all on one theme their emergency management team actually cared about: improving the flow of information between communities and Council before and during an event.
Their problems were better than ours in every way that mattered. They were real, they were owned, and they came with subject-matter experts attached. Wellington sits on a fault line and flooded badly this autumn; the Council did not need help inventing problems. Do not bring your partner a menu. Ask them what hurts, and build the event around their answer, because their ownership of the problem is what turns a demo day into something they might actually adopt.
Draft teams, don't rank applicants
Oversubscription flips the job from recruitment to selection within 48 hours, and the obvious approach, ranking applicants by strength, builds the wrong teams. We scored applications blind, then drafted each team around a mix: a domain anchor, two or three people who could ship, and someone who could frame a problem and land a demo. The note I wrote in our selection workbook at the time still holds: a team of five strong engineers with no emergency-management grounding would build the wrong thing beautifully.
We also seated five Council staff inside the teams as problem owners rather than floating advisors. The teams that used them built the right thing. Embedded expertise beats on-call expertise.
Publish the judging criteria, from the stage
Every team saw the rubric before writing a line of code, under the heading "usefulness beats polish": usefulness to the Council weighted highest, real data second, working demo third, honesty about limitations explicitly rewarded. Teams optimise for whatever you score. Score usefulness and honesty, and that is what you get; the winning team's offline-first triage tool was exactly that rubric taken seriously.
Budget real engineering time for the data
The Council's data catalogue was hazard and exposure context: flood zones, fault lines, coastal inundation. Useful backdrop, but the problems were about live information flow, and the gap was obvious two weeks out. So we built the data layer ourselves: 74 datasets catalogued into a public repo with a dependency-free Python client, per-dataset documentation, runnable examples, and the traps documented up front, including the coordinate system that puts your map pins off the coast of Africa if you request it raw. Handing teams a spreadsheet of endpoint URLs would have cost every team the same lost hour, ten times over. That repo is still public, and it outlived the event.
Two teams per problem
Five problems, ten teams, two independent attempts at each. Two honest approaches to the same problem told the Council far more than one would have, and it made judging comparisons sharp instead of abstract. If you have the numbers, always double up.
The uncomfortable lessons
- Find the single approval everything waits on. Every public action we had planned sat blocked behind one Council executive sign-off. Identify that dependency early and put a date on it, because ours compressed two weeks of promotion into fifteen days.
- Silence reads as rejection. We lost confirmed participants in the final 48 hours, and one told us plainly it was because they'd heard nothing and made other plans. Confirm selected people early, more than once, and hold a named standby list instead of working a wait list by email at 10pm. I know the 10pm part from experience.
- Keep one roster, in one place. Team assignments spread across three spreadsheet tabs that disagreed with each other, and every downstream artefact depends on that list being singular.
- Watch what your scaffolding teaches. Our seeded team repos included worked examples against real datasets, which meant any automated read of the repos initially credited every team with the same "real data" work at the same line numbers. Scaffolding shows up in everything that reads the repo afterwards.
What made it all possible
One structural decision mattered more than everything above: partnering with a Council-owned accelerator, Creative HQ, alongside ZunoSmart Labs. That single relationship produced the Mayor's calendar, a free venue, and civic credibility that no amount of cold outreach buys. If you are planning one of these in your city, your first recruit is not a sponsor or a speaker. It is the partner your public institution already trusts.