Chipwright

Why this matters

Smart-home hardware stopped being the hard part years ago. A capable wireless chip costs a few dollars, the standards have converged, and there is no shortage of good ideas for devices people would actually want in their homes.

What is left is an integration tax. Shipping one device means being fluent in embedded code, cloud services, security, certification, and update infrastructure at the same time. That is a team, not a person. So the devices that get built are the ones a company is large enough to staff, and almost everything else dies as a weekend idea that turned out to need a quarter.

The bet behind Chipwright is that this tax is accidental rather than essential. Remove it, and the group of people who can ship a real device grows from firmware teams to anyone who can build software.

What was actually in the way

Two things, and neither of them is the interesting part of making a product.

The first is duplication. A single device ends up described six separate times, by hand, in six places that all have to agree: the device itself, the service it talks to, the tests, the documentation, the smart-home compatibility layer, and the packaging. Change one and the others silently fall out of step. Most of the ongoing cost of a device project is keeping six descriptions of the same thing in agreement.

The second is the waiting. Nothing starts until hardware arrives. The design questions you most want answered on day one are exactly the ones that need a board on your desk, so the cheapest moment to discover you got it wrong is the moment you are least equipped to.

What changes

Chipwright makes the device description the only thing written by hand, and generates the other five from it, every time it changes. Then it runs the whole device as a simulator so none of that work has to wait on shipping.

• Describing a device: six places kept in sync by hand, now one place that cannot fall out of sync.
• Starting a project: after hardware arrives, now before you decide what to buy.
• Discovering a design mistake: after you have spent money, now in the first sitting.
• Testing: written twice, once for the simulation and again for the real thing, now written once and valid for both.
• Updating a device already in someone's home: a custom project, now part of the platform.

Who it is for, and what I refused to build

The person I designed for is a software developer who has never built hardware. They are not short on ability, they are short on tolerance for a project that stalls for three days on something unrelated to what they set out to make. Every decision below traces back to that person.

Naming them settled the scope faster than any feature list. I picked one device, a thermostat, and refused to let the platform handle anything else until that single device worked the entire way through. A platform that half supports many devices teaches you nothing. One device that fully works tells you exactly where the walls are.

Building in dependency order, not demo order

The roadmap came from asking what each capability was waiting on, rather than what would look best first. Most things had an answer, and the order fell out of it.

The AI assistant is the clearest case. It is the most impressive feature to show someone and it shipped last, because a tool that suggests changes to your device is only worth trusting once something can verify a suggestion before you ever see it. Shipped first, it would have been a confident guesser pointed at a product that can be broken permanently. The trust was worth more than the demo.

The decision that carries the product

A simulator was always going to be part of this. The real decision was whether it would be a convincing imitation of the device or would run the same code the device runs, and that choice decides whether the whole promise holds.

An imitation is a fraction of the work and it quietly gives the value back. Anything you build against it only proves your assumptions agree with each other, so the day hardware arrives you start over and the expensive surprise simply moved. Running the real thing means the work done before you owned hardware is still worth something afterwards. That is the difference between a demo and a head start.

Checking it against reality

A simulator nobody has tested against the physical world is a story, not a product. So the first hardware purchase was framed as an experiment with a question attached: what is the least I can spend to find out whether this is lying?

It was not lying. The device reported real readings, passed the same tests on physical hardware, joined a real smart-home network the way a customer's would, and accepted a secure update sent over the internet. That is the claim the whole platform rests on, and it is now the part I can point at rather than argue about.

Where it goes next

The interesting consequence of a single description is that a finished device becomes something you can hand to another person, install, and verify, the way you would install an app. That turns individual projects into a library other people can build on, which is the part that compounds.

The nearest work is about learning rather than features. Instrument the first ten minutes so I know where new users actually stall instead of guessing. Let real use decide how the description format grows, since it is the hardest piece to change later. And widen chip support, which is deliberately open so it does not have to be me who does it.