Dispatches from the work in progress
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
When I first started working with navigation in Flutter, I thought the concept was fairly simple: A route takes you from one screen to another. You have a route, you navigate to it, and the corresponding screen opens. But while working on a real navigation flow involving deep links, route
How we approached packaging as an engineering problem rather than simply adding more material. Introduction Packaging is easy to treat as the last step in product development. The product gets designed, the manufacturing process gets defined, and then the question becomes: how do we put it in a box and
Events are how our modular monolith keeps its seams sealed. This is the transactional outbox, hash chain and four delivery lanes we built on DynamoDB, and the two ways it failed silently before we made it prove itself.
How a migration can pass reconciliation at every environment and still ship a broken system — and what we verify instead. A matching count proves the rows arrived. It does not prove the system can find them, identify them, or alert anyone when they stop working. We learned that the hard
Introduction In early bring-up, time looks like a solved problem. The SoC has an RTC. A 32.768 kHz crystal is fitted on the low-frequency oscillator. The board boots, the network connects, NTP sets the clock, and every log line carries a sensible date. Then the product is unplugged. Power
A camera module's job sounds simple: take a picture of the pet, shrink it, compress it, save it. On a microcontroller-class part, the naive version of that pipeline eats the processor. Converting a raw sensor frame into colour is millions of multiply-adds; resizing it is millions more; JPEG-compressing
A daily recap job that ran every night, never threw an error, and almost never wrote anything. The cause was a query flag that promised "newest first" and delivered something else. One of our features writes a short daily recap for each pet, built from that day'
The Hidden Cost of Peak Search Performance Hierarchical Navigable Small World (HNSW) graphs have rightfully earned their reputation as the speed demons of vector search, delivering sub-millisecond retrieval times across millions of embeddings. However, this lightning-fast performance comes with a steep trade-off: high RAM consumption. Because HNSW relies on keeping
Introduction Most embedded systems are designed assuming that the required power will always be available. The power supply is selected based on: * Maximum processor load * Peak peripheral consumption * Worst-case communication activity * Sensor requirements The calculation looks simple: Available Power > Maximum Expected Load But real products rarely operate in perfectly
