From open source packages to smart home hubs to SaaS platforms, these days there is no shortage of pre-packaged solutions to choose from when building an IoT product. While these “off the shelf” services may be very tempting to an otherwise overwhelmed entrepreneur about to embark on years of product development, it is not always the right decision to buy versus build. Failure to do a comprehensive analysis up-front could jeopardize a product launch or lead to huge costs over the long term. So, in the first of a series of blog posts entitled Behind The Vents, I’d like to share an overview on how and why Keen Home decided to build its own IoT infrastructure by focusing on the two key elements: Smart Home hubs and SaaS platforms.
Smart Home Hubs
In the early stages of Smart Vent development, we had to decide whether we would build our own bridge or operate solely on partner platforms (smart home hubs like SmartThings and Wink). Partner hubs were appealing because they enabled us to get our hardware in beta users’ hands with minimal software development, virtually no interaction with the partner platform’s engineers, and at no cost. Ultimately, the SmartThings platform was invaluable to us and informed the development of our own hardware, but as the vision for the Smart Vent grew, the long-term viability of solely relying on this type of platform severely diminished.
Since these platforms aim for generic device support, many of the advanced features we wanted to build were either not possible on these platforms or required some serious hacking. For example, doing historical data analysis on duct temperatures would have been nearly impossible since many of these platforms would not enable us to seamlessly send data back to our cloud. To further complicate this, even if we could send the data back to our platform, we wouldn’t have been able to associate the data to a user and take actions on their behalf. That revealed another issue: we didn’t have a direct relationship with our customer - the smart home hub provider did. This 3rd party relationship with the user made it very difficult for us to recommend value-added products such as repeaters and Smart Filters.
SaaS IoT Platforms
Once it was clear that we would be building our own ZigBee to Ethernet Smart Bridge, we began to investigate another appealing product category: SaaS IoT platforms that provide an off the shelf solution and integrate cloud-to-cloud with a client’s back-end. Such platforms can be thought of as “middleware” in that they act as a broker between your hardware device and your back-end where you would implement your specific business logic. There are a number of things to consider with these platforms.
The first is that many of these providers charge a recurring per-device cost for connectivity to their system. In many cases the specific cost was obscure, but we were able to estimate reasonable pricing for each provider, some of which were per device per month. From a system perspective, because this cost grows linearly as we sell devices, we would not be able to take advantage of the economies of scale gained by building our own system hosted on a cloud service provider, such as AWS. On the hardware side, since many of these providers supplied SDKs to make a device compatible with their platform, we would have been forced to include far more hardware onto our devices than otherwise necessary to function at a reasonable cost. So, right out of the gate, most of these service providers were taken out of consideration because passing on the recurring connectivity costs to the end-user was untenable and the impact on our unit profit margins would have been material.
Next, we found that while the communication between the ZigBee layer (the device) and the back-end was advertised as “out of the box,” there was still an associated build cost. For example, in order to enable communication between our Smart Bridge and the cloud, we needed to find a way to get the provider-specific firmware onto our device, which limited compatible hardware and, as mentioned earlier, would have bloated the cost of manufacturing our Smart Bridge. Similarly, we found that building our application-specific functionality via cloud-to-cloud integrations shifted the kind of work we’d have to do on the back-end, but not necessarily the amount of it. We would have had to deploy our own databases to store user and home data, capture and store long term sensor data, and build out all of the real-time analysis that affect vent state. Removing device-to-cloud connectivity and communication was only a small piece of the puzzle; the bulk of the development work would still rest on our shoulders.
Finally, even if we were successful at building a cost effective Smart Bridge and integrating cloud-to-cloud, we were left with one lingering problem: future switching cost. So much of the hardware, firmware, and back-end software built around the selected service provider would have caused a major build if we needed to move to another platform or to build our own. Considering that many of the solutions are offered by startups that may not be in business a few years from now, this was a very real and considerable risk that we were unwilling to incur.
Building a custom IoT platform is no easy feat. It takes a great amount of software, system architecture, and hardware expertise to pull off well. Therefore, the final question we asked ourselves was, “can we pull this off?” For us, the answer was “yes.” Not only did we have the software and architecture skills in-house, but we found a reference design for our Smart Bridge that vastly simplified the build for that product. We were able to leverage a number of open source solutions for both the hardware and software while putting significant effort to ensure our custom builds were the right ones for our specific application. We subjected ourselves to tough constraints on timeline, budget, reliability, business risk, and scalability and, in the end, designed and built a system that fits our needs and sets us up nicely for future enhancements.