A device should be small, inexpensive, communicate over long distances and run for a long time on a battery. These wishes often come together in a conversation about a new IoT product. They are understandable: you want to make something appealing and practical for your customer.

The difficulty is that the choices affect one another. More space can accommodate a larger battery or a better antenna arrangement. A higher sampling frequency can provide more useful information while consuming more energy. An additional radio connection can enable new functions, with further implications for design and testing.

A good design therefore starts with priorities. What performance does the user actually need, and where is there room to adjust?

Changing one requirement can affect the others. This is not a measured scorecard.

Make your requirements specific

Words such as small, cheap and real time sound clear, but give a development team little to work with. Small enough to fit in a pocket is a different requirement from small enough for a wristband. A daily location update is different from a new position every few seconds.

Start with the situation in which the product will be used. How often does someone need fresh information? When is charging possible? How should the device be worn or mounted? What selling price fits the value it delivers?

These questions connect technical choices to actual use. If the customer gains no benefit from an additional measurement, there is less reason to dedicate battery capacity, processing time and communication to it.

Battery life needs a defined usage pattern

A claim such as one year of battery life only means something when it is clear what the product does during that year. How often does it take a measurement? How much data does it transmit? How long does the device stay active, and how much time does it spend asleep?

For a tracker, the required update frequency can make a substantial difference. Constantly updated information calls for a different approach from a device that mostly sleeps and only transmits when an event occurs. The environment and connection quality can also affect consumption.

That is why I prefer to discuss battery life through a usage scenario. For example, you can define what the product does during normal operation and what changes when more information is temporarily needed. Then you need to measure energy consumption under representative conditions. Only then does a calculation become practically meaningful.

A small enclosure limits your options

I once spoke to an entrepreneur who wanted to make a tracker with an overall footprint of roughly one by one centimetre, including the battery. For the product they wanted, that was not a feasible starting point. The conversation then needs to focus on which requirement can change.

Miniaturisation is about space for the entire system. The electronics, battery, antennas, connections and enclosure all have to fit together and continue to work properly. You cannot allocate space to each component independently of the rest.

More room can make the design easier, but a larger chip is not automatically faster or better. The characteristics of the chosen component and the application determine its capabilities. What matters is how much freedom you have to position and combine the right components effectively.

The JOGO insole is a real example of electronics that must fit the way a product is worn

The JOGO insole is a real example of electronics that must fit the way a product is worn. The wristband example in this article is illustrative.

Choose connectivity around the application

Bluetooth, Wi-Fi, LoRa and cellular communication have different characteristics and dependencies. The first question is where the data needs to go and which infrastructure is available.

Can the device use a nearby phone? Is a suitable network available at the location? Does it need to transmit information independently when the user is elsewhere? The answers determine which solutions you should investigate further.

Combining several technologies can make sense. It may allow you to support different usage scenarios. At the same time, every extra function requires attention in the design, firmware and test plan. Add a connection because it supports a specific user need, and assess whether the additional complexity is justified.

Compare the consequences side by side

A child tracker in a small wristband is a useful example for explaining these trade-offs. Parents may want a comfortable size, expect up-to-date location information and want to charge the device as rarely as possible. First, you need to investigate which combination is technically and practically feasible.

Then discuss different usage scenarios. What changes if the position is updated less often? What does a slightly larger enclosure mean for comfort and the space available for a battery? Is communication through a phone sufficient for the intended application, or does the device need to work independently?

Compare the options using the same criteria: size, battery life, functionality and cost. A radar chart can make these priorities visible, provided the axes are clearly defined. Use measured or calculated values wherever possible. An attractive shape on a chart is not, by itself, evidence that a design is feasible.

Decide what is fixed and what is negotiable

A project can get stuck if every preference becomes a hard requirement. Distinguish between what is essential to the application and what would simply be attractive. That creates room to investigate alternatives while preserving the product's value.

Sometimes the desired combination does not fit the available budget or physical constraints. You then need to change direction or decide that the product does not make sense in its current form. That conversation belongs early in the process.

Rather than bringing a disconnected list of technologies to your first development meeting, describe what your user wants to achieve, in which environment and within which constraints. This allows us to investigate concrete design options and explain what each choice means in everyday use.

Discuss your next step

Describe the usage scenario in your first product development discussion. For a concrete miniaturisation example, see how we built the JOGO insole sensor.

Hardware design: size, battery life, performance and cost