Between 2020 and 2024, my team built five generations of the Orb, manufactured thousands of units, and distributed them across the Americas, Europe and APAC. We started with in-house assembly, ended up working with Jabil, and somehow made it to the cover of TIME.
Here’s what nearly killed us, what saved us, and what I’d do differently next time.
The Real Work: Explaining the Cost of ‘Yes’
In hardware, you’ll always start with a messy, overloaded product requirement sheet — that’s normal. The real challenge is not in saying no, but in helping others understand the cost of yes.
When you’re responsible for bringing a physical product to life, you’re ultimately judged on three things: how much it costs, how reliable it is, and how fast you ship. Everything else is negotiable — but only if people across the company understand how their decisions impact those metrics.
For us, early product development was shaped by deep commitments to privacy and data protection. That drove massive complexity into the compute stack, long before we had full visibility into what we’d actually need. In hindsight, I’d be less emotional about which requirements felt right to me personally, and more disciplined about communicating trade-offs — early, often, and clearly.
Design vs. Engineering — and Why You Need Both
I’ll be honest — this one was a big learning for me.
Coming from a traditional German engineering background, I was taught that functionality matters more than form. Design was seen as secondary. At german universities, we tend to joke about “fancy-looking” devices that sacrificed performance. And to some extent, that mindset makes sense — if your career ends up focused on industrial automation or power systems, nobody cares how pretty your inverter looks.
But that perspective breaks down quickly when you build something that real people touch.
The truth is: even in B2B, the companies that care about aesthetics often win. And in consumer markets, looks and brand drive decisions far more than most engineers want to admit. Functionality still matters, but it’s not enough.
The tension between design and engineering is what creates great products — but only if both teams act like partners. If one side tries to strong-arm every decision, or refuses to compromise unless presented with hours of polished documentation, the process becomes painfully slow. It’s frustrating and drains energy from the team. The best outcomes happen when both sides are curious about each other’s constraints, not just fighting for their own priorities.
Getting this right is a learning process. It won’t work perfectly from day one — and that’s okay. What matters is that both sides stay open, engaged, and willing to adjust as they go.
I struggled with this more than I expected: getting the team to align on must haves, hard deadlines and clear engineering gates is never easy. But without them, debates over materials, radii, or manufacturing methods can spiral endlessly. All this reduces flexibility — that’s true — but they protect something more important: momentum. And momentum is what gets you to launch.
Never Outsource Understanding
Certifications took far more time than expected — and trusting consultants blindly was part of the problem.
You need someone on your own team who truly understands the process — even if they’re learning it for the first time. Consultants will often give you overly optimistic timelines just to close the deal. You align your internal roadmap to that promise — and then get crushed by reality six months later.
Also: always go local. Don’t use a German firm to manage Indian BIS certifications. Hire someone with on-the-ground relationships. It’ll save you time, money, and stress.
Don’t Let Manufacturing Kill Your Momentum
If you’re early-stage and building hardware, try to keep as much manufacturing in-house as you can — at least through initial production runs. And yes – it will be scrappy and stressful BUT:
The moment you move to a contract manufacturer, everything slows down. Contracts become complex. Communication gets filtered. Data formats clash. You’ll spend weeks pushing PDFs and Excel files across disconnected systems. And onboarding your product into their process is a project in itself.
But here’s the nuance: going through that pain once is worth it. It shows you what not to do next time. It gives you the tools to ask better questions — and to recognize partners who still run on legacy processes.
For us, one key tactic was pushing back against the “standard” path to mass production. We deliberately stuck with aluminum tooling longer than recommended, which let us continue iterating without resetting timelines. It wasn’t what our suppliers advised — but it was exactly what we needed.
And of course, this isn’t black and white. You should outsource parts of the process that are well-defined and standardized — things like cable assembly or PCBA work are usually safe bets. But final assembly is for example a different story.
Especially early on, when your testing programs are still evolving, handing off final assembly can create serious friction. If your engineer can’t access the line remotely and instead has to fly in, download logs onto a local machine, and work around your vendor’s IT restrictions — that’s a recipe for wasted time and frustration.
Avoid the Commitment Trap
Success can be dangerous. The moment funding lands, internal pressure builds to “lock in” supply — to secure components and capacity before it’s too late.
That can lead to overcommitment, especially early in the product lifecycle. From experience, I’d say it’s almost always better to risk too much demand than too much stock. Suppliers are happy when you scale. They’re less happy when you cancel.
In 2021, during the supply chain crunch, we locked in large volumes of Jetson Nanos — only to later realize we needed Xavier modules instead. Unwinding that deal while preserving the relationship was tough. I’m grateful we found a path forward.
What I’d do differently in this example: never lock compute modules until firmware is at least in beta. And even then, cap commitments to 2× estimated year-one demand. It’s just not worth the downstream pain.
Small Teams, Fast Decisions, Close to action
Speed comes from trust and proximity. For most of the Orb’s development, we had an extremely lean team — just one or two people per core function.
It worked because decision-making was tight. There were no alignment meetings for circuit board design. No back-and-forth approvals. Just fast iteration and high trust.
We also kept engineers close to the real-world use of the product. Letting someone who designed the hardware watch users struggle with it creates urgency. It makes flaws impossible to ignore.
The other thing that mattered: no ego. Engineers counted inventory. They handled logistics. They filled in the gaps — not because it was their job, but because it had to get done. That attitude made all the difference.
One example: the connector between the swappable battery and the Orb. Our original solution used a spring-loaded design — exposed gold pads on the battery side, and spring-loaded pins on the Orb side. It seemed elegant and robust. In our internal tests, the connector was cycled maybe two or three times a day. No problem.
But in the real world, users weren’t just swapping batteries at a desk. They were holding the Orb while walking, tossing it in bags, carrying it across cities. That introduced constant micro-vibrations — and with a spring-loaded design, every vibration became a mini cycle. The result: the gold coating wore down within weeks. Friction increased. Eventually, the spring force was no longer enough to maintain contact. Power dropped. Resistance spiked. Devices failed in the field.
Ironically, our attempt to improve reliability — by creating a sealed battery interface — became the very thing that broke it. You only see these patterns when you’re out there, observing how people actually use your product. Not how you imagined they would.
We ended up replacing the entire connector system — moving to a more conventional plug-style interface. It solved the problem, but required changes to both the Orb and the battery pack, on a compressed timeline. Not fun — but exactly the kind of challenge small, fast teams are built for.
Decentralized Manufacturing Is Still Broken
This one’s still a huge unsolved problem.
We wanted to decentralize manufacturing from day one — to align with the open-source nature of our project, and later also due to rising geopolitical risks and logistics costs. But unless you’re operating at massive volumes, most contract manufacturers simply aren’t set up to support flexible, multi-region production.
The problem? Each country effectively becomes its own isolated project — different materials, different suppliers, different certifications. You lose consistency. You lose speed. And your operational complexity scales linearly with every new site.
There’s a massive opportunity here for a new kind of player: distributed-first, scale-second, built on a modern data stack. One that can standardize BOMs, version control, and production processes across borders — natively. We’re not there yet. But someone will build it.
One example from our own experience: my team was also responsible for the stands that held the Orbs in place during customer interactions. The original design used a specific type of wood — readily available in Europe, but nearly impossible to source in India or Latin America. Importing it wasn’t feasible either — too expensive, too slow, and wrapped in red tape.
This is the kind of problem you don’t think about until you’re deep in deployment. Localizing manufacturing isn’t just about sourcing — it can force design changes. Our solution was to replace the wood with a metal structure, wrapped in a textured film that mimicked the original look. Visually indistinguishable, easy to produce locally, and far simpler to ship globally.
These kinds of trade-offs show up everywhere — not just in tooling or electronics, but in the physical identity of the product itself. And today, most systems aren’t built to handle them well.
Final Thought
Looking back, there are a few things I’d do differently.
I’d approach product requirements with more structure and less emotion. I’d keep final assembly in-house longer, even if that meant ramping slower. I’d stay flexible with suppliers, even if it meant paying more per unit. And I’d never lock components until we were close to launch.
But more than anything, I’d double down on the team — small, trusted, close to the action, and willing to do whatever it takes.
That’s what shipped the first Orb.