Most IoT devices today only operate within the confines of point-solution ecosystems. Those ecosystem are locked and have limited interoperability with external software applications.
However, we think that significant new economic gains would occur if any device could readily be interconnected with third-party software applications.
For example, the ability to open up any building lobby door would allow FedEx or Instacart to eliminate missed deliveries. Meanwhile, a common interface to EV chargers and thermostats would let energy utilities adjust real time supply and demand of electricity.
Some of this is already happening.
Amazon Key integrates with garage openers, enabling unattended deliveries. Reliant Energy leverages Nest thermostats for demand-response. OpenDoor and Sonder eliminated labor costs by integrating smart locks.
However, for most application devs out there, IoT devices remain too hard. The lack of public APIs & OAuth requires significant reverse engineering, and the sheer number of device brands only compounds the challenge.
It does not have to be this way.
Fin-tech used to be plagued with a similar problem. Before Plaid, developers had to fight a convoluted mess of bank login-screens and archaic ACH protocols. Then, Plaid came along, aggregated all 5000+ U.S. banks, and provided a single easy-to-use API.
The same dynamic will play for IoT.
We’ve seen enough developers struggle with this IoT device integration task to warrant the existence of a platform that solves it. We see this problem across hospitality, delivery/logistics, proptech, energy, and many other sectors where software needs to interface with the physical world.
To succeed, this platform must first aggregates economically-important devices behind a single API.
Second, it must then nail the developer experience to ensure demand-side aggregation of developers and their users.
Third, it can leverage the demand-side aggregation to economically incentivize the supply-side (OEM & their devices) into becoming fully compatible with the platform.
We're obviously building that platform, and here we detail some thoughts and strategies of how we plan on going about it.
State of The IoT Ecosystem
To start, we provide our point of view on the state of IoT, as well as the resulting dynamics that create an opportunity for a platform like Seam to exist.
Over the past ten years, we’ve seen a rapid proliferation of internet connected devices.
For example, Nest was once the only wifi thermostat in the market. We now survey over 60 different models. Similarly, we've found over 100 different smart lock models. In fact, pick any device category, and you'll find dozens of brands competing against each other.
A lot of this has been driven by Chinese OEMs repurposing smart-phone components to add connectivity to just about anything. And the net result of all this has been a sharp drop in device prices, and more devices than ever are being installed by consumers and businesses.
But up to now, most of these devices have been sold as simple point-solutions with limited interoperability.
For example, you can buy a smart lock and remotely unlock it from the OEM's app. However, good luck trying to connect it to Airbnb to automate guest access. Similarly, you have countless camera options giving you real-time video feeds, but almost none will tell you how many people are in your retail store right now, or whether your warehouse has any safety risks.
Everything is just simple devices that have basic atomic functions. Nothing is correctly addressing the more specialized needs of users.
Things are this way for a couple of reasons.
First, OEMs are not good at software. Their expertise is hardware and manufacturing. Creating additional apps and services on top of their devices isn't something they really know how to do. Second, if they did know, the breadth of use cases and customization-needs would quickly overwhelm any company.
Third-Party Devs are Key
So at this point, it's pretty clear that device OEMs will not be the ones building the software that will fully leverages those devices.
So who will? Third-party software developers.
They're already creating vertical SaaS offerings targeting every nook and crannies of our economy. They understand the need of their customers best. And they want to leverage devices that their customers already own to deliver new features and real-world automations.
Across the board, these developers will all use the same atomic device functions (e.g. lock & unlock). However, they will be doing across radically different industries like hospitality or parcel delivery.
Enabling third-party devs to leverage IoT devices will greatly increase the economic impact of those devices.
Integrating Devices is Really Hard
Unfortunately, for third-party developers, a lot still needs to happen before they can easily start integrating devices with their applications. As of right now, it's still too hard.
Bad & Non-Existent Device API First, most OEMs don’t offer a public API for their devices. This is primarily because whether a device has a public API or not, is not a factor in most buyers' purchase decision making.
However, what is a factor is whether the buyer can remotely control this device from an app or website. This means that there is a private/internal API somewhere!
But to tap into it, a developer first needs to do significant reverse-engineering to understand how this API works. You have to use a complex toolchain that includes Android emulators, ADB, HTTP ToolKit analyzers, CERT-pinning, and even decompiling tools when you need to understand cypher suites being used. To study how an OEM's app and internal API works is an art form.
And frankly, despite experts at it by now, the process sucks. It takes days, sometimes weeks to fully understand the scope. And internal APIs tend to be poorly designed, requiring many hacks & workarounds.
You simply can't expect the average developer out there to be able to pull this off.
Authentication and Security Second, even if you manage to reverse-engineer an OEM’s internal API, you still have to figure out how to authorize your application against your users’ devices.
On the web, third-party auth is a long-solved problem. You just implement OAuth. Your users can then authorize third-party apps to access their account (e.g. log-in with Google).
Unfortunately, in the world of IoT, OAuth is a rarity (we've seen it only once).
This means that offering an integration between your app and your users’ devices, requires implementing an intricate auth flow from scratch that achieves the same outcome as OAuth.
This UX flow must guide users through identifying the device they wish to link to your app, collecting their account credentials, and verifying access. These collected credentials must then be securely stored so that you can regenerate session tokens to use the internal API.
This is a major undertaking. We know, because we did it.
Device Fragmentation Hell Third, as each device category becomes ever more commoditized, the sheer number of devices to support compounds the aforementioned challenges.
This increase in choice (and decrease in price) is great for device buyers. For software developers, not so much! With each new device that becomes available on Amazon, the surface area of API, auth-logic, and maintenance chores increases.
Upcoming Regulatory Requirement Lastly, the explosion of ransomware and security breaches is prompting regulators to implement changes to how IoT devices can be accessed and secured. Many of the rules are still being drafted, but they will impose a similar regulatory burden on developers as the likes of PCI and HIPAA. This further increases the complexity of integrating IoT devices with a software application.
OEMs in Search of Recurring Revenue
The last point to bring up is how OEMs find themselves desperately looking for new revenue sources, and how third-party developers could be key to unlocking it.
First, this is what the CTO of Yale had to say about hardware margins trending toward zero:
Consumers expect to be able to control these devices remotely via our app. This means we have to run backend services. This costs us real money. We ran some experiments to see if we could charge for this, and the answer was a hard “hell no!” from consumers. This sucks. And our hardware is generating less and less margins with the slap-a-label-on-it OEM plays out of China that you can find flooding Amazon. There’s a real sense of urgency within Yale to find sources of recurring revenue to compensate for the server costs and the decreased margins. So far, nothing is really panning out.
Yale and Assa Abloy did explore interest in providing an API. However, what they quickly found out is that to be broadly useful, it would need to support other door lock brands since Yale is only 20% of the U.S. smart lock market.
Stated another way, even if one OEM provides a world-class API, this still does not solve the fragmentation problem developers are facing today.
Thus OEMs find themselves in a situation where they are very receptive to working with developers, but not necessarily able to do something about it due to the fragmented nature of the market.
The Blueprint for Seam
As mentioned, the current IoT ecosystem context and latent demand for software integrations create an opportunity for a platform to exist.
Here we provide a few heuristics for how we're going about building this platform. Furthermore, given the OEM and third-party devs symbiosis, we discuss longer-term plan to build network effect via double-sided marketplace dynamics.
Focus on Aggregating Devices with Economic Leverage
First, we only want to focus on devices that matter from an economic standpoint because this is where revenue opportunities will naturally exist.
For example, door locks can eliminate the need for expensive front desk staff, and thermostats can control a huge portion of a buildings’ energy usage. If there's economic leverage to be gained, dollars will flow.
On the other hand, we often get asked to support cheap home hobbyist sensors & lights. These devices present little value beyond making your house more fun. This leads to little desire to pay a recurring usage fee to Seam. For now, we chose to stay away from integrating those devices if the integration cost is high.
So how many economically relevant devices are out there?
Focus on Fragmented Device Categories
Second, we want to focus on fragmented device categories because this is where we find the highest level of developer pain.
For example, there are 39 OEM’s making smart locks. As a developer, managing this many integrations is awful. However, there are only 2 OEMs making people-counting sensors (Density and VergeSense). Though people counting is economically important, we don’t think it present enough API integration pain just yet.
Aggregate, Abstract, and Standardize
Third, there is an opportunity to maximize developer experience ("DX") by standardizing device functions across brands.
For example, smart locks all do more or less the same thing (lock, unlock, set user code). This means that even if all 39 OEMs have a different API for locking a door, we can refactor them into a simple SDK call like
door.unlock(). And though there are occasionally features no present across all devices, in our experience, developers never ask for them.
Ignore Old Devices — They’ll Get Replaced
Fourth, sometimes, even if a device meets our prior heuristics, the integration pain isn't worth the juice.
For example, there are still many 1970’s building access systems out there. Those are fully offline and often operate using old BACnet protocols. Bringing these devices online would requires extensive installation and retrofitting work.
We chose to stay away from these devices for now, and wait for them to be replaced. We know from folks like ButterflyMX that the annual replacement rate for building access system is about 5%. This means that in a couple of years, many of these older systems will have been replaced by internet-connected versions of themselves.
Be a Platform of Platforms
Fifth, we deliberately choose to be a software infrastructure company and we don't build anything at the application layer. We instead choose to be a platform for platforms.
To understand this strategy better, you can read through Ben Thompson’s essay on Stripe as a Platform of Platforms. Stripe only builds payment tools for developers who themselves may be platforms for online shops or SaaS plays. That is, Stripe doesn’t build tools for non-technical end-users. Instead, it builds technical tools for the ones who build solutions for those types of customers (e.g. Shopify).
For Seam, we lay low in the tech stack, building a generalized API that developers across many verticals can use. These developers know their market and customers best and will build the best UI leveraging those devices.
Arguably, this strategy results in less value capture on a per device basis initially. However, in the long-run, by virtue of being horizontally broad, it has the potential to be a much larger company. It also has a key advantage in that it leverages each of our customers' go-to-market function without us having to expand resources.
Focus on Great DX to Aggregate Devs (and their users)
Sixth, we have to build a great developer experience not just for the sake of it, but because it will help aggregate developers and their users, giving us leverage in our eventual negotiation with EOMs.
A great developer experience isn't just a solid API. It's a whole process that involves delighting a developer at every touch points. A touch point can be technical (client libraries, conventions, solid documentation...etc) as well as cultural (design, blog, brand/aura). Nailing this experience, combined with the platform of platforms strategy will give us meaningful leverage with OEMs.
Eventually, Integrate Directly with OEMs
Seventh, we eventually want to convince OEMs to integrate directly with Seam. This will lead to more stability and better developer experience.
First, it's important to note that we do not need a direct relationship with OEMs to get started. We've already proven that reverse engineering is sufficient.
However, we know that the reverse engineering has flaws. For one, it's prone to breaking, reducing SLA. Second, today, we must poll for real-time events instead of having those be pushed to us in the same way OEM push events to Apple and Google's notification services.
But we can't go to OEMs today. We're too small. We don't have much to offer them. And we would be vulnerable to their legal whims.
At its start, Plaid found itself in a similar situation, having to reverse engineer many banks' internal APIs and websites. It similarly found itself in the grey-zone.
However, with time, Plaid was able to aggregate enough developers (and theirs users) to coerce banks into working with them ("Make Citi compatible with Plaid or else Venmo stops working for thousands of your customers.").
This worked, and we intend to take the same approach: aggregate developers and their users; approach OEMs to do direct integrations; increase overall quality of our service, leading to more developers using us. Cycle repeats.
Build a Marketplace
When we asked one of our investor and early Plaid employee what was Plaid’s “pitch” to the bank, he answered that they would simply tell banks that by working with Plaid, they would sign up new customers.
Frankly, it's a bit of a weak argument and it's hard to believe that people would sign up for a bank based on it being compatible with Plaid. The reverse may be true (i.e. they would leave the bank if it’s not compatible), but Plaid can’t say that to a bank’s face without coming across as adversarial (“work with us, or else…”).
Ultimately, it appears that banks understood the zero-sum game nature of working with Plaid on their own. FOMO is powerful; especially in an ultra-competitive industry like consumer banking.
For Seam, we could certainly take a similar approach. As in, "OEM work with us or else your device won't be Airbnb host compatible."
However, these is a much stronger narrative to play up with OEM.
IF you assume that we can aggregate and charge the demand-side of the equation (developers) by creating a universal API that works with all these brands, THEN maybe we can kick back some dollars to OEM on a pro-rata basis, and create a new recurring revenue line for them. In marketplace parlance, this is called "found money".
So in short, Seam’s pitch to OEM is money.
Any OEM will be able to add their device ecosystem to the platform and get paid on a pro-rata basis without having to worry about managing thousands of third-party developer relationships.
Meanwhile, any developer will be able to easily unlock doors, control thermostats...etc without the need for complex BD partnership and intricate payment flow with each OEM.
Seam would sit in the middle, ensuring that parties are able to transact without burdening themselves with the actual steps needed for market making.
Obviously, this marketplace strategy will only work if the ecosystem of devices is fragmented and developers aren't able to standardize on a single device brand. So far, this appears to be the case, thus making disintermediation of Seam difficult.