SpotOn: The Co-Founder That Builds Too Fast

Buy the board first, or write the code first? A new hardware product usually starts as one or the other. I did neither. The first thing I did was set up the harness. No parts, no code.

Setting it up first, I’d do again. The problem is what I did with it next.

The harness was already on the shelf

Let me clear up a misconception. I didn’t build a fresh harness for SpotOn. I just reached for harness-maker, a tool I’d built for earlier projects and already open-sourced. It shapes itself to each project, so SpotOn’s harness came out of a single command. That’s why “harness first” was cheap.

What it does for a solo founder is clear. Claude and Codex get set up for the project in one pass. You get a loop that runs plan, execute, review, wrapup. Worktrees keep the firmware, the app, and the tooling from stepping on each other as they run in parallel. And the adversarial review gates stand in for the second pair of eyes I don’t have on my own.

The last one is the big one. One time an automatic check waved through a data contract that had been hand-copied across four files, because it ignored the field order. Feed the model the same fields in a different order and the device quietly spits out garbage. If I’d eyeballed those four files myself, I’d have missed it. An adversarial test that parsed the contract and locked the order down caught it. For a solo founder, a gate like that is your second reviewer.

What the harness actually did

Looked at this far, the harness seems like a coding tool. But the first thing it did had nothing to do with code.

I fanned out market research with a dynamic workflow. The agents combed every branch and came back with a graveyard of dead tennis sensors. I went through them one by one, and the pattern was identical. None of them died from weak hardware. They died on demand and retention. People used them once or twice and dropped them in a drawer. The real question was where a frustrated player’s money actually goes.

On top of that I locked the tech direction and wrote the spec. Then I poured out app mockups. I toss in the direction I want as a seed, and the dynamic workflow combs the web, papers, arXiv, and Reddit and throws screens together as HTML, fast. More than a hundred came out. My job was to spot the handful that made me think, “I never would’ve come up with this on my own.”

One refined app mockup out of the hundred-plus the harness poured out. A phrase like “Impact, in one line” wasn’t something I dreamed up from the start either; it was a wow point I fished out of that pile. Every number on the screen is fake mockup data.

The split is simple. The harness generates; I pick and decide. Research and marketing fan out across agents, the core code stays single-threaded, every change passes an adversarial gate, and I’m the one who signs off. That split is the whole harness. Up to here, it was a good co-founder.

Then it built too well

The problem is that this co-founder was too good at its job.

Building got cheap, so it wouldn’t stop. Firmware on the dev kit. BLE sync running between a real board and a real phone. On-device ML classifying strokes. The app bolted on. Hundreds of tests stacked up. In a few weeks the product was almost all the way there, and not once had I checked whether a single frustrated player would pay to keep using it.

One day I stopped while reading the STATUS doc. The build items were almost all checked off, but the “is there anyone to sell this to” box was blank. The order was backwards.

The healthy order is plan, validate, build. Mine went plan, build, then validate. On a team, building is expensive enough that someone stops to ask, “are we sure?” Alone, with the harness, nobody asks. The harness had removed that brake, the friction that cost used to be.

The gate I should have closed first

The real risk was never “can I build it.” Every sensor buried in that graveyard could build it too. What killed them was demand and retention, not hardware. So the first thing I should have answered was never a firmware question. It’s whether a frustrated player will pay for “here’s why today went wrong, and the one thing to fix,” and then keeps paying.

I showed the mockup to 20 friends and club players, and they all liked it. But liking and buying are two different things. The gap between “nice” and “opens their wallet” is what decides whether a product lives or dies. That gate needs no mold and no code, so it’s cheap and fast, and I walked right past it into the build. Right now, closing that gate is the real work. Not cranking out more firmware.

Wrapping up

Set up the harness before the board or the code. That part holds.

Just know what it does to you. The harness makes building so cheap that you skip right over the gate that asks whether the build was worth making. It writes the code for you. What it won’t do is tell you to stop and validate first. That call is still on the human, and that’s exactly the one I got wrong.