SpotOn: What I'm Building, and Why Alone

I play tennis. And I’ve spent 18 years as an embedded engineer, building other people’s products.

A small sensor that tells you where the ball hit the racket. I’ve wanted one for myself for a few years. The idea was never the problem. On my own, I could never carry it all the way to a product.

One person for firmware, one for the app, one for signal processing and ML. Then industrial design, marketing, certification on top of that. Even a palm-sized piece of hardware needs all of those roles at once. No single person is good at all of them. So the answer was always one of two: build a team, or drop it.

The moment it changed

This year, writing code next to an LLM, that assumption cracked. Set the vague optimism aside. This came from actually running the firmware and the app myself, alone. A big share of those roles now fits in one pair of hands.

So I’m placing a bet. Can a solo engineer carry a real hardware product all the way to launch? This series is the record of it.

It’s not a finished conclusion. The bet is still rolling. I might lose it. Either way I write it down without pretending I won. Honestly, this reads less like something for readers and more like a productization diary I keep for the version of me who digs it up later.

What SpotOn is

The product is SpotOn. A sensor that reads where on the racket face the ball landed and gives you feedback.

It didn’t start with market research. It started with my own racket. I began because I wanted one. When I make product calls, being user number one turns out to weigh more than I expected.

How it picks up that location, the method underneath, I’m not covering here. That part is the core of the product. Why I keep it closed, I explain at the end.

What I have today

Let me be straight about the state. There’s no hardware yet I’d call a product. No custom board, no enclosure, no finished form factor.

What exists is two things. One, an app that holds the experience I want. Two, a firmware prototype running on a Nordic development kit.

Building the app first was deliberate. Before pouring money and time into hardware, I wanted the thing I’m making in my hands. Once I could see where the ball hit on a screen, the product got sharper. That call, what to build first, is itself the subject of later chapters.

So this is a different animal from a “we’re starting a startup” announcement. A working app and a validated firmware path are already in hand. But the product I can actually sell is still zero. Turning that zero into one is what this series is about.

The order ahead, and what I won’t show

The rough order goes like this. The harness that turned one person into a team. Scoping a roadmap a single person can finish. Ordering hardware. A solo dev routine. Testing with no QA. Pricing. Marketing. Funding. Certification.

At each step I write down one thing: where the tools wrote the code, and where the judgment was mine. The hardware bet, the architecture taste, what I refuse to give up, when to kill a direction. That judgment is the whole point of this diary.

The disclosure rule is one line too. I write down the methods and the judgment. I keep the real numbers, meaning price, cost, funding, and the sensing internals closed. It’s a product I mean to sell. That boundary is the promise of this series.

So that a year from now I can read this back and know why I decided what I decided. Whatever the bet returns, the record stays.