Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / Why Hardware Startups Should Use Design for Test from Day One
Transcript
- Lucas: So you've spent months designing your PCB, you get the first batch back from the assembler, and half the boards don't power up. Now you're probing blindly with a multimeter, hoping you find the cold solder joint before your demo next week. That's the reality for most hardware startups — and it's totally avoidable. Luna: You're talking about Design for Test, right? DFT. The idea that you build testability into the board from the start, not as an afterthought. Lucas: Exactly. And I want to make this concrete because DFT is one of those things that founders nod along with but then skip because it adds maybe ten percent more board area and a few extra days of layout work. But the cost of skipping it is exponentially higher. Let me use a real example. Luna: Please. I've seen too many startups treat 'we'll test it later' as a plan. Lucas: There's a medical-device startup I've been following — they make a wearable continuous glucose monitor. On their first prototype, they embedded JTAG test points, boundary-scan cells, and a dedicated test-access port on every board. Revision zero. They didn't treat test as a separate phase. They treated test as a design requirement. Luna: JTAG and boundary scan — that's standard for complex ICs, but on a whole board? How does that work? Lucas: You put a boundary-scan chain on every digital pin. When the board comes off the line, you run a test pattern through the chain — basically you tell each pin to output a specific value, and you read back what the neighboring pin receives. If a solder joint is open or shorted, the pattern breaks. You know exactly which net failed, down to the individual pin. Luna: And the medical-device startup — how did it go for them? Lucas: Their first-article inspection caught ninety-four percent of soldering defects. That's not after a week of debugging. That's in the first hour after the boards came out of reflow. They knew which joints to rework before they even powered the board on. Luna: Ninety-four percent is huge. What about the other six percent? Lucas: Mostly power-related — voltage regulator dropouts that boundary scan can't catch because it's digital-only. But they had a separate test point for every voltage rail too, so that was a five-minute continuity check. Their total debug time from bare board to functional prototype was something like eight hours. A comparable startup I know that skipped DFT spent three weeks debugging their first batch. Three weeks of engineers staring at oscilloscopes. Luna: Three weeks of engineering time is brutal. That's easily forty thousand dollars in salary plus whatever delay costs in missed customer commitments. Lucas: Exactly. And the re-spin cost if you don't catch a layout error until after you've built a hundred boards? That's another twenty to fifty thousand, plus a six-week lead time. DFT doesn't just save time. It saves your cap table. Luna: Okay, but I want to push back a little. Adding test points and boundary-scan cells takes board real estate. If you're designing something tiny — like a hearing aid or an implant — every square millimeter matters. There's a real trade-off. Lucas: There is. And I'm not saying you put test points on every net in a space-constrained product. But you can be strategic. You prioritize the nets that are most likely to fail — fine-pitch BGAs, connectors, high-speed differential pairs. And you use test-access ports that are daisy-chainable, so you only need a few physical pads to access hundreds of nets. Luna: So you're saying the trade-off is usually worth it. But when does it stop being worth it? Like, at what production volume does the upfront DFT cost pay off? Lucas: I've run the numbers with a few founders. If you're building fewer than two hundred units total, and you have an engineer who can manually probe each board in under an hour, you might break even skipping DFT. But most hardware startups plan for at least a thousand units in their first production run. At that point, DFT pays for itself in reduced debug labor by unit five hundred. Luna: Five hundred units. That's not a huge number. And if you go to high volume, the savings compound because you also reduce field failures. Lucas: Right. Field failures are the nightmare. A single field failure can cost hundreds of dollars in replacement, shipping, and customer support. If DFT catches one defect that would have slipped into the field, it's already paid for the extra board area on that design. Luna: I want to ask about the tooling. There's an open-source tool called OpenOCD that does boundary-scan testing, right? Can a startup use that instead of buying expensive test equipment? Lucas: Absolutely. OpenOCD — Open On-Chip Debugger — supports JTAG boundary scan for a huge range of ARM and risc v microcontrollers. You can run it on a twenty-dollar USB dongle. There's a learning curve, but the cost is essentially zero. For a startup on a shoestring, that's a game changer. Luna: So the barrier to entry is lower than most founders think. They just have to know about it and decide to do it. Lucas: That's the key. The technical knowledge is out there. The decision is the hard part. Because DFT adds work upfront when you're already under pressure to ship. But the startups that do it — they just flat-out ship faster with fewer surprises. Luna: It's like writing unit tests in software. Nobody wants to do it, but the ones who do have way fewer production bugs. Lucas: Perfect analogy. And just like with unit tests, the earlier you start, the cheaper it is. Adding DFT to a board that's already been routed is a nightmare. You have to rip up traces, add vias, redo the stackup. But if you plan for it from the first schematic, it's maybe a day of extra layout work. Luna: Let's talk about the specific techniques a startup should use. What's the minimum viable DFT for a two-layer board with a microcontroller and a few sensors? Lucas: Minimum viable: one JTAG connector — that's four signals plus ground. You program the microcontroller to run a self-test on power-up that checks each sensor and reports status over UART. That's not full boundary scan, but it catches the most common assembly defects: bad solder joints on the MCU, power shorts, sensor misalignment. Luna: So even a simple startup can do that with just a header and some firmware. Lucas: Yes. And if you have a BGA or a fine-pitch QFN, you really want boundary scan. But for through-hole and larger surface-mount parts, a power-on self-test combined with visual inspection gets you a long way. Luna: What about the test access port you mentioned earlier? That's more advanced. Lucas: A test access port, or TAP, is a dedicated block of pins that gives you access to all the internal scan chains. If your microcontroller has a built-in TAP — most ARM Cortex-M chips do — you can use it without adding dedicated boundary-scan ICs. That keeps the board simple. You just need to route the TAP signals to a connector. Luna: And if the microcontroller doesn't have a TAP? Lucas: You can add a small boundary-scan controller chip, like those from Texas Instruments or Analog Devices. They're a few dollars each. Or you can use a FPGA to implement your own test controller. But for most startups, the microcontroller's built-in TAP is sufficient. Luna: Got it. So the message is: don't skip DFT, but you don't need to go overboard either. Start with JTAG and a self-test, and add boundary scan for complex parts. Lucas: Exactly. And if you're doing any kind of high-speed digital — USB, Ethernet, HDMI — you must have test points on those nets. The signal integrity margins are so tight that a slightly cold solder joint can cause intermittent failures that are nearly impossible to find without a test pattern. Luna: Intermittent failures are the worst. They pass initial testing then fail in the customer's hands. Lucas: Those are the ones that kill startups. Because you ship a batch, they work for a week, then they start crashing. You have no idea what's wrong. The customer loses trust. DFT specifically catches those weak joints before they ever leave the factory. Luna: So fundamentally, DFT is about de-risking the manufacturing ramp. Which is exactly what a hardware startup needs when every dollar and every day counts. Lucas: Right. And I want to be clear: I'm not saying DFT is a silver bullet. You still need functional testing, environmental testing, reliability testing. But DFT is the layer that catches the most common defects at the cheapest point in the process. It's the first line of defense. Luna: And if you skip it, you're effectively betting that your assembler has perfect yield. Which no assembler does. Lucas: Exactly. Even the best contract manufacturers have defect rates of a few hundred parts per million. If you're building ten thousand boards, that's potentially dozens of defective units. DFT catches those. Without it, they become customer returns. Luna: And the cost of a customer return is way more than the cost of the board. There's shipping, support time, and maybe a replacement unit. Lucas: Plus the reputational damage. For a startup, a few bad reviews on Amazon or a negative write-up on a forum can kill the next funding round. Luna: So let's say a founder is convinced. What's the first concrete step they should take? They're designing their first PCB right now. Lucas: First step: include a JTAG connector on your schematic. Even if you don't use it for DFT initially, you'll use it for programming and debugging. Then, in your layout, add test points on every power rail and every I/O pin that goes to a connector. That's maybe ten extra pads. Then, write a simple firmware test that exercises each peripheral and outputs a pass-fail over UART. That's it. That's the minimum. Luna: That's very doable. I think a lot of founders can handle that. Lucas: Absolutely. And once you have that infrastructure, scaling up to full boundary scan is straightforward. You just add the scan chain in the schematic and use OpenOCD to generate the test patterns. Luna: So the key is to start small but start now. Don't wait until the board is designed. Lucas: Exactly. And if you're at the schematic stage right now, you can add DFT with zero extra board spins. The cost is just your time. And your time is valuable, but it's a fraction of what you'd spend debugging later. Luna: That's a great message for founders. I hope they take it to heart. Lucas: And you know, that's exactly the kind of practical insight we try to bring on this show — things that actually save you time and money in the trenches. We deliberately don't run ads on these conversations, because we want them to be useful without interruption. If you find that valuable and want to support the choice to keep it that way, the link is buy me a coffee dot com slash fexingo. Luna: Yeah, I think that's one of the reasons listeners stick with us. It's just the content, no fluff. Lucas: So back to DFT — one more concrete tip. If you're using a microcontroller that doesn't have a built-in boundary-scan controller, consider switching to one that does. For example, many STM32 parts have a full TAP. The cost difference is often negligible, but the testability gain is enormous. Luna: So the chip choice itself can enable DFT. That's a smart procurement angle. Lucas: Right. And when you're doing your BOM optimization, don't just look at unit cost. Look at total cost of test. A chip that's fifty cents more but saves you two hours of debug per board is a massive net win. Luna: That's a good way to frame it for the finance side of a startup. The CFO might not care about testability, but they care about debug hours. Lucas: Exactly. And that's how you sell DFT internally. You don't say 'we need more test points'. You say 'if we spend one day on DFT, we save three weeks of debug later'. That math speaks to everyone. Luna: I think that's the kind of concrete return-on-investment argument that gets things done in hardware. Lucas: Absolutely. And on that note, we'll wrap up. If you're building hardware, design for test from day one. Your future self — and your investors — will thank you.