Around 2019 and 2020, a new kind of chip started showing up in the hands of people who build things. It was small — small enough to sit on a wire outside instead of inside a data center — and it did one thing well: run AI models fast, on very little power, without phoning home to the cloud. You couldn't just order a pallet of them yet. If you wanted the hardware early, you wrote a grant for it.
That one constraint ended up shaping everything about the hackathon we ran around it at SpacePost Labs.
Why a tiny chip was a big deal
Normally, AI runs somewhere far away. Your phone records a voice memo, ships the audio to a data center, a big model transcribes it, and the text comes back. That round trip costs bandwidth, leaks your data across a network, and simply won't work where there's no good connection.
An edge AI chip — the Google Coral TPU was the one we built around — changes the geometry. It's a small, cheap processor tuned to run trained models efficiently, right where the data is. On a wire outside. In a greenhouse. On a boardwalk. Instead of hauling the world back to the model, you send the model out into the world. For a decade that had been the exclusive privilege of anyone with a server rack; suddenly it fit in the palm of your hand and cost less than a nice dinner. That's the thing worth understanding here — not the hackathon, the shift underneath it.
Grants, not prizes
Most hackathons are pitch competitions with a cash prize at the end. This one wasn't. Because the hardware was new and scarce, the way in was a grant proposal: write down what you would build, and if it was any good, you got early access to the chips.
It's a small difference that changes who walks in the door. A prize draws people chasing the prize. A hardware grant draws people who already have a problem and just need the right tool to finally attack it. And writing the proposal first made everyone honest — you had to say, in advance and in plain words, what you were actually going to make.
What people actually built
Here's my favorite part, and the reason the format worked. Because the chip is general — it just runs models efficiently, it doesn't care what for — the projects had almost nothing in common except the hardware.
One team built a personal, open-source voice coding assistant: talk out loud, and it helps you write code. Another team — mine — built a crow-language biomonitoring rig, a Raspberry Pi paired with a Coral, left out on Venice Beach to listen to the local crows for patterns in their calls. Another wired up a backyard garden, letting sensors and a little on-board model decide when to water and when to shade the plants. And more beyond those.
The point was never any single project. It was what you see when you hand the same small, powerful tool to a dozen different people and step back: not one use case, but a dozen — each one obvious only to the person who needed it.
None of this was a landmark result. It was early, scrappy work, and most of it stayed at the prototype stage. But it taught me something I keep leaning on. The fastest way to learn what a new capability is good for is to spread it wide and cheap and let a lot of people surprise you. That bet — real tools in many hands, then get out of the way — is the same one behind everything I've built since.