4 min read

API-first companies [Nexus Newsletter #142]

Hey friends,

I'm honeymooning this week 🥳 so this week's essay is recycled from a very popular 2021 edition. Enjoy!

“What’s incredible to me about (API-first companies) is that each represents something that a company would have had to build on its own previously, that it can now do by writing a few lines of code, and do better than they would have ever been able to in-house.”

Packy McCormick

Longtime listeners to the Nexus podcast know my favorite question: Why is the technology in buildings so far behind? I love asking it because I keep getting different, but insightful answers, which help us understand the obstacles we need to collectively overcome to make smarter buildings.

However, after asking it dozens of times, there’s still one answer I believe in but haven’t yet heard: Our industry is behind because we don’t yet have enough API-first companies.

Before I explain, a quick primer on APIs: Software applications are just a bunch of functions strung together to get things done. Application programming interfaces (APIs) wrap those functions in easy-to-use interfaces so you can work with them without being an expert or writing those functions from scratch.

Unfortunately, when we talk about APIs in the buildings world, we often talk about the API as the second option. Software as a service (SaaS) vendors want users to interact with their software through Graphical User Interfaces (GUIs). And they have this API, just in case you need to access your data in another way. In other words, the API is an afterthought.

But outside of our industry, we've seen an explosion of companies taking a totally different approach. They build their API (or APIs) as the primary option and their main strategy is to focus on one part of the stack and do it better than anyone else. They’re happy to be the infrastructure for someone else to solve the user’s problems most efficiently. They’re part of the solution, not THE solution.

When Shopify’s developers went to build merchant software that takes payments over the internet, they didn’t dare build it on their own. They used Stripe’s payments API. When Airbnb’s developers went to build the ability for hosts and guests to text each other, they used Twilio’s messaging API. When Uber’s developers went to build automated driver background checks, they used Checkr’s API.

The decision to be API-first is a first-order decision—all other decisions flow from there. For example, while Square makes hardware and software, that’s not what they sell. They sell their core differentiator: payments for small businesses. In fact, they literally give away the hardware and software for free.

That’s because they want you to use their API to accept payments and they don’t really care how you do it.

Compare that to a company in our industry like Density. Density’s core differentiator is that their sensors count humans anonymously and accurately. But that data stream is not what they sell. They sell the entire stack, from hardware to SaaS.

They want you to use their SaaS to “simplify space planning, manage operating expenses, and meet new workplace expectations with a single platform”, even though all of those things depend on more than just occupancy data. They’re not a part of the stack, they want to be the whole stack.

No offense to Density of course, I’m not knocking them—if every building in the world had accurate occupancy data I would be ecstatic. I’m simply observing that more often than not, our industry makes the API-second decision Density has made. And I think the implications of these collective decisions are a big drain on our progress because instead of everyone focusing on only what they do best, everyone is doing the same sh*t.

To explain further, check out our deep dive into one piece of the smart building stack that’s ripe for an API-first company to take over: the data layer.

Do you agree?

Let us know on LinkedIn,

—James Dice, Founder of Nexus Labs

P.S. By the way, Jon Clarke of Dexus takes this philosophy one step further: MQTT at edge, and API as central interface.

✖ At the Nexus

Here’s everything worth sharing from Nexus HQ this week:


★ PODCAST: 🎧 #115: The role of the smart building consultant with Bruce DuyshartEpisode 115 is a conversation with Bruce Duyshart, founder and Director of Meld Strategies, a Smart Building Consultancy based in Sydney Australia.

In this discussion, we'll unpack the role of a Smart Building Consultant and the process of running and managing a Smart Building project and the human side of what it takes to create a successful project.



Pro Member Gathering: Sara Neff, Head of ESG at Lendlease will do a deep dive into Scope 3 Emissions and Embodied Carbon. She'll cover the role of sensors in addressing tenant emissions and innovations in low carbon materials.

Note from James Dice: As a reminder, I'll be away on my honeymoon. Rosy Khalife (Pro Member) will be hosting. Hope you can make it! August 31st @ 9:00am MT.

Join Nexus Pro now to get the invites and access to the recordings.


★ ON LINKEDIN: Stop calling your product a platform.


★ CARVEOUTS: Using AI to Optimize HVAC Systems in Buildings: A Real-world Example


★ JOBS: Are you hiring? Searching for a job in smart buildings?—We've relaunched the Nexus Labs Jobs Board and we've made job postings free.

It's got great jobs from Synchronoss, Honeywell, Aquicore, Vanti, McKinstry, GridPoint, Gridium, Buro Happold, WSP, Switch Automation, and ThoughtWire

👋 That's all for this week. See you next Tuesday!

Whenever you're ready, there are 3 ways Nexus Labs can help you:

1. Take our shortcut to learning the Smart Buildings industry here (300 students and counting)

2. Join our community of smart buildings nerds and gamechangers here (400 members and counting)

3. (NEW) Sponsor our newsletter & podcast & get 5k+ nerdy eyeballs and earholes on your brand, product, or business.