XenneX/LLC
All posts

I've Been Building Software for 12 Years. Nion Lights Is Trying to Change That.

The mental model shift from software to hardware is steeper than I expected. Here's what I'm getting wrong.

#hardware#indie#nion lights#founders#manufacturing
I've Been Building Software for 12 Years. Nion Lights Is Trying to Change That.

Twelve years of software has trained me to think in a specific way: ship something, see what breaks, fix it. The feedback loop is fast. The cost of being wrong is a deploy and some embarrassed Slack messages.

Nion Lights is teaching me that this is not how physical products work.

The Thing You Can't Patch

Software has a safety net that's so fundamental I stopped noticing it: you can always fix it later. The fix costs time, sometimes money, occasionally some user trust — but it exists. You can push a patch to every user simultaneously the moment the bug is found.

You cannot push a patch to a belt that's already shipped.

If a firmware bug gets past QA and lands in a customer's hands, you're managing a support situation, not deploying a fix. If a component choice turns out to be wrong, you're looking at a revised run, not a pull request. The cost of being wrong compounds in ways that software doesn't prepare you for.

I knew this intellectually before we started. I didn't feel it until I was actually making decisions with it in the background.

What I'm Getting Wrong

A few things I've had to actively unlearn:

Speed as a default setting. In software, moving fast is almost always the right call. In hardware, moving fast before you've validated something real is how you end up with 500 units of something that doesn't quite work. The iteration loops are measured in weeks or months, not hours. This is a hard adjustment for a brain trained on continuous deployment.

The cost model. In software, the marginal cost of one more user is essentially zero. Physical products don't have that luxury. Every unit has a bill of materials. Every revision to that BOM is a conversation with a supplier. The unit economics of a physical product require a fundamentally different kind of discipline than software pricing.

What "done" means. A software feature is done when it works. A hardware product is done when it's manufacturable at scale, the packaging ships without damage, the firmware survives a full battery drain, and the return rate is acceptable. That list is longer than I expected, and each item on it requires different expertise than I have.

The Kickstarter Dynamic

We're planning a Kickstarter, which adds another layer I'm still learning. Crowdfunding a physical product means making real commitments about timelines and pricing before you've fully solved manufacturing. You're essentially selling something you're still building, to people who are trusting you to deliver on a schedule you're forecasting without all the data.

Software has equivalents — early access, pre-orders — but the physical product version has no "we'll push an update next week" escape valve. The accountability is different.

What Software Gets Right (That Hardware Can Learn From)

It's not all adjustment in one direction. There are things software culture does well that hardware can use.

Instrumentation is one. Physical products often ship with no telemetry — you find out something is wrong when people email you. Adding any visibility into how the product is actually performing in the field is an engineering advantage, and it's something software people think about naturally.

Iteration discipline is another. Hardware people sometimes wait for a perfect version before releasing. Software people know that "good enough to learn from" beats "perfect never shipped" every time. Finding the right calibration between those instincts is the actual challenge.

Why I'm Doing This Anyway

The honest answer is that the constraints are interesting.

Software is where I'm comfortable. I know how to ship software. Nion Lights is hard in ways I didn't anticipate, and that's not a reason to stop — it's actually the point. The studio exists to build things, and "things" shouldn't just mean "apps."

I don't know yet whether the Kickstarter lands, whether the product finds its real audience, whether this becomes a meaningful part of the portfolio or a great learning experience that didn't scale. What I do know is that twelve years of software made me overconfident about how much I understood about building products in general.

Nion Lights is correcting that assumption, one hard constraint at a time.