Swarma

I’m old school fringe consumer tech: Path for social media, Songza for music, Foursquare—now Swarm—for lifelogging.

I’ve also deepened my commitment to Google hardware over the years—first Google Home, then Pixel phone, now Pixel Watch.

But there’s no Swarm app on Wear OS (!), which leaves the 63 of us in this cross-sectional segment with a choice: find and beg a Swarm product manager to prioritize it in the backlog, or vibe-code it.

Option B is a lot more realistic (and fun), and thus Swarma¹ was born.

This is my third or fourth vibe-coding project with Claude as co-pilot: I’ve done APIs, a Telegram bot, dark mode, etc. The pattern is familiar by now: describe what you want, iterate, ship. But this time the platform was completely new to me: Android Studio, Kotlin, Jetpack Compose, Wear OS.

The core app logic—hitting the Foursquare Places API, grabbing nearby venues, displaying a scrollable list, etc.—came together relatively easily. Claude handled the Kotlin syntax, the Compose UI components, the API calls. Same as it would in JavaScript or Python.

What wasn’t interchangeable was everything around the code:

• Environment. Android Studio generated a project that immediately failed to build. A Gradle plugin version didn’t exist. My corporate VPN was silently blocking downloads via SSL inspection—🤫. The Wear OS template ships with the wrong UI library. The app crashed on first launch for missing permissions that the compiler never warned me about. None of these are code problems—they’re platform faffing. A co-pilot helps you diagnose them, but you have to know the right questions to ask.
• UX decisions. The Foursquare API treats the radius parameter as a suggestion, not a hard limit—venues were populating 8km away when I’d asked for 300 meters. That’s a product decision dressed up as a technical one: do you trust the API’s ranking, or enforce your own filter? On a tiny watch screen where you can see maybe five venues, the answer is obvious—but a co-pilot doesn’t have the product context to make that call for you.
• OAuth on a browserless device. The app needs Foursquare authentication, which means OAuth, which means a browser. Wear OS doesn’t have one. My first design had a token field where I banged in 48 characters on the watch keyboard—either comical or infuriating depending on your mood. Process of elimination led me to a companion phone app: it opens a WebView, intercepts the OAuth redirect, and sends the token to the watch via Bluetooth. Minimal, one-time setup. This is the kind of problem that can’t be vibe-coded. No amount of prompting produces the right architecture—you have to understand the constraints of the device and the expectations of the user.

Vibe-coding scales to unfamiliar platforms as long as you can identify and decompose the problem. The AI handles syntax and boilerplate. So it seems the hard parts of building have shifted from the code (implementation) to everything else: environment, architecture, product judgment, platform constraints.

The whole thing—from opening Android Studio for the first time to checking into a Foursquare venue from my watch—took about an afternoon (a.k.a. naptime) to get sorted.

Swarma v1.0, now in closed testing on the Play Store.

Update: Submitted to the Play Store and recruited testers from the Wear OS and Foursquare subreddits. First useful feedback came quickly: u/sorross flagged that the phone companion app was using a WebView for Foursquare login—meaning users were authenticating inside my app rather than on Foursquare’s own site. Fair point. Took an hour to swap in a Chrome Custom Tab with a proper authorization code flow. The co-pilot had taken the path of least resistance the first time; a human caught it. Which is probably the other lesson here.

Swarm lives on the Pixel Watch 🤘

— ᴘ. ᴍ. ʙ.

First published: 2026-03-29 | tweet | cast | subscribe

tech product

← back to all posts