The Device Is Not the Product

Someone offered me a project. Modernize an intercom system: camera, remote access, GSM. One engineer, me.

After the first call, I thought, ok this seems simple. Just connect a camera, add some remote controls, test with some buttons in my protoboard, and just like that, I have a system that captures images at a front door.

After the second call, I realized the project was looking more complex: I had to work with an ESP32, use GSM communication due to the characteristics of the current modules, and on top of that, it had to be connected to an app, where you can see the visitor, control the system remotely, manage users, create roles, and, probably in a second version, add a functionality to make calls. I started to feel overwhelmed.

New ideas kept. coming: how to store the data, how to save images and video, calls, logs—a server? Do they have a local server or a cloud one? So many questions started to pile up, and with the holidays approaching, I had to step back and accept that this is something a whole team should do.

Building an IoT System from Scratch

This was my first shock of reality. Maybe an embedded system is more than writing a few lines of C code, programming a microcontroller, and running tests in a controlled environment. That was the moment I had to step out of the cave and see that the IoT world is more than just firmware.

I wanted to see the full picture of building an IoT system from scratch, going beyond firmware and hardware decisions, to architectural, communication, power, visualization, and more.

That’s why I decided to build AirNode, a low-power environmental sensor that measures air quality in real time and streams data via Bluetooth and MQTT over Wi-Fi. This would make me walk through the whole system and also build something that will be useful for people. 

Air quality is important for everyone. Do you have a baby and live near a crowded street with a lot of cars and smog? Or do you live in an apartment building and have a smoking neighbor? These are some simple use cases, but the concept scales from personal use to industrial or agricultural applications.

The System Is Bigger Than the Device

An IoT device does not live alone. It has a flow that starts with sensor readings that need to be transmitted, processed, and displayed to the user. That alone forces you to start making real decisions — should I use Wi-Fi, BLE, LoRa?  Connectivity is a major architectural decision that affects several aspects of your system, and one of the biggest is power consumption.

Power is really important and needs to be considered. Everything changes when you use a device connected to a power source versus a device that is running on battery power. You cannot poll sensors or keep connections alive continuously if you are running on a couple of AA batteries. It is not going to last long. 

Continuing the flow, the next step is to think: how will the user interact with the system? A webpage? An app? Yes, an app. Apps are everywhere, and everyone wants to control everything just by taking a phone out of their pockets. Phones are our modern crystal balls. But an app is a whole entire separate world. 

This implies building a backend, because, besides visualizing data, you need to handle users, login, registration, roles, device status, and data flow. And on the app side, implementing Bluetooth in a mobile app is far from trivial.

This is where you realize: the device is not the product. 

To the user, the device is like a black box. They know it will be sensing, but the real thing is the user experience, having control of the device and being able to make decisions based on it.

Thinking Like a Product Builder

At this moment, I begin to think differently and to take my mind out of academia. Before, I was focused solely on the microcontroller, considering whether to implement bare-metal code or a system with an RTOS, running ideal tests in my lab, and uploading a demo to Instagram. But I never thought about whether it would work as a real product. 

Now, I am planning every step of development, knowing that there are many decisions that cascade across the entire system. From firmware, connectivity, power, backend, and the app, all of them affect how the device behaves and is used.

This is how you should think if you want your prototypes to become real products. Here are a few ideas that may help you along the way. 

First, define the whole system and make a product definition. I know you will have a bunch of ideas, but it is time to define them. For example, define a block diagram with inputs and outputs, then picture it out, separate it into modules, and write some use cases to give you the full picture.

Think in terms of decisions, not in implementation. Don’t focus on how to code it yet, instead focus on what to use and why. Choose connectivity, architecture, data flow; every decision has an impact, and like a wave, one move carries all the way through.

Don’t just test a separate module once you have something working. Instead, see how you can connect this with your phone or computer, see the info transmitted, and check the system end-to-end. You will be killing two birds with one stone.

What You Learn by Building the Whole Thing

Let's be honest—none of us were born knowing how to build a backend the way we know how to toggle an LED. You may not know how to develop an app, or you may not be an expert at designing your own UI/UX. Many of us have learned by following lab guides instead of solving real problems. 

That's exactly what makes projects like this valuable. You learn things you can only learn by doing. And in a few years, when you're leading a team of specialists — each one owning a different layer of the system — you'll have the experience to guide them well and make the right calls at every level.

Because you've already lived it, end to end.