So you have an idea for an Internet of Things (IoT) product. That’s awesome! But how do you build it? This article covers the basics.
First, you want to have a business case for your product. This may seem obvious, but it is surprisingly easy to miss. The business case is supposed to be what drives your idea: what problem are you solving, and for who?
Now you want to build it!
This article is our guide to how you should make your IoT product come true.
When we say IoT product, we mean a product or system that is connected to the Internet.
There are many reasons for making an IoT product. The most common are:
- The IoT makes an existing product better
- Develop a completely new product line based on IoT
- Add a new revenue stream - usually a service - on top of an existing product
These may be different motivations, but the plan is very similar.
All IoT products consist of hardware and software. Both of these will need to be tailored for your product,.
Development of an IoT product usually occurs in three phases:
In terms of the timeline, the proof-of-concept step may be as quick as a few weeks, but usually takes a few months. The actual time depends on the complexity of the product.
The prototype phase may be quick, or skipped entirely, if the proof-of-concept was successful.
Once production phase starts, the product can be in the market in a few weeks or months.
How to plan for your IoT product
Before we start the process, there are a few important choices that we need to plan for.
- What wireless technology to use
- What connectivity technology to use
- What cloud platform to use
- What smartphone apps or other software that is needed
These are ranked in order of importance.
Let’s start with the first one: what wireless technology to use.
Step 1: The wireless tech
The first step is selecting the wireless technology that is going to be used for the product.
This choice depends on how the product is going to be used:
- Smart city equipment, such as street lights, parking meters, or occupancy sensors? Choose a mesh network technology like IPv6 or low-data rate technology like LoRa. Can also use cellular systems like NB-IoT.
- Lighting equipment, such as emergency lights or industrial lights? Choose a mesh network technology.
- Electrical equipment, such as microgrids or power pole monitoring? Choose a mesh network technology. Cellular technologies can also work.
- In-door retail equipment, such as footfall sensors or occupancy monitoring? Choose a mesh network technology.
- Large-scale home equipment, such as electricity meters or water meters that are deployed in large buildings? Choose a mesh network technology.
- Medtech equipment, such as large-scale vaccine temperature monitoring? Choose a mesh network technology.
- Large-scale fitness tracking equipment, such as team tracking equipment? Choose a mesh network technology combined with Bluetooth for local read-outs.
- Personal equipment, that is used directly with an smartphone, such as fitness trackers? Choose Bluetooth.
- Smart home equipment, that is used both directly with a smartphone and via the cloud? Choose Bluetooth together with either WiFi, ZigBee, or Thread. For outdoor use, also consider mesh networking technologies.
At Thingsquare, we use mesh networking technology for all our customer projects because we believe it provides the absolute best bang-for-the-buck.
Mesh networking gives both long range and extensive coverage out of the box. It is really low-power. And hardware chips are readily available.
The wireless technology is difficult to change after the product is in the field. So it pays off to be thorough at this stage.
How do you know if you have chosen the right one? You build a proof-of-concept system.
More about this in the section about the proof-of-concept phase below!
Step 2: Connectivity
Almost every IoT product (with some exceptions) is connected to the Internet.
To communicate with its software. And that software is running in the cloud.
But the way that the product is connected to the Internet may be slightly different.
The actual connectivity technology does not matter too much. As long as it is an Internet connection, any technology will work.
The most commonly used connectivity technologies are:
- Cellular Internet (3G/4G/5G): this is just how your phone connects to the Internet. This usually works well, but may not work in deep in-door environments or if 3G/4G/5G connectivity is spotty in the deployment location.
- WiFi: if the IoT product is to be deployed in offices or homes, the gateway can be connected via WiFi. But not every customer wants others to connect to their WiFi networks.
- Ethernet: sometimes a good old Ethernet connection is available where your deployment locations are.
In addition to the technologies above, there are a number of low data-rate cellular technologies such as NB-IoT, LoRaWAN, and SIGFOX. Those technologies can be used to connect individual devices in remote areas, but they require a third-party infrastructure that may not always be in place.
Internet connectivity is much more wide-spread and available than low data-rate cellular.
Connectivity is relatively easy to replace as part of a second or third generation of your product.
The Thingsquare system works with both cellular, WiFi, and Ethernet connectivity.
Step 3: The cloud
Almost all IoT products have software running in the cloud.
The cloud is a collection of powerful computers that are running software. For an IoT product, most of the product’s intelligence sits in its cloud software.
The software can be hosted in different cloud providers. The most common cloud providers are:
- Amazon AWS
- Microsoft Azure
- Google Cloud
The different cloud providers have similar offerings in terms of the technology they provide.
But sometimes the choice of cloud it done because of business factors. For example, if you are directly competing with Amazon, you may not want to host your software in their cloud.
So then you choose another cloud provider.
Strictly speaking, it is not necessary to run your software in the cloud. It is technically possible to run the software on your own server, somewhere on the Internet.
But the cloud just makes life to much easier: it is easy to deploy, backup, and scale services when they are running on a cloud provider.
It is also relatively easy to switch cloud providers, so there is no need to sweat this decision at this point.
The Thingsquare system can be deployed in a range of cloud providers and we provide ready-made libraries to integrate with many of the cloud provider’s own services.
Step 4: Smartphone apps and other software
Almost all IoT products will be used through a smartphone app or a web frontend.
Most will also interact with some form of third-party software.
It may be as simple as a database that collects data from the devices. Or it could be a complex suite of integrations that hook into a suite of in-house business systems.
In either case, you will need to plan to develop new software to talk to your old software.
In terms of smartphone apps, you will almost always need an installation app.
The installation app is used by personnel to install the devices in the field. This is easy to overlook at the outset, but it has the potential to significantly reduce installation costs down the line.
It can also be the differentiating factor between your product and your competition.
Third-party software integration is best done at the cloud level. Just use any of the available APIs, and be prepared to have a team ready to develop the necessary integration code between your old systems and your new system.
It is easy to switch software after deployment.
Much easier than the previous steps we have discussed.
But this also means that requirements will change drastically over the course of the project. So budget accordingly.
With the Thingsquare system, we have ready-made smartphone apps that can take you all the way into the production phase without having to develop any software on your own. And integration APIs for third-party software integration.
How to develop your IoT product
So now we have an idea of the first steps in planning our product.
But how do we start actually building something?
We do it in three steps:
- Proof-of-concept. Purpose: demonstrate feasibility.
- Prototype. Purpose: demonstrate usefulness in the hands of your customers.
- Production. Purpose: bring the product to market.
The purpose is to de-risk the process as much as possible by:
- Testing the feasibility of the technical solution early
- Involving customers early
- Making sure that the business case holds
The steps above are often tied to investment. Investors will be more confident in our project if we can demonstrate progress quickly.
Speaking of investment, what is a reasonable to budget for all this? We have covered that in more detail here.
Step 1: The proof-of-concept phase
The purposes of the proof-of-concept phase are:
- Validate technology choices
- Validate the feasibility of the product
- Prioritize work for the prototyping phase.
This should be done as quickly and within budget.
Ideally, this means that it should be done without any custom hardware.
Because hardware is difficult and relatively expensive to develop. It is better to save this budget for the prototype or production phase.
That said, it is in general not possible to use everything off the shelf. Some development is needed:
- Add one or two custom pieces of hardware attached to an off-the-shelf hardware platform
- At least one smartphone app
- One web frontend
- Backend integration software
These should not be feature complete. But they should cover the most important points of your product.
Aim to do some early field trials with your proof-of-concept solution, to find out that the technology choices are sound.
At Thingsquare, we often work with off-the-shelf hardware platforms like the Texas Instruments LPSTK at this phase. Our software also provides mechanisms for measuring wireless range, power consumption, and other performance metrics to help determine feasibility.
This is what a good proof-of-concept may look like:
A proof-of-concept IoT sensor on a laptop in a recent retail monitoring project
At the end of the proof-of-concept phase, you should have a good understanding of the technology choices and their trade-offs.
As well as an idea of what was difficult and what was not.
Step 2: The prototype phase
If everything looks good after the proof-of-concept phase, it is time to dive into the prototype phase.
The purpose of the prototype phase is to:
- De-risk the production phase by developing custom hardware
- Doing large-scale field trials
- Validate the business case by getting feedback from early customers
The prototype phase usually takes longer than the proof-of-concept phase. Much of the reason for this is that development of new hardware takes time.
You will also need to flesh out the software.
Much of the software that was developed during the proof-of-concept phase will have to be thrown away and re-developed based on the new requirements from the proof-of-concept phase.
Ironically, this often leads to the results of the prototype phase looking worse than the results of the proof-of-concept phase.
The way to deal with this is to inform stakeholders, investors, and your team that this is to be expected.
This is what custom hardware developed as part of a prototype phase may look like:
Newly designed hardware usually does not look too inviting to customers.
Fortunately, there is a way to fix this: 3D printing.
With relative ease, 3D printing can turn off-putting hardware into good-looking devices that can be tested with customers.
Step 3: The production phase
The purpose of the production phase is to get your IoT product to market.
At the end of the prototyping phase, you should be certain that:
- Your product works in its intended target environment
- Your business case holds
So now you can step on the gas for the production phase.
The prototype hardware and software developed during the previous phases should be possible to use for the production phase.
But there are a bunch of new things that need to be done in the production phase:
- Manufacturing and production testing
- Device production mechanics
- Customer manuals and training material
- Smartphone apps
- Web frontends
- Sourcing hardware components
- DevOps: cloud software deployment and maintenance
DevOps, cloud deploument, web frontends, smartphone apps, and customer training material are not specific to the IoT. But they need appropriate skills on your team.
Sourcing of hardware components is also standard procedure for hardware manufacturing.
But manufacturing and production testing and production mechanisms are specific to the IoT.
Each device has a unique identity that needs to be synchronized with other backend systems. And each device needs to be flashed and tested as part of the manufacturing process, before they go to the customers. At Thingsquare, we do this with our ready-made manufacturing and production testing mechanisms that are tailored to each product’s requirements.
This article was first posted on the Thingsquare blog.