How Do You Design a No-Code Platform?

Cormac Driver has seen smart sensors used for everything you can possibly imagine.

As Temboo’s head of product engineering, he’s heard of sensors buried in the ground around New York City to measure ground temperature, installed in sewers to record water levels, and, in his favorite use-case, placed in an octopus farm pond to track pH levels.

The proliferation of IoT devices has made it easier than ever before to gather data about the world around us, but managing those devices and extracting that data still requires technical expertise that can be hard to come by. That’s where Driver and his company, Temboo, come in.

Based in New York City, Temboo has built a platform that lets users build their own IoT monitoring systems without writing a line of code.

What we want to do is rely on a lot of smart defaults and then surface the questions to people that we really need them to answer.”

Temboo is one of a growing number of companies building “no-code” tools that can empower anyone to build a complex software system. Similar to Squarespace, which simplified web building with drag-and-drop templates, while taking care of the coding work for its users, Temboo’s Kosmos platform turns building an IoT system into a series of questions and answers.

“It’s not a common way to build a software interface, but what we want to do is rely on a lot of smart defaults and then surface the questions to people that we really need them to answer,” Driver said.

Although it’s designed to be simple from the user perspective, what’s going on behind the scenes is a feat of complex engineering. We spoke with Temboo about the technology underpinning no-code platforms, as well as the product decisions Driver’s team made to balance flexibility with the need to keep the user interface simple.

It All Starts With Asking the Right Questions

Kosmos’ onboarding begins with two simple questions: “What do you want to do?,” and, “Where will the device be located?”

The answers to those questions actually don’t matter all that much. The user could be installing a temperature sensor in a greenhouse or a pH sensor in an octopus farm — it would all be the same to the code generator, Driver said. Instead, the questions do the critical work of setting the tone for the onboarding experience — the most important step in Kosmos’ no-code process.

“It’s a tiny sense of progress that you can make right away and let people know they’re in the right place,” Driver said.

Since Kosmos is intended to be used by anyone, regardless of technology experience, the team modeled the process of gathering code requirements after an onboarding conversation. Each question a user answers fills in a blank the code generator needs to develop a working IoT systems platform.

It’s a tiny sense of progress that you can make right away and let people know they’re in the right place.”

To build the process, Driver said his team started with a set of default assumptions from their experience in the IoT industry. They know users will want to collect data, receive updates, control devices and visualize the data. So the questions revolve around collecting the information the code generator needs to make that happen, Driver said.

After the first two questions, users are asked what brand and type of sensor they’re using, and what they’re intending to measure. Other prompts include selecting how often they want to send the data to the cloud, the frequency of data updates and alert parameters.

“They’re all pretty simple,” Driver said. “None of them would give away the fact that, underneath, there’s a pretty involved process happening.”

The questions are tuned to save on wasted clicks that might deter or overwhelm a user, preventing them from finishing the process, Driver said. Each prompt must either reassure the user or fill in a critical code requirement.

In total, the onboarding can take anywhere from 15 to 30 minutes, and the resulting product supports most of the common types of IoT devices, including proximity sensors, industrial sensors, programmable microcontrollers and Bluetooth 5 multi-sensors.

Building the Framework to Allow Customization

What the user doesn’t see in the onboarding process is the framework that the engineers had to build to make it all happen.

To minimize the number of decisions made by the end user, Temboo’s team automated the generation of Kosmos’ core application code. This half of the code base acts like a bridge connecting the IoT sensors, the platform and the cloud, laying the foundation for everything the user wants to do, Driver said.

When the user goes through the onboarding process, they’re actually generating a batch of instructions for the core application. The instruction code latches on top of the application code and allows users to make changes to suit their particular use case.

Our customers are free to deploy however many sensors they want, which means the number of nodes under our control is constantly growing and shrinking.”

One of the biggest challenges to offering this kind of flexibility was accounting for unknown quantities of IoT devices. Unlike web or app builders, which just need to account for server space, Kosmos has no control over the number of devices a person uses — or when a user decides to add them. On top of that, a user can inadvertently flood the platform with too much data from a bad configuration and cause a DDoS attack.

“Our customers are free to deploy however many sensors they want, which means the number of nodes under our control is constantly growing and shrinking,” Driver said. “And the number of data points that are being sent to us is not something that we can know before they arrive.”

To protect users from errors, they built a kill switch into its code that allows a Temboo engineer to isolate the sensor flooding the system with data and toggle it off. They also added the ability to rewrite any part of the Kosmos code and send over-the-air software updates via the cloud.

This feature gives Temboo the ability to rewrite both the code running on the IoT devices and the operating system itself to keep it up-to-date with the latest features. If an internet connection goes down during the rewrite, the old code is recoverable and reapplied to prevent devices from becoming unusable, Driver said.

They also had to build in security parameters to protect users who may not be technically savvy from leaking their data. Early on, a lot of IoT security breaches occurred because people sent their data in plain text over the wire, Driver said. Kosmos integrated a MQTT communication line and cryptography algorithm to encrypt data and secure its connection to IoT devices.

Of course, none of those measures are visible to customers.

“That’s something a customer would never really think about, but it has to happen and it has to be invisible,” Driver said.

Feel the MusicHow Not Impossible Labs Translates Music for Deaf People

Thinking Carefully About Which Features to Support

From a hardware standpoint, Kosmos is designed to support every feature for each of the devices it’s capable of hosting. If they don’t, they either run the risk of locking a customer into a brand or breaking uniformity. While the code base is intended to be a unified system, the team has had to make it more complex to accommodate unique features across different devices.

But no-code technology isn’t limitless. Customers do have the opportunity to request unique features that the no-code system doesn’t generate, but Kosmos tries to push them toward the parameters they set.

One of the most common requests is real-time graphs, but Driver said his team reminds customers that they’d have to store all of that data and that they couldn’t even show all of the pixels on a screen. What they really want, most of the time, he said, is to be alerted when something happens.

Building a More Human No-Code System

But Driver acknowledges that there are limits to the no-code approach. Their platform is bound by the hardware they choose to support and those devices’ capabilities. That, in turn, limits the data it provides and what it can communicate to users.

It’s understanding what are the things you care about and how can you best represent that information.”

Driver said the next phase for his company will be to build a smarter no-code platform that places the sensor data into context for users. As it stands, there’s a gap between what someone is measuring and what they want to know. Take a sensor that is measuring water pressure in your home, for instance: The water pressure might not be what you really care about — the main point is to let you know if there’s a leak.

“It’s thinking in more human terms,” Driver said. “It’s understanding what are the things you care about and how can you best represent that information. It’s getting away from the obvious line graph style of displaying information.”

Seeds of GrowthHow Sprout Social Scaled Its Product Team