Dispatches from the work in progress
A feature only helps people if they can find it. It's easy to spend weeks building something useful, test that it works, and ship it, only to realise that new users walk straight past it. That gap between what an app can do and what users actually discover
Balancing a smaller form factor with repairability on the Tracker. Miniaturization usually gets treated as a packaging exercise: shrink the dimensions, squeeze the components into a tighter enclosure, make the product look more compact. In a real hardware product, though, reducing size changes a lot more than the outside shape.
Why our operator console has no database, no domain code, and no knowledge of any module until it asks. Every admin console eventually drifts, because it is the one place where knowledge about a module lives outside that module. Ours was a second application: its own server, its own idea
Introduction Most hardware protection systems are designed around a simple assumption: One fault happens, the system responds, and recovery begins. Real products rarely fail that cleanly. In a deployed device, multiple fault conditions can appear at nearly the same time: * A power rail collapses while an overcurrent protection circuit activates.
A pet tracker spends most of its life waiting. The dog is asleep on the sofa, the Bluetooth link to the hub is idle, and the collar's only job is to be ready the instant something happens. For a battery-powered device, "ready" and "awake"
Every product company ends up with two applications. One is the product customers see. The other is the internal console where operations, support and ML teams calibrate devices, review flagged content, inspect a customer's setup and approve batch jobs. The first gets the design reviews. The second gets
The problem: one tap, two possible realities A user submits feedback. The backend saves it successfully, but the response never reaches the app. The database contains the feedback. The user sees an error. From the client's perspective, the operation failed. From the server's perspective, it succeeded.
On DynamoDB, the outbox is one TransactWriteItems and the relay is Streams, Pipes and SQS FIFO with no code of ours. Exactly-once was harder: two error paths in our inbox quietly made it at-most-once.
When I started learning Flutter, I had a habit of trying to build everything myself. If I needed a particular feature, my first thought was usually, “How can I write this from scratch?” At that time, it felt like the best way to learn. I wanted to understand every line
Introduction Modern embedded products are becoming increasingly modular. A single hardware platform may support: * Multiple sensor configurations * Different communication modules * Optional accessories * Replaceable compute modules * Expandable peripheral boards This flexibility improves product scalability, but it introduces a hidden reliability challenge: What happens when someone tries to change the system configuration
Durability choices for the Tracker against water, mud, impacts, and chewing. A wearable designed for a dog has a very different durability problem than one designed for a person. A human takes a device off before showering, avoids dropping it, and notices when something starts to loosen. A dog does
For a camera that watches a pet, the hard question is not "can it take a picture" but "can it understand one before the picture leaves the device." Our new camera module carries a dedicated neural accelerator next to its image pipeline, and on the day
The problem In the app, an owner reporting a missing dog uploads a photo, and the app turns it into a lost-dog poster. If the photo is a cat, a bottle, or a screenshot, the poster fails at its first job. So we wanted one small check before creating it:
The problem Every feature in this app is built on a handful of quiet assumptions. There is a network. The app is running. The user is looking at the screen. The user has time. If something goes wrong, we can show them a spinner and try again. A dog goes
The Tap That Went Nowhere The button worked. The SDK log said the event was queued, then flushed. The server came back with {"status":"Ok"}. The dashboard was empty. I was adding analytics to a journal screen in a Flutter app - nothing exotic, just a
