How to make an IoT prototype: Your guide towards building hardware electronic products


How to make an IoT prototype: Your guide towards building hardware electronic products

Hardik Shah
in Internet of Things
- 35 minutes

This article is going to be more about building IoT prototyping and help your startup or team to get there properly. But, if you need help tackling the complexity of mapping user needs as a product manager, here’s an amazing read by Daniel Elizaldale.

Hardware is difficult!

Even though cliche, I wouldn’t understate the difficulties here. IoT products often fail because of:

  • Underestimating product development
  • Ignoring complexities that comes with manufacturing on a scale
  • Poor QA
  • Too many features

With this blog post, I am going to help you with a proper technical product development for the Internet of Things. This may not seem like a really big deal to you now, but this is exactly how I helped non-tech founders and enterprises adopt IoT in a really large scale – without risks!

Why prototype when you can build a product?

Developing IoT products is like any other product development process, but, with the exception of 3-4 technologies working together. This makes building IoT products the right way extremely important.

You can’t simply just build a spec of features, functionalities and sensory capabilities that you want, send it to a manufacturer and get your product built. No matter how simple your product is, when it comes to IoT, you have to test your idea for hundreds of parameters to see what you are building is right.

To make it easy for you to understand why IoT products fail, take a look at the comic strip I made below:

If you don’t prototype and directly go to production, be ready to face the following consequences:

  • Your product wasn’t market validated, and nobody needs it
  • Your product doesn’t work in the targeted environment
  • There is a market for your product, but requires modifications and multiple iterations. You end up spending more and more capital to manage and cope up with the iterations. It might become infeasible for you after sometime.
  • Your product is technically bad, and pivoting technically would cost you earth now

For the sake of clarity, let’s break down IoT product development into the folllowing stages:

  • Idea
  • PoC
  • Prototyping
  • DFM (design for manufacture)
  • Production

I like making things simpler, so the comic strip below actually shows how to approach confusing IoT product development:

Approaching IoT product development step 1

Cost breakup of these stages that typically go into IoT product development:

Idea: Takes 1-2 months, costs $5k
PoC: 1-3 months, costs $15k
Prototyping: 6-8 months, $150k
Design for Manufacture: 3 months, $60-90k
Production: For 500 to 1000 units, around 2 months and approx $60k

A good way to get a realistic pricing of your product in retail is to multiply the unit cost by a factor of 4. This factor comes into the picture as you’ll have to pay for distributors, retailers, payment processing feeds and some(occasional) refunds.

Tip #1: You now know the timeline, stages and rough cost estimates around these stages. Download the diagram below, print it out and scribble it with your rough ideas. Even better if you print multiple copies, you can jot multiple/alternative ideas that way as well.

Once you have done that, let’s move down to the next stage.

How do you prototype IoT devices? (The complexities)

Technical jargon aside, generally you need the following components to prototype IoT devices:

  • A development board
  • Few sensors
  • A communication module
  • Wires to connect everything
  • A battery or a direct power source

We will go into extreme details of these, but let’s first evaluate the most important thing – IoT environment. As someone who has spent thousands of hours understanding thermal sciences, fluid motion and machine movements I can’t emphasize on this enough.

Tip #2: Let’s now shape your idea a bit more. In an excel sheet or a note, add all of the components that you think you would need to build this prototype.

Now, we have your timeline and components listed, but how would you make sure that your components are well suited for your needs? To better assess that let’s go through stages of temperature sensing IoT device and the environmental considerations involved in it.

IoT environment considerations in prototyping

Let’s take the case of building a simple temperature sensing IoT device. It may seem simple as a lot of work has already been done on the subject, but depending upon the following factors the performance of your prototype could vary significantly:

  • How your device has been exposed to heat: Convection, conduction or radiation?
  • How’s the fluid movement around the exposed sensor node?
  • Impact of localized/restricted environments when you are trying to measure the global temperatures or global humidity?
  • If the device is directly exposed to direct radiation(image direct sunlight falling on it when you are just trying to measure the room temperature. Which in this case would be very different)
  • Deposition of ice/dust or other materials on top of the sensory interface. It can significantly alter the readings
  • If you are trying to measure temperature, what should type of temperature to actually measure? Wet bulb temperature or dry bulb temperature?
  • What if your environment exceeds the high or low tolerance range of your sensor
  • Is the device hazardous to your environment? For example, a device using more than 5 Volts in a flammable environment could easily spark ignition.  

Note how a very simple sensory problem has expanded into 8 different dimensions – even while we were doing a very generic evaluation. This is the minimum level complexity that we usually see in IoT products. The complexities are ten folds higher in most cases.

Here’s an illustration of how to logically select an IoT sensor

IoT prototyping challenges: Environmental considerations

A good idea would be to think of your environment and then listing down anything that can create an issue.

Note: Understanding your environment could be extremely important when you are working through the prototyping phase. It can lead to building better product and help solve real customer problems. A lot start with their vision, neglecting the hard reality that your hardware (unlike software) is going to interact with real-physical world. That could mean, ice falling on top of your sensors, a layer of mud on top of it or device getting placed in a coldest corner of the storage room.

It can be difficult, you don’t know what elements you need to select

Often for people who are not from technology backgrounds might find it difficult to put together specs for their prototype. With this guide, I will try to make IoT prototyping extremely easy for you, doesn’t matter who you are or what you technology background is.

Hang this on your wall

Here’s an amazing way to structure your thoughts and shape them to build an IoT prototype. Given the complications involved in IoT product development, it helps you clearly list risks, benefits and shows how various parties involved can better leverage a new connected hardware.

IoT prototyping framework

IoT prototyping/product roadmap

Before we get into details of IoT components that are used for prototyping or building initial specs for your products. I would highly advise you to go through this roadmap first. I would go as long as saying that a lot “product roadmaps” that people use, are for software type services where the cost of MVP related failures are easy to compensate for(relatively).

A real product roadmap for Internet of Things should be significantly focused on technology part. Sprints, scrum all have their own place, but do not downplay on technology roadmaps. I have seen too many that come from a software dev background and ended up burning themselves. Hardware is not software, there are very few pivots possible.

IoT prototyping roadmap image

Since, we are not going to talk about end hardware design in this post, I have kept it focused on your hardware prototyping needs.

Let’s now see common architectural setup of these prototypes to make you even more familiar with what you are building.

General IoT prototype architecture

The two figures below best illustrate IoT prototypes architectures in general. I am using the word architecture, as it this representation has seemed to overshadow what most product managers and IoT leaders think architecture is. I would prefer to call this as a model. 

IoT device general architecture that communicates directly with cloud

IoT device cloud architecture

IoT device and gateway network architecture

This is a different architecture where devices can not only talk to a gateway, but it also shows the mesh paradigm that your IoT product call follow as well. You can further drill this architecture down to ecosystems of Edge, Fog and even MIST computing as well. Here’s a good in-depth introduction to IoT edge computing if you want to read deeply. I wrote a blog covering Edge, MIST and Fog computing covering when, where and what purposes these different IoT models serve.

IoT mesh, edge, mist, fog architectures

Before reading this section, you knew that your device had:

  • A sensor
  • Environmental characteristics that it would be exposed to

Now, you know that your IoT device can communicate in two ways:

  • Device to cloud directly
  • Device to device, device to gateway and then to cloud

That gives you even more opportunities to think through and refine your IoT idea in multiple places.

In the next sections we will get into what has actually revolutionized connected tech: Dev boards and communication protocols. Dev boards make it extremely easy for you to prototype at literally no expense and in weeks as opposed to months. Communication protocols on the other hand makes it extremely easy for us to connect almost everything. 

What hardwares are available for you to prototype (what can you do with them)

This is pretty difficult to cover, but I will try to list as many common hardware development boards as possible here. I am trying to bring in diversity of use cases that you should consider when you are prototyping.

Dimensions are definitely something that you can use to decide which dev boards are the best fit for you. And, I’ve made this graphics so that you can refer to the dimensions of common IoT devboards and actually compare if they fit for your usage:

IoT prototyping dev board compare size

Bosch XDK

Based on ARM Cortex M3, this hardware development kit was specifically focused on enterprise grade prototyping. It has a few built in sensors for rapid prototyping purposes, has a rechargeable battery and has a form factor of 60mmx400mmx22mm (length, width, height). It has been built to support indoor and outdoor environments.

From Blockchain based solutions to an enterprise grade firmware, this kit is everything you need.

Raspberry Pi

Once considered a hardware for kids to play, is now world’s most used development kit for IoT devices. From Electric vehicle charging systems to Industrial gateway prototypes, a lot of people are using it to prototype their products. Raspberry Pi is flexible, and allows you to code in Python, C, Java and even some high level languages to make prototyping really easy for you. It has a lot of pins for you to be easily able to plug in your sensors, integrate it with a system to push and output etc.

Also, if your product needs a local server, you can practically make one using RPi by simply running Django or equivalent on top of it.

Raspberry Pi 3 and Raspberry Pi zero came out with Wifi and BLE support in built so that you won’t have to add anything extra to get the same level of connectivity. Raspberry Pi requires an SD card to work, this SD card would also contain an operating system that helps your Raspberry Pi to function.

If you are planning to utilize camera, Raspberry Pi has Pi Cam. 

IoT developers love Raspberry Pi and it is a fantastic tool to get all the way to product grade IoT. However, I would warm you that since it uses an external microSD card, it often fails for use cases where you have to frequently read, update and store data on the SD card. You would end up being frustrated by the number of times your SD card gets corrupted. If I have no other dev board as a choice, I usually add an external storage via USB to the Raspberry Pi and make SD card a read only source. That reduces the read/write cycles on Raspberry Pi and prevents SD card corruption.

I recollect talking to a client who was planning to use a Raspberry Pi for indoor location tracking was convinced that RPi is the ultimate platform for building IoT prototypes. After a meeting he realized that Raspberry Pi doesn’t have an appropriate antenna. The ceramic antenna of RPi wasn’t able to capture beyond 5 meters. That takes us to the next dev board.


To extend the range of this client, I moved them to nRF DK based boards. Here’s antenna design were so amazing that we were able to extend that range to 15-20 meters with minute errors in location tracking. In fact, if you are building a BLE based IoT prototype, I would suggest you checkout nRF first and see if it has everything that you need or not. They also bring in BLE 5.0, IoT mesh networking stack to the table as well.

nRF also provides nRF 52832 that makes it very easy to simulate a Beacon-gateway type relationship without much of work needed. There are some minor bugs in the mesh networking SDK that nRF provides, but for most of the part it works really well.

ThunderBird Sense 2 from Silabs

So far we have only spoken about dev boards that has one or two communication protocols in it (Wifi and BLE). ThunderBird on the other hand is a multi-protocol dev board. It is really easy to get started with, you can expect to get started as soon as 1 week with your IoT prototype ready.

The quality of build would be very high and the form factor is considerably low. If you are looking for BLE, Zigbee and  other communication protocols in a dev board without bloating your form factor, this dev board is for you then.


This IoT board was built by designers to make electronic prototyping extremely easy. Unlike a Raspberry Pi (which is a full fledged computer), Arduinos are dev boards with microcontrollers that have limited amount of processing power and memory. They run loops of function that you embed in them. Similarly to Raspberry Pi they have a lot of pins that you can use to push output to other devices or receive input as well.

They are very easy to program and support C as they programming language. Some modifications support MicroPython, i.e. a framework for writing code on Arduino type boards using Python.

Pretty much everything you need to communicate or sense would need to be integrated externally with Arduino.

Arduino and Raspberry Pi have been supported by a really large dev community that makes it easy to consume open source contributions for your prototype.

When I see hardware development kits, at present people are only concerned about sensing capabilities with little focus on responses and interactions. The future won’t be just about simpler interactions and responses, it will be about taking a step further and actually be able to respond to situations based upon what a device senses.


Can you believe that every 4th Kickstarter campaign launched for IoT products actually uses an ESP8266 module? Crazy, right?

Personally, I don’t find ESP8266 reliable enough, but the ease of getting started with it and building a prototype in just a matter of hours is an incentive for anyone else to try it out. It is cost effective, has certifications in place to make your prototype a non intentional radiator. And if you are okay with a couple of resets on your prototype a day.

MSP430 LaunchPad Kit

MSP430 launchpad kit is an ideal dev board for industrial grade prototyping, it comes with a TI based MSP430 microcontroller. They are not very friendly for those that are just starting with IoT prototyping, but for someone who has decent experience of building such prototypes would be easily able to get started with MSP430 dev boards.

IoT development boards like Particle are worth mentioning here as they are not only extremely easy to program and build your prototype. They also come with a cloud solution that is extremely easy to integrate with your IoT prototype. With their cloud solution in place, you won’t have to assemble a team of developers just to have a cloud backend for the prototyping phase. You can continue iterating with their cloud solution till you hit a bottleneck or product validation, you can then think of getting someone onboard to create a custom cloud solution.


To get near to the end product as much as possible, I often personally prefer to use STM32’s module. It is extremely low cost, runs barebones code – basically any engineering enthusiast’s needs. However, prototyping with STM32 can get extremely time consuming and expensive for new to mid level developers. But there are times when my barebones code written on STM32’s dev board went to initial level custom PCB prototypes as a firmware with extremely minor modifications.

There are many more dev boards that I wish I could include here, but that would become a book. I might consider updating this blog post in future or even write a new post to add a detailed review.

Here’s a very light comparison of IoT prototyping boards by peformance

IoT dev boards by perfomance

OS of prototyping dev boards

So, any IoT development board can be categorized into three types based on OS:

    • Bootloaders: They are not operating systems. They are simply platforms that provide you to run your IoT code endlessly on a loop(event loop) and perform functions that you define within your code.
    • Non-real time operating systems(non-RTOS): With such IoT OS, you get to execute some functionality with speed, but it is not real time. Most Linux distributions like Raspbian (The one that runs on top of Raspberry Pi) falls into non-RTOS category. Android is another example of such operating systems, and is fast gaining popularity within IoT and Robotics’ ecosystems.
    • RTOS: These are real time operating systems, they have been sharply optimized to deliver real time communication to critical parts. Anything that slows down or could fatally paralyze a solution is removed from the picture to create such solutions

While RTOS was something that was impossible on tiny IoT devices not so long ago. RTOS is now expected to power small scale devices as well. Keep a watch if your IoT prototype needs such capabilities.

If you really want to understand the difference read forward, else, skip the tiny section on IoT operating systems.

IoT Operating systems

How bootloaders work?

This is what a bootloader looks like.

IoT device bootloader

Your IoT code will be executed endlessly here on an infinite loop. And, there’s very little functional access that you have here. Plus, it really depends on the hardware vendor as well on what type of access they would really give you. Some don’t even give access to storage.

How operating systems work?

When you use an operating system for your IoT device, things get a bit more complicated (for good reasons!).

You get to create modules, define user access, setup admin controls and what not. IoT OSes these days aren’t any different from the operating systems you are using. We even have Windows 10’s IoT version.

The diagram below better illustrates what an OS entails:

IoT operating system (non real time)

How real time operating systems(RTOS) work?

Here’s a very detailed blog post around RTOS and RTOS comparison for IoT devices and needs. Incorporating an RTOS within your IoT product is focused around stripping of unnecessary components that you don’t need, prioritizing processes and placing controls to make sure that your hardware device is not just fair, but 100% reliable.

Here’s what a workflow of a typical RTOS is like

IoT real time operating systems

In case if you don’t know, the other systems that we build are “fair”, not reliable – that’s the main difference RTOS brings in for mission critical IoT products. Any software that you use and lives on a cloud is “fair” not what we can categorize into mission critical reliability. The best example to cite reliability is airbags in your vehicle.

Breaking down IoT hardware requirements

Breaking down hardware requirements into electronic components can be difficult. But, here’s a simple list of bullets for you to get started:

  • How complex is your requirement?
  • How much RAM would you need?
  • How many peripherals are you going to use?
  • What about the power supply?
  • What’s your use case?
  • On what language are you going to write the firmware?

If it seems too overwhelming for you to break your IoT requirement and select a hardware board let me make it a bit more easy for you. Selecting a development board for your IoT prototype shouldn’t very difficult for you.  

How complex is your IoT need?

Do you need a simpler loop to run around and check for a sensor input? Or, do you need something more complicated that can have two way feedback loops?

In the first case, you can pretty much do it with any microcontroller based board like Arduino, Linkit One, Particle, etc. But, if you need something more complicated, you would definitely have to pick up a board with that has a microprocessor in it.

I will break down IoT boards by high and low complexity needs. There are boards that can push and receive information, process it and act on top of it. And, then there are boards that can only carry out minor functions.

How much RAM would you need?

Let’s say if you are trying to build an IoT prototype with 1 or 2 sensors (not including the camera), you won’t need a lot of RAM. For example, an Arduino comes with KBs of RAM to handle all operations, and you would be surprised to see how well it can handle 2-3 sensors.

I was recently working on an IoT project, where it required us to have a local server even during the prototyping phase and required something that could bring in more processing to run a full scale application on an IoT device. We had to select between Raspberry Pi or BeagleBone Black. We went with Raspberry Pi due to some very niche reasons. But you get the idea, right? If you are expecting an Arduino UNO type board to handle this much processing, it isn’t possible.

The image below shows prominent dev boards for IoT and RAM they have:

dev boards


How many peripherals do you need?

If you are going to have 15+ sensors or if you are planning to build a gateway with a multi protocol support, you would need a dev board that can these many peripherals and has multiple input output pins with it.

IoT developers that have more experienced with IoT prototyping and are shaping industrial prototypes, STM32 might seem like a viable solution, but they are limited by the number of Input outputs (or I/Os). With STM32, you get to add on a few peripherals (sensors, inputs, output, interfaces, etc).

The image below would paint a better picture of what I am talking about here:


How much power do you need?

Peripherals consume power, do you have it?

Let’s make this extremely easy to understand, assuming that a sensor or switch would incur 0.3V voltage drop across it. Common small scale batteries provide a 5V power supply. That also means, that if you have 15 components (not including resistors), you get a 3V power drop. We have not even included microcontroller here yet.

A microcontroller would consume anywhere between 1.8V to 2V. That means, you system is already energy deficient. For you to be able to validate your idea, you need to get your core features tested properly. But, if your board isn’t going to work properly, how are you going to do that?

In case, if you don’t already know this, there’s something called a Brownout voltage. If you don’t power your board properly, it will start behaving irrationally. You could face issues like:

  • Firmware upload and update not happening
  • Highly inaccurate sensor readings
  • Device failing to connect with GSM type services

I have listed only some of them, but, there are literally like 100s of them out there. Even if you aren’t technical, this should your utmost priority to check and ensure.

You still need more power

If you are planning to use a GSM or GPS module, that would be power hungry. The moment your battery can’t supply more than 1A of current, your IoT device would stop connecting. Most external GSM modules require external battery power during prototyping phases. Make sure that you account for all of these

How long do you need this power?

Battery based power dies sooner or later. The question you need to address here is that how much battery life you need with you IoT product? If you want 5-10 years worth of battery, you need to switch to low power protocols like Lora, Sigfox or mid-level power consuming protocols like Zigbee if you are okay with a battery life of 2 years.

I am not going to talk about AC or DC power here, it is safe to assume that you have already figured out.

[Add details on 15+ sensors would be difficult to manage with 5V power supply, add details on protocol connectivity and power connection, add details on external power that is often needed to power GSM modules]

What’s your use case?

Think about simplicity when building a prototype, write clean code and do the same while selecting a dev board. Make list of possible features that you might want and map it with a reputable dev board for the sake of simplicity.

Not all dev boards are built equally

Not all boards are built equally, I remember working with this popular dev board from Mediatek(Linkit One). The prototype wasn’t just unreliable, it lacked library support, the hardware performance wasn’t smooth and for some reason USB powered testing won’t work unless you are running this board in a dev mode. The same USB that provided 500mA of current worked fine while you run it in a dev mode, but won’t work when you aren’t working in a dev mode. Weird isn’t it, required 4 days of testing and multiple emails back and forth to figure out. We initially selected this dev board as it had almost everything, Wifi, GPS, BLE, GSM, etc inbuilt. But it later turned out to be a poorly supported hardware.

Your device’s environment

You can easily create a prototype out of Arduino, thermal stability, electromagnetic interference, and poorly design components could easily give up under these situations. There are IoT dev boards manufacturers like Texas Instruments, Silabs, Bosh XDK, etc that manufactures dev boards keep extreme conditions in mind.

What language does your dev board supports?

We have talked about this before, different dev boards would support different programming languages, make sure that you select one that you or your dev team is comfortable with.

Microcontroller or microprocessor?

To make this very simple, you can simply decide dev boards between those that have a microcontroller or those that use a microprocessor. All you need to do decide is to see how complex is your need?

If you need an IoT device that can run a full scale app(has admin controls, multiple roles, etc), go for a microprocessor. But, if you need to carry out simpler operations, you can easily work your way through a microcontroller.

Speaking from my own experience, 80-90% of all requirements don’t need a microprocessor. So, if you directly jumped on a conclusion to use a microprocessor, you might need to dive a bit more deep.

I will cover this in even more details in a future blog post on microcontroller vs microprocessor illustrating exact use cases and scenarios.

Designing your power supply

I usually divide power supply into two types:

  • Direct AC/DC
  • Battery based power supply

The choices are pretty obvious, I don’t think there’s any need for me to get into any details here. I will rather go into more details on what type of battery based power supply is available to power your IoT devices.

Here are some of the common battery types in use for IoT devices:

  • Lithium Manganese Dioxide (Li/MNO2): Useful for a single use scenarios
  • Lithium ion(Li-ion) : Rechargeable but have a large form factor
  • Lithium ion polymer (Li-po) : Rechargeable and compact batteries

There are other Nickel and Cadmium based batteries, but they are mainly to be used with hardwares that require a lot of power to operate. For most of the IoT use cases, you would never require such high power.

Here are some of your power supply options: 

IoT sensors for prototyping, where and when can they be used?

If you are building your prototype with a plan in mind, each and every week counts. While testing your prototype you would want to minimize the number of variables that are affecting the business use case.

Quality and suitability of a sensor for a particular use case is something that you should always keep on top of your mind. But, there are many vendors that push sensors like DHT11s as the most imperative sensor technology for temperature sensing – and you would only realize that once you have spent weeks building a prototype and wasted efforts and capital on testing it with your target audience.

There are sensors for each occasion, they have their own range, they own benefits and limitations towards a situation. The section that proceeds below will help you pick up a sensor based upon a situation and use it in your prototype.

IoT protocols for prototyping, how they(devices) should be connected?

There are many ways in which you can connect your devices when you are prototyping. The following protocols enable IoT connectivity:

  • BLE (Bluetooth low energy)
  • Zigbee
  • Lora and Lorawan
  • Thread
  • Sigfox
  • NB-IoT
  • Cellular
  • Wifi

The protocols I listed above are either extremely developer friendly, innovative or popular. There are many others like IP6 based mesh protocols for device to device connections, but they are used in very niche use cases.

How can you select the best IoT protocol?

During the prototyping phase, selecting the right protocols could save you a ton of time, money and potentially product threatening pivots. My simple rule for assessing a protocol is by:

  • How many devices are going to be connected to my IoT product?
  • How much will the protocol stack cost me post prototyping phase?
  • What’s the level of support available? How developer friendly is this community?
  • Does it actually fits my use case? [capabilities, data transfer rate, battery life, etc]
  • How would I be able to handle information transfer between IoT devices (or IoT to phone/cloud)?
  • Am I going to push firmware over the air in this product?

Talking about these things at such a high level isn’t really helpful. So, let me dig into my own experience and bring in some real case studies here to show you how you can practically apply this rule.

How many devices are going to be connected to my IoT product?

Protocols limit to what extent can you connect to another devices. I remember a client that came to us with their BLE enabled devices that were pushing out temperature values of different shelves located in a vicinity. Their goal was to build a solution where use can move through a shelved room with 20+ BLE devices bonded with a mobile app sending their temperature values of these shelves.

The followed the usual hardware development process where they first created a proof of concept using hardware development kits, and tested everything with a real customer. They tested this solution with 1-2 temperature sensing devices that pushed data to a smartphone. Everything was great, the customer validation was correct. They eventually raised funding as well.

But, when the first batch of manufacturing was delivered, this was the first time when they actually tested 20+ of these devices together, only to find out that BLE 4.0 has a limitation where they couldn’t connect to more than 7 devices together. This almost killed their product!

Luckily, BLE 5.0 was just around the corner, and we were able to make minor modifications to make sure that connecting to more than 20 BLE devices was no longer an issue.

How will this protocol stack is going to cost?

Ideally, when people are prototyping, they don’t think about costs associated with buying a protocol. But, do you know that even using “Bluetooth” in your product makes you liable to pay a licensing fees of $8,000? A lot of people don’t account for this when they start with a prototype. 

As an alternative, would you prefer to use a pay per subscription service like Sigfox?

Or, would you consider open source protocols like Lora. Using them into your product is extremely cost effective. But, again, that might not be something that is a great fit for your use case.

Whatever you do, choose wisely!

What level of support is available? How dev friendly is this protocol?

So, here’s the thing about technology and product development – pick up a technology choice that’s just simple. If you pick something up that’s not so simple, your startup can die just because of the complexities involved.

When Lora was a newly introduced protocol, we had a project where we could only use this technology as the competitor Sigfox wasn’t in that US location at all. I remember, scooping through Semtech’s forums for weeks for even tiniest bit of information. This was incredibly frustrating as I wasn’t actually solving an engineering challenge, but trying to find out simple bits of information like the details on the Link Layer.

Picking up something that has no level of support can be extremely daunting for your IoT project. So, choose wisely and balance innovation with risks.

Does it actually fits my use case?

Often device connectivity in itself is critical to pass the prototyping phase. Take BLE based asset tracking solutions for example, if you are unable to improve location tracking accuracy, you are sure that you won’t be able to pass the prototyping phase.

In the case of asset tracking, the location error tolerable during prototyping phase is 2-3 meters.

I often look at data throughput as another parameter to assess whether a protocol is suitable for a particular use case or not. Check how much transfer rate and bandwidth you would require, and see whether the protocol supports that or not.

Battery life and range (even capabilities to extend it) are good parameters to assess a protocol. Let’s you that you are trying to extend the range using an external antenna, you should be able to assess SoC’s or repeaters that can actually help whether you can do that using a particular protocol provider or not.

With most BLE gateways, you can simply add another external BLE antenna to increase the range. And with solutions like Sigfox you would be limited to what range you can get by default. Even though the range is pretty great (10-15 miles), you won’t be able to extend it. But, you can easily extend NB-IoT and others via repeater and other extensions.

Firmware Over the air(OTA) updates

Secure OTA is becoming the backbone of maintainable IoT products. You need that within your IoT products too! Select a protocol, make sure that they do support secure OTA updates by default. When I talk about secure OTA updates, I mean controlled releases, with signed and encrypted firmwares transported to your IoT devices via mobile or gateway or Cloud.

I feel that I have taken BLE in a lot of my examples here, but since a lot of startups and organizations use it to build IoT connectivity, I think it worth keeping it here.

Back in 2017, I was a part of an IoT project where we had to manage secure OTA from an iOS app to an nRF52 based prototype. We have a ton of experience doing things like these, hence we were easily able to customize nRF52’s bootloader, encrypt and sign firmware on the iOS app and securely remove the old firmware from the dev board and update nRF52 with the new one. This is now officially supported by nRF52 with their new SDKs. But, imagine being a startup with little experience, trying to build through the day and test it with customers to fail faster. You would end up spending way more precious time doing the wrong things, if you don’t select the right protocol.

Some IoT prototyping challenges

After spending years into building IoT products and moving large scale organizations/startups to

  • Power optimization
  • Sensor reading accuracy
  • Electronic shielding
  • Taking control over networking
  • Multiple ecosystems working together(mobile, web, hardware, networks)
  • Using the right libraries
  • Communicating with multiple devices at the same time

I am just listing these challenges here at the moment, but each and every of them are a really huge topic in itself. And, I am going to write detailed blog posts covering all of these topics.

Soldering the prototype, beware of voltage drops

If you are using perfboards or solderable dev boards, keep a note that for every soldered part you are going to face a voltage drop. Here’s how a typical soldered prototype looks like

Soldering in an IoT breadboard prototype


I have also marked a few soldered junctions where one could face voltage drops in red.

This may seem extremely easy just from the looks of it, but one of the most frustrating part of the prototype development. I often seen prototypes that are soldered so poorly that initial requirements either indicate a business failure or the need to overcompensate in terms of BOM.

But, if you just follow these two things you should be able to make sure that your prototype is built with proper soldering:

  • Use the right soldering paste and material
  • Measure the voltage drop across each and every soldered point. If required remove the solder paste and add it again. Do it till you feel that there’s no significant voltage drop here.

IoT cloud services: Custom or prototyping?

To build a cloud service either for IoT device or for capturing analytics, we have a range of options to select from. We have premade cloud services providers like Ubidots, Xively, etc and then you have custom cloud platforms like AWS, Azure, and many more.


Identifying the best fit for your IoT product is pretty straightforward.

Pre made cloud backendsCustom Cloud providers
Plug and play, making it extremely simple even for the DIY enthusiasts. Expensive if there are even considerable amount of IoT devices presentRobust, highly customizable and inexpensive

How do you actually write a code on these hardware development kits?

When it comes to code deployment on these hardwares, most dev boards will allow you to upload the code via a USB port. In other cases, you would end up using something like an STlink to upload your code where it isn’t possible to do so via USB.

Let’s make this even simpler with me walking you through the process of me writing a code for Arduino UNO.

First, let’s get your Arduino dev board ready. You do that using a special USB connected called “USB A to B”. One part of this cable gets connected to the Arduino, and the other USB interfaces gets connected to your PC/laptop.


Usually in case of most dev boards, USB can deliver required current to power them. As soon as you do this, a few LEDs would light up on your Arduino. Which means that you can now write your IoT firmware in it.

The next step would be go on and download IDE(or the software you need to write the firmware). In case of Arduino, we use Sketch IDE.

Arduino firmware upload

The code that is written above blinks an LED interfaced with Arduino on a PIN #13. As soon as we hit the arrow on the top left, this could would get transferred from your PC to your Arduino. That’s it, that’s how simple the entire process it.

For deciding on the power source you have three options. I have discussed them before: USB powered, Direct power supply and batter based power supply.

USB based power supply is usually delivered using USB A to B cable

Below is how you power an Arduino using a battery

IoT device power through battery

And, here’s how you connect an Arduino to a direct power supply


Ardiuno IoT direct power supply

Seems pretty simple and straightforward, isn’t it?

Let’s move on to the size of your prototype, where I’ll show you how you can reduce the size of IoT device that you are building. This is often required to make prototyping as close to the end hardware without spending a hundred thousand dollars on it.

Reducing the size of IoT prototypes

Often people start with Arduino and Raspberry Pi for the start, only to learn that the form factor is actually too big for them to test it in a target environment. We normally either look for smaller dev boards that fits this form factor, or we remove devboards all together in some of these use cases.

A year ago we were working with an supply chain leader that wanted to build a temperature sensing prototype. As we moved further and iterated with the project to develop something more precise, I knew that none of the dev boards would be able to deliver what we needed at that time. So, as a next step of prototyping we moved on to a perfboard based prototype that had all components, but with a significantly reduced form factor.

Here’s a perfboard based prototype in the image below. See how selective we can get with identifying what elements to keep, what not to keep etc and the best part is that there are no zillion pins on it.


Reduce IoT prototype size with perforboards

I will end the blog here, but I plan to add rest of the information in multiple other blogs and books.

And if you have been able to follow the blog post till now, you should be 95% close to understanding what exactly you need to do in your IoT prototype and how to better drive your IoT product development. If that’s not the case and you feel that you are stuck somewhere, feel free to reach out to me at

Hardik Shah

Working from last 8 years into consumer and enterprise mobility, Hardik leads large scale mobility programs covering platforms, solutions, governance, standardization and best practices.

IoT development popup

I write highly actionable, practical tips from my experience of building large scale IoT products. Join my mailing list to know everything you need to build a successful IoT product for any level of complexity. 

- Parikshit, Lead IoT and Data Science at Simform

You have Successfully Subscribed!