Dispatches from the work in progress
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
A firmware build has one job that is easy to state and hard to guarantee: the image that comes out must contain every feature you believe you put in. "The build passed" feels like proof. It isn't. A build system reports on the steps it ran
INTRO Every team has an architecture document. Very few teams have an architecture. The gap between the two is where most mobile codebases quietly rot. Someone writes "features must not import each other." Six months and four contractors later, half the modules import each other, and the document
How early user feedback became formal engineering inputs for Everbowl. Introduction A product rarely fails the same way it fails on a test bench. In the lab, we control the load, the environment, the assembly process, and how the product gets handled. In someone's home, none of that
When I first started looking at this problem, it looked like a simple UI improvement. The idea was straightforward: instead of asking users to understand everything about the product themselves, we could ask a few simple questions and use their answers to guide them toward a more relevant experience. But
The problem An owner reports her dog missing. The app raises an emergency: a row on the server, and an ongoing alert on her lock screen that survives the app being killed. Two days later the dog comes home. She taps Found. The alert disappears. She relaunches the app that
Our architecture is not a document. It is thirty-five numbered rules and eight named ones — and almost every one exists because something already went wrong quietly.
How real interaction with Everbowl changed the way we thought about clearance, wear, and durability. Designing a mechanical product around a spec is fairly straightforward. Designing one around how people, or animals, actually interact with it is a lot harder. A lot of our mechanical assumptions for Everbowl came from
The problem A member's phone lost data for about ten seconds. She was in the middle of writing a community post, tapped Post, and got told it failed. She tapped again. Failed. Again. Again. When the network came back, four identical posts appeared in the feed. The obvious
Building thermal systems that behave the same across every manufactured unit Focus: Mounting pressure control, TIM selection, screw torque, mechanical tolerance stack-up, and unit-to-unit thermal repeatability Introduction Thermal design failures rarely happen because a heatsink was completely ignored. More often, they happen because the design worked perfectly on the first
Publishing an operating system to one bench device is a task. Publishing it to a fleet of devices sitting in customers' kitchens — each polling the same update feed, each capable of being permanently broken by a bad write — is a discipline. The scary part isn't the update
An honest look at how simulation guided Everbowl's mechanical development, and where physical testing forced us to rethink the model. Introduction Simulation is one of the most useful tools in hardware development because it lets you ask questions before you've manufactured anything: where will this deform,
The bottleneck of modern vector retrieval. When working with high-dimensional embedding space-whether serving semantic search, recommendation engines, or Retrieval-Augmented Generation (RAG) pipelines - the fundamental challenge is nearest-neighbor search. Exact nearest-neighbor methods require calculating the vector distance (like Cosine or Euclidean) between a query vector and every single item in
The bottleneck in the handoff. For most of this project, converting a Figma screen into Flutter was the slowest, dumbest part of the job. The work wasn't hard, it was just relentlessly manual: open the design, click a frame, read the inspector, note that the gap is 12
Amazon OpenSearch Serverless (AOSS) presents the OpenSearch REST API. You point the standard client at it, sign your requests, and everything you already know appears to apply. That appearance is the whole problem. It is not a managed OpenSearch cluster, it is a different product that accepts a subset of
