Start with this idea: without a hub, you’re explicitly relying on the infrastructure that already exists wherever your user happens to be. In almost all cases, that means you have to rely on WiFi. For many products, carte blanche WiFi implementation just isn’t practical. Not only is there a major cost with slamming a WiFi chip into everything (see: HitchHiker’s Guide to IoT Standards and Protocols), but there’s also serious hangups during first time setup as well as ongoing maintenance nuisances— you have to create a system to hand each device credentials in the field, many of which are headless devices and thus inconvenient for your users. Secondly, those credentials can’t break ever. For simple devices, you theoretically could use WPA2 with some pre-shared key, but that means you’ll be relying on some hard coded credential for your user's WiFi infrastructure; for many deployments that is unacceptable because often we need an authorization scheme that can turn users on and off.

There are a few alternatives to WiFi that don’t involve a hub. Some products, for example, don’t need persistent connectivity. Take a Bluetooth button for example—it uses a smartphone as ‘infrastructure,’ and if it’s not in range of the phone it’s paired with, the button doesn’t work. If spotty connectivity isn't ok with your use case, then another option is cellular. While cell connectivity is an obvious choice for outdoor applications, it may also a good choice for indoors when you want zero touch provisioning for the user or you need a persistent backhaul to the internet, such as with security products. Keep in mind, it’s usually a small amount of data being moved across many concurrent connections-- negotiating with the MVNOs is critical here because you’re paying for the number of open connections as well as amount of data. Between the costly WiFi/cell path or persnickety short range options, going to some kind of mesh network solves a lot of problems, and it means launching with a hub of some kind.

In the world of consumer products, that’s where this is really hard because it's an additional piece of hardware to fiddle with, and hardware is hard; this conundrum has been an age old discussion in home automation. Incidentally, the cure-all for home connectivity is the nut Zigbee was trying to crack, but there’s just not enough user adoption. There’s some SmartThings and Wink hubs out in the world which provide some Zigbee coverage, but it’s simply not nearly enough to bet the farm on it as a product manager launching a connected thing into the world. The tiny fraction of households that do have some mesh based hub are still a tough bet because those products may not even have longevity (see: Revolv).

But don’t fret: putting a hub out there opens up a world of possibilities. Once you realize your product exists alongside others, you start to build an integration story that evolves into more features you can monetize. Instead of hanging your hat on a mythical far future standard that hands you interoperability with everything, launching with a hub allows you to immediately bridge across these different standards—you can stack as many radios into a hub as your product definition calls for. Even a hub that only supports WiFi means that you can take direct local control of devices that typically talk to their own clouds. Depending on your application, this will work out well for you because then you don’t have to worry about the third party data policies, thanks to the precedent set by court over jailbreaking iPhones. Basically, as an owner of the hardware, the consumer can do anything they want—hack it, hit it with a hammer, or give you permission to access it. So, with your hub sitting there in direct control, you become the arbiter of that data.

There’s more. The hub can be a much more reliable and fast experience than the device being directly connected to the internet. In the latter case the device has to keep an active open connection to some cloud, and that’s either a huge battery cost or just more attention span than many of these devices should possess. Ultimately, this setup lends itself to a very poor performance. A local hub can devote its attention to simultaneously maintaining a real time connection to the cloud and to its downstream devices, brokering messages a lot faster than the device maintaining its own connection. Connectivity is not free, and it doesn’t just cost in the latency or the amount of data sent. There’s a real cost to keeping a connection open with a server. A dozen connected lights in a customer’s home that speak WiFi and talk directly to the internet are that many open connections one must maintain (and pay for) in the cloud, and that starts to become expensive. With a hub in the equation, 12 connections becomes 1.

And don't worry about building a hub yourself. Sure, you could if you wanted to, and we even provide some reference designs on request. But, the easiest thing is to do your POC and beta with off-the-shelf options such as the Raspberry Pi, and source an "original design manufacturer" (ODM) hub from the likes of Foxconn for your product launch. 

Ultimately, the hub is a tool for a product manager to stabilize his or her product architecture and road-map long-term. Today you may launch some devices in the field with Bluetooth for local control, but tomorrow the market may demand cloud support that would be enabled by a hub. This 'hub optional' infrastructure will support both conditions natively, and the consumer doesn’t have to deal with any fuss as you further enable your product down the line. 

This article was originally posted on LinkedIn.