Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / Why Hardware Startups Fail At Component Obsolescence
Transcript
- Lucas: We talk a lot about the valley of death in hardware, but I want to zoom in on a specific trap that catches founders right as they’re trying to scale. It’s not just about raising money or finding a factory. It’s about what happens when the specific chip you designed your entire product around gets discontinued by the manufacturer. Luna: Right, because usually that doesn’t happen until you’ve already sold ten thousand units. By then, you can’t just swap it out without re-certifying everything. Lucas: Exactly. And the scary part is that manufacturers don’t always warn you clearly. They’ll send an end of life notification with a twelve-month notice period, which sounds generous until you realize you need eighteen months to redesign, retool, and recertify the replacement part. That gap is where companies die. Luna: So it’s a timing problem disguised as a technical one. You have the wrong lead time for the transition. Lucas: Precisely. Let’s look at a concrete example from last quarter. There was a mid-sized robotics company that built a specialized autonomous mobile robot for warehouse logistics. Their entire navigation stack relied on a specific lidar module from a smaller European supplier. In August, that supplier announced they were exiting the consumer-adjacent hardware market to focus solely on industrial automotive sensors. Luna: And they didn’t give a long enough runway? Or did the robotics firm just assume it would be fine? Lucas: They assumed it would be fine because they had a letter of intent for a second source, but that second source was actually a generic alternative that required a complete hardware revision. The original supplier gave them six months notice. Six months is nothing in hardware engineering when you’re dealing with firmware drivers and mechanical housing constraints. Luna: That’s terrifying. So they couldn’t meet their delivery obligations because the core component vanished? Lucas: They couldn’t. And since their customers had signed long-term service contracts based on that specific hardware capability, the company faced massive penalty clauses. It wasn’t just a product delay; it was a liquidity crisis triggered by a silicon shortage. Luna: It makes me think about how we treat software updates versus physical hardware. In software, you patch it. In hardware, you scrap the tooling. Lucas: That’s the fundamental disconnect. Software founders understand versioning and backward compatibility instinctively. Hardware founders often treat the bill of materials as a static list rather than a living document that degrades over time. Every component has a lifecycle curve. You have introduction, maturity, decline, and discontinuation. Luna: Most founders only look at the introduction phase. They pick the coolest, newest part available. Lucas: Usually the newest part. And the newest part is the most volatile. When you pick a component that just launched last year, you’re betting that the manufacturer will keep it alive through your production run. But if that manufacturer merges with another player, or shifts strategy, your part becomes legacy overnight. Luna: So the advice should be to pick parts that are already established? Like mature technology? Lucas: Not just established, but actively supported. There’s a concept called 'last-time buy' rights. If you negotiate hard enough, you can pay a premium to lock in inventory for three years. But that burns cash early. A better strategy is designing for interchangeability from day one. Luna: Interchangeability in the design phase? How do you even plan for that without knowing exactly what you’re going to sell? Lucas: You design the interface, not the component. Think about usb c. It doesn’t matter if the chip inside is from Intel, AMD, or Qualcomm. The physical connector and the communication protocol are standardized. If you design your power delivery system around a standard protocol instead of a proprietary IC, you insulate yourself from single-source failure. Luna: But proprietary components often offer better performance or lower cost. Is the trade-off worth it? Lucas: Only if you have volume. If you’re a startup shipping five hundred units, you might get a custom price on a proprietary sensor that saves you fifty dollars per unit. But if that sensor gets discontinued, you lose two hundred thousand dollars in re-engineering costs. The math changes depending on your scale. Luna: So for early-stage hardware, maybe standardization isn’t the priority. Maybe just avoiding single-source dependency is enough. Lucas: Single-source dependency is the baseline. You must have at least two qualified suppliers for every critical component. Not two suppliers who happen to sell the same part, but two suppliers who can provide functionally equivalent parts that fit your existing board footprint. Luna: Footprint matching is huge. If you have to change the PCB layout because the new chip has different pin spacing, you’re looking at weeks of respins. Lucas: Weeks or months. And each spin costs thousands in fabrication and assembly. Plus, you have to update your test fixtures. Everything connected to that component becomes a liability if it’s not modular. Luna: It sounds like we need a new KPI for hardware teams. Not just yield rate or time to market, but 'obsolescence risk score'. Lucas: I love that. An obsolescence risk score would track how many components in your BOM are approaching end of life notifications, whether you have alternate sources, and how difficult the replacement process would be. It turns a vague fear into a manageable metric. Luna: Can you even automate that tracking? Or does it require constant communication with sales reps at component houses? Lucas: There are platforms now that aggregate distributor data and manufacturer announcements. You can plug your BOM into these tools and get alerts when a part is flagged for discontinuation. But the human element still matters. You need engineers who actually read those emails instead of auto-deleting them. Luna: Auto-delete is definitely the default setting for most busy engineering teams. Especially during crunch time before a launch. Lucas: Which is exactly when those emails arrive. The irony is that the warning comes when you’re busiest, but you’re also least able to respond. That’s why this needs to be baked into your quarterly planning, not treated as an ad-hoc task. Luna: Quarterly reviews of the BOM health. That’s actually smart. It aligns with how investors look at runway too. Lucas: It does. Investors are starting to ask about supply chain redundancy in due diligence. If you can show them a map of your critical components with dual-sourced alternatives, it reduces their perceived risk significantly. Luna: So it’s both a operational necessity and a fundraising asset. Double win. Lucas: Double win. But here’s the thing that keeps me up at night. Even with dual sourcing, what happens if the whole category disappears? Like memory chips or certain passive components during a global shortage? Luna: Then you’re at the mercy of the broader market. Unless you have massive inventory buffers, which most startups can’t afford. Lucas: Right. So you design around availability. You avoid niche components that are prone to geopolitical bottlenecks. You choose parts that are produced by multiple major foundries across different regions. Resilience isn’t just about having a backup plan; it’s about choosing a path that doesn’t require one. Luna: Designing for resilience means accepting slightly higher costs or slightly lower performance upfront to avoid existential risk later. Lucas: Exactly. It’s insurance. And unlike car insurance, you hope you never have to use it, but if you don’t have it, you’re bankrupt. Luna: That’s a strong way to put it. Most people think of insurance as a cost center, but in hardware, it’s a survival mechanism. Lucas: Before we go further, I want to mention something quick. If these conversations help you navigate the messy reality of building hardware, supporting us directly keeps the lights on and the ads away. Honestly, if today was worth a coffee to you, that's the link — buy me a coffee dot com slash fexingo. Luna: Yeah, it really helps us dig deeper into these specific engineering challenges rather than skimming the surface. Lucas: Back to the topic though. Let’s talk about the psychological barrier founders face when switching components. They feel like they’re admitting failure if they change a part after the initial design freeze. Luna: Pride over pragmatism. They’d rather burn cash on a risky single source than admit the first choice was bad. Lucas: It’s sunk cost fallacy on steroids. Once you’ve spent three months optimizing the firmware for Chip A, you’re emotionally invested in Chip A. Switching to Chip B feels like throwing away that work. But holding onto a dead part is worse. Luna: How do you convince a founder to make that switch cleanly? What’s the best approach? Lucas: Show them the total cost of ownership. Include the risk premium. Calculate the potential revenue loss from delayed shipments, the cost of customer churn, and the engineering hours needed for emergency fixes. Put it in numbers they respect. Luna: Financial modeling of technical risk. That usually works. Founders speak the language of margins and downside protection. Lucas: It does. And once they see the spreadsheet, the emotional attachment fades. It becomes a rational business decision rather than a personal ego battle. Luna: I wonder if hardware accelerators should mandate this kind of analysis before releasing funds. Make it part of the curriculum. Lucas: Some do. But many focus so heavily on product-market fit that they neglect the plumbing. They assume the tech will work, and they forget that the tech has a shelf life. Luna: Shelf life of the components, not just the product. That’s a crucial distinction. Lucas: Yes. Your product might last ten years, but the components inside it might only be supported for five. You have to plan for the maintenance cycle, not just the launch cycle. Luna: So obsolescence management is really a post-launch responsibility, not just a pre-launch hurdle. Lucas: It starts pre-launch but lives forever. As long as you’re selling the product, you’re managing its lifecycle. It’s continuous. Luna: Continuous monitoring of your own supply chain. It’s a lot of work for a small team. Lucas: It is. But the alternative is waking up one day and realizing your factory is idle because you can’t get the one thing that makes your product work. Is there anything else you’d add to the playbook for founders? Luna: Just remember that relationships matter. Keep good terms with your component suppliers’ application engineers. When things go sideways, those contacts are your lifeline. Lucas: Good point. Don’t just transact with them; build relationships. They might give you early warnings or help you find a workaround when others see none. Luna: Human intelligence beats automated alerts every time. A phone call to an old contact can save a project. Lucas: Absolutely. Technology gives you data, but relationships give you context. Use both to stay ahead of the curve. Luna: It’s funny how the oldest business advice applies to the newest tech. Network well, plan for the worst, and never bet the farm on a single variable. Lucas: Those timeless principles are exactly what keep hardware startups alive when the silicon runs out. Thanks for listening.