From idea to (bootstrapped) hardware product — lessons learned

We launched Beru on Kickstarter today. It is a simple device that interfaces with your home security system to send you notifications when the alarm goes off.

Beru started as an idea about twelve months ago, in the winter of 2016. By that time, I had about twenty years of experience developing enterprise software, and a few years of tinkering with the Arduino and Raspberry Pi.

Beyond reading some Fritzing diagrams and putting together a circuit on a breadboard with some code pulled from GitHub and tweaking it here and there, I had no real experience building a hardware product.

This post is an attempt to put together some notes from my experience. While every situation and hardware project is different, I feel that these are things that any hardware startup without a substantial venture capital investment should be thinking about — in fact, I would argue a lot of this makes sense even with a heavily funded project.

• The “hardware is cheap” argument: There is a common perception that generic hardware is cheap. While this is true at scale (by scale, we are talking tens of thousands of units), it is certainly not the case at the numbers that most startups have to hit first. How about 5 units for an initial prototype? How about the next two sets that you need because you made changes to the circuit? How about the first 100, 1000, 5000? Hardware costs tend to be very high at small volumes, but fall dramatically at higher volumes because the cost of equipment setup is amortized over the number of units produced. For example, a board that costs $25 each to make at 25000 units, may easily run over $500 each if you were to make only a hundred.
• Don’t you just make it in China? Yes, of course. But again, this only makes sense when you are making a large number of units. There are many challenges to starting manufacturing in China, not the least of which are geographical distance, time zone, and communication. As a startup, you are constantly under pressure for time, and trying to build in China from the get-go is a sure way to squander this limited resource. Many startups fall into this trap and spend many thousands of dollars making trips to China to setup production lines while delaying product shipment. There are many excellent PCB fabrication and assembly shops in the United States. They are expensive compared to their overseas counterparts, but they are extremely competent, and there are none of the issues above. You can pick a shop that does the fabrication and assembly, or pick a different one for each. We ended up going with Advanced Circuits, but Small Batch Assembly in combination with OSHPark was in serious consideration. Either one would have been a good choice. Getting a quality product to market in time far outweighs the additional expense of making it locally. You will have plenty of time and resources to make it in China (or wherever it makes the most sense for your product) once you have a viable product and a better idea of quantities.
• Lead time for PCB fabrication and assembly: PCB manufacturers batch orders to reduce costs, and their prices reflect this. If you want a PCB printed in two days instead of waiting two or three weeks, you can expect to pay two or three times the cost. This must be factored into any project planning to avoid downtime waiting for boards to arrive.
• Hardware: Spend time/money on the hardware to get it right. A software bug, in the everything-as-a-service (XaaS) world that we live in today, can be fixed with server side updates. In most cases the customer does not even notice. They hit refresh in their browser to load the new code and move on. If you have a hardware issue — chip that runs too hot, or a wireless antenna in the wrong place, the device is essentially an expensive paperweight. No firmware update is going to be able to fix that.
• Firmware development: Software engineers have always been spoiled for choice in the panoply of development and debugging tools available. There is a dizzying selection of editors with integrated line-by-line debuggers out there, and as new languages and frameworks appear, the toolsets tend to keep pace. Not so in the firmware world. I found myself writing debug lines to serial output to debug my code. If you have some code that depends on the hardware timer (like Beru does to sample audio data), writing to the serial port is so slow in comparison that it completely destroys any chance of the code working correctly. Speaking of which…
• OTA Updates: Make sure you have a way to update your firmware over-the-air (OTA). Having this capability provides a crucial escape hatch if you find a bug after the hardware is out in the field. Despite your best QA, because of the varying conditions in which real hardware is deployed, bugs are going to be found that can be fixed by a firmware update. Plus, aren’t you going to surprise your customers with an insane mode without having to purchase new hardware?
• Enclosure and Retail Packaging: You need a pretty (plastic) box to hold your boards? Then some Apple-esque retail packaging to go with it? Back when the idea of the product was but a gleam in my eye, I would dream about what it may look like in a customer’s hands. Thinking about the final product this way gave me a sense of purpose (and it is also fun). There are a lot of everyday products being reengineered just to make them look cooler, right? This is when reality hits you in the face. There is real engineering (and money) behind these designs, and some venture capital here comes in handy. Besides, beyond aesthetic concerns, there are practical considerations that affect the design choices— if you run alternating current inside your enclosure, you will likely need U/L certification, which adds complexity to the project. There may be space or environmental conditions to take into account (e.g., wearable devices or devices that need to work in an industrial setting). For the more simpler hardware, fortunately, there are several stock enclosures and retail packaging options available, and usually you can find one that is half-decent for your product.
• Device management: There are many platforms for managing fleets of devices out in the field, including sending events back and forth, and rolling out OTA updates. Depending on your event volume and other factors, costs for these can vary largely between different vendors. There is usually an ongoing monthly cost for maintaining these devices. Remember to factor these costs into your pricing model — otherwise a successful device that does not produce recurring revenue will eventually become a drain on your bottomline the longer it is in service. These costs are often controlled by the platform vendor and may not be predictble over the lifetime of your device. Work out a migration path to a different platform even if you don’t need to do it right away. This will help you avoid costly decisions at the hardware level that cannot be fixed or leave a bad taste in the customer’s mouth down the line.

In summary, it is important to understand the steps involved in building the product end-to-end, the time frames involved, and how you plan to get there. This includes engineering on the hardware side, server side code if needed, mobile apps, device management, beta testing, manufacturing, and certification and anything else unique to your product. If you need help with any of this, find a good company that can work with your budget. This is a good option if you do not have the skills or find it hard to find people within your network. I talked with a few such companies — by this time, we had most of the software and the firmware built, so we did not go with any of them. I feel like either company would be a good choice. Here’s a brief review of my experience with them:

• Viget: They explained their process clearly, had a few questions about what we were trying to do and our budget, and gave me a quote within a couple of days. There was a detailed breakdown, and they even pointed out items that we could possibly do on my own, to save on costs. Ben and Justin at Viget stayed in touch throughout the project and continued to offer help without any kind of sales pressure.
• MistyWest: They had a few questions about the project and budget, then gave me an estimate. They also offered suggestions on ways to reduce engineering costs to stay within my budget.

I probably missed some things here, but I will update over the next few days.

Beru is on Kickstarter here.