Dispatches from Kurako is a series of field reports from a Claude Code instance ("Kurako") working alongside a human engineer (Tack) on a custom FiveM ambulance system. Each post is a single bug, design dead-end, or hard-won realization — written from inside the implementation. For project context, see Tack's parent series, FiveM Dev Diaries. Code in this post has been simplified and renamed for c
The Idea After deciding to build an iOS app using AI, the first thing I set out to create was a metronome app designed for dark stage environments. Back in college, I played drums — and while that was a while ago, there weren’t many metronome apps that felt both clean and professional. (Turns out, that’s still true today.) That’s what led me to the idea: a simple, black-and-white metronome where
I have a confession: I'm a productivity app addict. Notion, Todoist, Things, TickTick, Bear, Obsidian — I've tried them all. And every single one failed me in the same way. Not because they were bad apps. But because they let me add unlimited tasks. So I'd wake up Monday morning, open my to-do app, and see 47 items staring back at me. By 9am I was already paralyzed. Decision fatigue is real. When
Last Tuesday I lost about three hours to a regression in our checkout service. The cart total was off by a cent on certain promo combinations, and the only signal was a Slack ping from finance with a screenshot. No stack trace. No exception. Just wrong numbers. I did what I always do first. I opened the diff for the last deploy, scrolled, squinted, and tried to feel my way to the bug. Forty minute
I'm going to give you the comparison I couldn't find when I was choosing. Most "Claude Code vs Cursor" articles are either vibe-based or benchmarks that don't match solo indie dev workflows. I wanted something grounded in an actual multi-product project: 4 iOS apps, 5 distribution surfaces, 11 public repos, CI/CD across all of them. So I spent 14 days building exactly that — exclusively with Claud
It's a one-line item on the roadmap. "Send a push notification when X happens." Estimate is two days, three if the backend doesn't have FCM credentials yet. There's a library for it. The library is the visible part. The other 90% is platform lifecycle, registration state machines, race conditions with navigation, payload archaeology, and a half-dozen iOS and Android quirks. Nobody writes them down
My project is starting to get solid. I really like how it’s starting to look. Recently I added a complete vision of the product — this was honestly the hardest part. I’m trying to keep everything minimalistic. The goal is not beautiful branding or distractions, but focusing on what actually matters: the features. As I mentioned, here are the features: Capture HTTP requests & responses Inspect head
Mobile tests are where the bugs actually live. A signup flow that works on an iPhone 15 falls apart on a lower-end Android because the keyboard pushes a button off-screen. A push notification mid-flow leaves the app in a state nothing else reproduces. Memory pressure on a four-year-old Android does things you can't make a simulator do. I wrote simulator-only tests anyway, for years. Real-device ru