Dispatches from the work in progress
IoT device onboarding is the sequence that takes a device from its box to a working connection with the owner’s network and your cloud: discovery, pairing, WiFi provisioning, authentication and registration. For consumer products the most dependable pattern is BLE for the first conversation and WiFi for everything after:
A time-of-flight (ToF) sensor measures distance by emitting a pulse of infrared light and timing how long it takes to return; at the speed of light, every nanosecond of round trip is about 15 centimeters of distance. Modern single-chip ToF sensors do this with an array of single-photon avalanche diodes
An edge AI camera runs its vision models on the device that holds the lens, instead of streaming video to a server. A proximity trigger decides when to capture, a quality gate rejects frames that are too dark or too blurry in under a millisecond, and only frames that pass
Pet facial recognition identifies an individual dog, not a breed, by measuring the geometry of its face and comparing that measurement against a stored profile. In our bowl-mounted camera system, a frame passes through seven preprocessing steps, a 46-point landmark model aligns the face, an embedding model turns the aligned
A Simple Request: Stop Copying Offline Logic My task looked small: when there's no internet, show a friendly "No internet connection" screen on two surfaces of our Flutter app, the Journal and the Saved posts screen. My first version worked, but it worked the hard way.
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: micro-frontends built on browser primitives, not a framework. Every admin console eventually drifts, because it is the one place where knowledge about a module lives outside that module. Ours was a
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
