As I’ve watched the Internet of Things landscape evolve over the years I’ve been shocked at how many maker-grade projects are released as products onto unwitting consumers.
It often feels a lot like the dot-com era when anyone who could write a few lines of HTML was starting a company. Now, it seems, if you can make some LEDs blink with an Arduino dev board you’re qualified to start a hardware company. The fallout of awful products and company failures has followed.
Pillars of Production
As I’ve thought more about the differences between maker projects and consumer products I’ve come up with, what I call, The Pillars of Production. These are high level concepts that govern how I think about creating production-grade products.
Determinism is the concept that you know precisely how your product will behave in a variety of conditions and that it will do so repeatedly. It involves being explicit everywhere. That means in code as well as in processes allowing you to reduce the number of “surprises” you run into. Your firmware, hardware, and backend should all be as deterministic as possible. “It works on my machine, ship it!” will get you in big trouble when it comes to shipping products.
Compromised IoT devices have made internet headlines over the years. If your device is easily hacked it will quickly begin serving it’s new purpose in an IoT botnet, happily DDoSing everything in sight. But security goes beyond not joining a botnet. You need to ensure your customer’s data is safe and secure. That communication between your own devices is encrypted. If security is an afterthought you will eventually spend, in spades, all of the development time and money you saved. It will go to your new best friends…lawyers.
This one is super important and often overlooked in the rush to deliver. “Just get it done, we’ll clean it up later”. Do that for 10 months and I promise you will be in a maintenance nightmare. With every feature you implement you have to be mindful of the maintenance impact. If you don’t, every new change will have an increased chance of breaking something and will take longer and longer to implement. Maintenance costs become a compounding interest problem if you don’t pay down the early technical debt.
It’s been awesome to see testing get so much attention and investment in the software industry over the last decade. But testing hardware and firmware is a little harder than running
npm test. As such, adoption in the IoT world hasn’t seen the same enthusiasm. You need a test plan for the hardware. You need to write unit tests for firmware and you can even get super fancy with Device Under Test (DUT) jigs to do full end-to-end testing of your devices.
In a production environment you need to be able to scale all aspects of the development operation. That includes scalable processes like source control, building firmware, and even how you set up your dev environment. All things you don’t think about in a maker project. Your infrastructure also needs to be scalable. Recording sensor readings from your garden is very different from managing sensor readings from 50 thousand gardens.
Almost all of the content on Production ESP32 will tie back to one of these foundational pillars. I want to share them because I’ve had so many people reach out with Arduino prototypes asking what it takes to turn them into products. It takes a lot of work, attention to detail, and professionalism. You need to be intentional and remember the Pillars of Production.
What do you think? Have I missed any pillars? Do you disagree? Agree? I would love your insight.
Join the community and get the weekly Production ESP32 newsletter. Concise, actionable content right in your inbox.