Revenge of the Tinkerer

Posted by Neha Palacherla /October 3, 2013 / FounderTalk

This guest post was written by one of our hardware ManagingDirectors, Carson Darling. He is also a founder of Rest Devices, where he leads electronics and software development.

In the startup world, I’ve heard the suggestion to “release early, release often” over and over again. It was mentioned by Paul Graham, and Wikipedia even dates it back to open source advocate, Eric S. Raymond’s The Cathedral and the Bazaar. For startups, the benefits are pretty obvious: you get early user interaction so you start to learn about your users, you are forced to actually finish a plan, and you get to test out both the idea as well as the team. But people think that on the hardware side of things there isn’t time or money to iterate and make mistakes. That just isn’t the case anymore.

Yes, hardware is different than software.

With software, deploying can be as easy as asking a chat bot and then, BAM! it’s running live for people around the world. According to Github, they had days with more than 175 deploys! Now, I know that I’m drastically simplifying the process and the effort involved, but when you boil it down, it’s possible to have fully functioning software deployed to end users at an incredibly fast rate.

Compare this to the “typical” hardware development timeline. Even once everything is designed, CADed, drawn, and finalized, the process of physically deploying that new iteration can take weeks or months. First, parts have to be sourced (if you’re lucky you can get them tomorrow, other cases could be 12 or more weeks!). Then, they have to be assembled (soldered, printed, glued, packaged, etc.), and then finally, delivered to the end user.

But moving fast and iterating IS possible.

At one point last year at Rest Devices, we had to deliver 10 fully functioning respiration measurement devices for testing. We had a hard deadline to meet, otherwise we’d lose the chance to collect data that we needed to use to improve our algorithms. We were on an incredibly tight timeline. We had two days to progress from concept to finished devices, and we were strapped for cash.

Normally, this shouldn’t be possible. Even if you nail the design on the first try, PCBs will take a day to arrive, and you’re stuck developing firmware without the final hardware. And if you do make a mistake, you’ve got to hope you have something that can be fixed with green wire.

In general, physical prototyping has two incredibly important requirements: time and money. At every stage of deployment, you can trade one for the other. For example, with PCB fabrication, we were quoted $319 for a 3-day turn around, and a whopping $808 for same-day turn around, and we still had to add a day (at minimum) for shipping.

However, you don’t have the money to do it quickly or the time to do it slowly, you’re in a tough spot. Unfortunately, our project was in that position. No one thought that we would be able to pull it off.

So how did we do it all in two days? We Makerbotted a custom PCB etch tank (complete with lights and agitation), so that we could make our own PCBs. We hand soldered all of the components, and tested them at each step of the way. We even printed the final plastics that were then sewn onto the garment. After two sleepless nights, the devices were finished, delivered on time, and miraculously, they worked!

By being scrappy, and pulling together a few of our favorite tools (and no shortage of caffeine), we did more than any of us thought was possible.

All of this goes to say, there are more (and growing) ways to pull things together and make it happen quickly in hardware. Tools today are more forgiving than ever, allowing you to fix the mistakes you make quickly and easily. It’s possible to set up a shop for less money, and turn around times are just getting faster. Having a hardware component is no longer an excuse not to keep iterations happening fast.

Hard(ware) Failures

There’s also long been a belief that you don’t have time to fail in hardware – you have one shot at your device. During the development of the Mimo baby monitor, we had countless failures. We’ve assembled batches of boards with the LEDs backwards, we’ve swapped pins, and we’ve had cases fall apart. We’ve even had glued pieces fall apart in the hands of investors. But every single one of those failures was an incredibly important learning point, and I wouldn’t trade them for the world.

During the very first alpha test of our WiFi base station, we brought our baby monitor out to the homes of our test parents and tried setting them up. On the first try, only one out of five worked. The rest of them had issues connecting to WiFi (we had already tested the connection in lab!). After hours of debugging, it turned out that we had a software bug that wasn’t working with a specific WiFi security mechanism.

On the second test run, our range was beyond terrible. We actually had to string up one of the base stations in the bathroom of one of our test parents in order to get a reliable connection.

On the third run, we had issues specifying the WiFi name and password.

Despite having our tests run perfectly before, and having checked these devices over with a fine-tooth comb multiple times before bringing them to test parents, we still had major issues. If we hadn’t involved users from the very beginning, we would have taken twice as long to find these bugs. We might have even launched the final product with some of these issues, and had to support it for years. By involving the end users at an incredibly early stage (just 6 weeks after pivoting into the baby monitoring space), we got feedback that we wouldn’t have seen for months or years otherwise.

The biggest surprise though, was how willing everyone was to help. Despite having an incredible number of issues, and having us in their homes every couple of days, when the alpha test was over, almost all of the parents asked if they could keep using the devices. They were delighted to share their insights and the challenges they were having with the product. Plus, having exclusive access to the hardware was its own reward.

At Rest Devices, we’ve been trying to push the edge with what’s possible in terms of rapid iteration and quick development. People have told us that what we’re trying to do isn’t possible, or that we just don’t have enough time or money to make it happen, but we’ve long since squashed the vast majority of the bugs in our hardware, and are getting ready to ship production units. I’ve been lucky to have a team that just won’t quit, but the reality is, it doesn’t take millions of dollars or a gigantic team to develop hardware anymore.

It just takes resourcefulness, persistence, and a willingness to be scrappy. So let’s break out the soldering irons, the hack saws, and the hot glue guns, and let the tinkering begin.