A hackathon is a working day where people build software together. Ours work a little differently: everyone builds on their own information, on their own machine, and the room only ever sees postcards. This page says what these days are, who judges them, and what's left when they end. There's a technical page for people who build and break software.
One table, many laptops, one shared screen. What crosses from a laptop to the screen is small on purpose: enough to show the work. The life underneath it stays on the laptop.
Nobody at these events asks you for your data: you build on your own archive, on your own machine. Other health hackathons hand everyone the same made-up data, because asking for the real thing is unthinkable. The whole point of this project is that your information stays on your own device and useful things still get built. A room full of people doing exactly that is the best demonstration we could give.
The ancestor of these events is the working session where the people building a shared standard sit in one room and test their pieces against each other until the standard gets better. The startup pitch contest belongs to another lineage. Prizes are small and the applause is real, but the day is measured by what it leaves behind.
Rooms are small on purpose: roughly forty to sixty builders at a full event, twenty to thirty at an evening one. Small enough that everyone can find everyone. When more people want in than fit, we plan another day.
You build on your own information, on your own laptop. Nothing is uploaded anywhere: no shared drive, no cloud folder, no "submit your data" step. There isn't one, because the step was never built. The guarantee is structural.
Every event provides a made-up starter archive, as rich as a real one. Use it or use your own; no one asks, no one can tell, and nothing about the day works differently either way. That choice is invisible by design.
Signing up asks for your name, an email, your language, and what you eat. That's the whole list. A health project that collects health information at the registration desk would have misunderstood itself.
Half the room builds; the other half attacks what's being built: politely, publicly, and on targets we publish before the event, so everyone knows where the locks will be tested. Then the halves trade places at the next event.
Finding a weakness scores the same as building a feature. A lock tested in public is worth more than one nobody has tried to pick. We credit the person who finds a flaw because the discovery makes the system safer for everyone who may rely on it.
Half the judges are technical people. The other half are people who live the problem: someone managing a parent's medications, someone carrying their own long diagnosis, someone holding a family's paperwork together. Their vote counts exactly as much. Their question never changes:
Something technically brilliant that fails that question loses to something modest that passes it. Every team also answers the judges in plain language (two minutes, no jargon) before any code is discussed.
Every team ends its demo with one plain sentence: who can read what this thing produces. It shows on their last slide, and judges may challenge it. It's scored for truthfulness. How private the answer is carries no points. A true "this sends a summary through another company's computers" beats a false "this is completely private" every time:
By the end of a day there's a wall of these sentences, side by side. Reading it teaches more about how software actually treats your information than most privacy policies ever will.
These days run in English and Spanish from the invitation onward: the sign-up, the instructions, the judging, the signs on the wall. Demos happen in either language, and the judges include both. Organizers who run a community event in one language have chosen the room before anyone signed up. We run both languages, so nobody is sorted out at the door.
The design gets better. Every weakness found and every improvement proposed is written down before doors close: that last hour is a required part of the day.
Everything stays open. What the room builds together stays in the commons. Nobody walks out owning it, sponsors included.
The next date is announced from the stage.
Sponsors make these days possible, and they're thanked by name, warmly. Here's what sponsorship buys: visible thanks, a seat on the judging bench, and a day among people worth meeting. No amount of money buys the participant list, the roadmap, exclusive anything, or anyone's information. We decline money that comes with control attached. The same rule this whole project runs on holds at its events too: sponsors are anchors. Ownership stays with the community.
Written July 18, 2026: the methods exist on paper. No event has happened yet. The way of running these days exists in full (nine named methods, a run manual, judging sheets) and is being reviewed. First events are being planned for the San Francisco Bay Area; no date is announced yet. When one is real, it will appear here and on the main site's "New in this place" board, dated.
The methods will be published openly. Any community will be able to run its own days this way — with local archives, postcard screens, and accurate disclosure sentences — without asking permission. Publication makes the method reusable.
Want to be in the room? On the main site: Write to us → "I'm interested." Say you're asking about hackathons; you'll hear when a date is real.
Want to help build or attack? Apply → "build," and read the technical page first: it shows exactly how the days work and where we've asked to be attacked.
See a problem with any of this? Write to us → "feedback," or → "security" for good-faith lock-testing: welcomed, credited, and protected by a safe harbor written into our Terms, §15.