Why an IoT Pilot Project Does Not Always Scale and How to Avoid This Mistake

Why a pilot is not the same as scaling

A pilot tests a hypothesis, but it doesn’t always test the system. In a test area, the team often chooses the most convenient points: accessible premises, meters with a clear interface, areas with good coverage, a limited number of users, and manual control of each device. Under such conditions, it’s possible to quickly receive the first data and show a result, but it won’t fully address the various network scalability challenges.

When scaling, the conditions change. Devices end up in metal cabinets, basements, shafts, remote buildings, or facilities with an unstable signal. Different meter models appear, along with different sealing conditions and different access scenarios for installers. The number of events grows, integrations become critical, and manual checking of each point is no longer possible.

That’s why a pilot should not be a demonstration of the technology, but a test of the future industrial model for network capacity and device provisioning at scale. If the pilot does not check difficult points, installation rules, connection quality, data format, platform performance, and responsibility for maintenance, the project may show good results at the start but fail to withstand expansion.

Mistake 1. Launching a pilot without a clear business goal

One of the main reasons IoT projects stop is an unclear goal. The team installs devices, collects data, shows charts, but doesn’t answer the question of what problem the customer is solving at the business or operational level.

For a resource provider, the goal may be to reduce manual inspections, improve billing accuracy, detect tampering, reduce disputes, or receive regular data for billing. For a property management company, it may be monitoring basements, flooding, technical rooms, and emergency events. For a municipality, it may be creating a unified infrastructure for different services e.g., metering, monitoring, lighting, engineering facilities, or environmental sensors. For a developer, it may be improving a building’s operational readiness and reducing future costs for manual processes.

Before the pilot, a measurable result must be defined: how many points will be connected, what data should arrive, how often, where it will be sent, what actions are triggered by an event, and what effect is expected after scaling. Without this, the pilot can easily turn into a technical experiment that’s difficult to justify to the finance, operations, or management team.

Mistake 2. Choosing only “convenient” points for testing

If the pilot includes only points with good access and stable connectivity, the team will get an overly optimistic picture of IoT scalability. In a real project, difficult zones will inevitably appear, such as basements, thick walls, metal cabinets, manholes, rooms with high humidity, remote facilities, weak mobile operator coverage, or unsuccessful locations for installing base stations.

A proper pilot should include three types of points: typical, borderline, and problematic. Typical points show how the system works under normal conditions. Borderline points help determine where coverage reserve, an external antenna, a change of installation location, or a different transmission interval may be needed. Problematic points show where an additional LoRaWAN gateway, NB-IoT instead of LoRaWAN, a different device enclosure, a changed installation scenario, or a refusal to automate a specific point may be required.

When scaling IoT solutions for LoRaWAN-based projects, it is important to measure RSSI, SNR, the percentage of successful transmissions, retransmissions, and coverage reserve. For NB-IoT, the signal level and the stability of device registration in the network must be checked at the actual installation location, not only according to the operator’s coverage map. This is especially important for utility infrastructure, where devices are often located not outdoors, but inside buildings, cabinets, and technical rooms.

Mistake 3. Not calculating operations after installation

Because an engineer knows every device, checks missing data personally, exports reports themselves, and quickly responds to failures, a pilot can be supported manually. However, when the project scales, this approach stops working.

After launch across hundreds or thousands of points, it’s necessary to regularly monitor batteries, connection quality, missing data, base station status, tamper events, integration errors, updates, object directories, and user rights. If these processes are not described in advance, the IoT platform becomes yet another interface that has to be serviced manually.

The operational model must be designed before scaling. It should answer practical questions: who is responsible for device lifecycle management, maintains the gateways, responds to missing data, checks connection quality, replaces batteries, maintains the object directory, and is responsible for integration with billing, SCADA, or another system?

For municipal and utility projects, it’s also important to define which events are considered emergencies, when a field visit is required, and how quickly the team must respond.

Mistake 4. The platform is not ready for growth in the number of devices

During the pilot, a basic dashboard is enough: several devices, a map, a table of readings, and an event log. But an industrial deployment requires more. The platform must support object groups, user roles, filters, mass device onboarding, history, reports, notifications, export, API, and equipment status monitoring.

If the platform doesn’t help manage a device fleet, scaling sharply increases the manual workload. Employees start searching for problem points in spreadsheets, manually reconciling data, maintaining separate lists of installed devices, and separately tracking incidents.

For such tasks, Jooby projects can use Jooby RDC Dashboard — a platform for collecting, displaying, and processing data from metering and monitoring devices. The Jooby RDC ecosystem also includes LoRaWAN and NB-IoT radio modules, sensors, smart meters, and LoRaWAN gateways for water, gas, heat, electricity metering projects, as well as engineering infrastructure monitoring. 

The Jooby catalog includes devices for different resource types and connection scenarios, while Jooby’s integrator solutions are focused on connecting meters, sensors, the platform, and external systems into a unified architecture.

Mistake 5. Integrations are postponed “until later”

Many pilots stop after the first success, when data is arriving in the platform, charts are being displayed, and devices are visible. Why? Because this is when the customer asks the key question: how will this data get into billing, the dispatch system, SCADA, ERP, CRM, BI system, or personal accounts?

If integrations were not designed in advance, the project has to be rebuilt. It turns out that systems have different object directories, meter identifiers, data format requirements, and event processing logic. As a result, the IoT solution exists separately from the customer’s working processes.

To avoid this mistake, it’s necessary to define during the pilot which systems will receive data, in what format, how often, through which interface, and who is responsible for exchange errors. For some projects, an API or regular export is enough. Others require MQTT, webhooks, OPC UA, Modbus TCP, or an intermediate integration layer.

It’s also important to separate technical messages from business events. A dispatcher or operator does not always need the full data stream from devices. They need clear statuses: “meter is not transmitting data,” “battery needs attention,” “tampering detected,” “threshold exceeded,” “object requires inspection.” This logic makes IoT useful for operations, not just technically correct.

Mistake 6. Not accounting for lifecycle economics

The cost of a pilot usually looks acceptable: a small number of devices, limited installation, minimal integrations, and manual support. But scaling changes the economics. Additional costs appear for more devices, base stations, SIM profiles, installation, inspection of difficult points, battery replacement, support, staff training, integrations, and network maintenance.

If the cost of one point per year is not calculated during the pilot, the project may turn out to be more expensive than expected. This is especially important for municipalities and resource providers, where the system must work for years, not only until the result is demonstrated.

The calculation should include not only CAPEX but also OPEX. It’s necessary to understand how much it costs to connect one point, how the cost will change as the number of devices grows, how many field visits can be reduced, which processes can be automated, how often batteries will need to be serviced, and what integration support will cost. 

In IoT projects, real efficiency comes not only from buying devices, but from reducing manual work and increasing process controllability.

How to build a pilot that can scale

A pilot should be designed from the start as the first stage of an industrial deployment. This means that it must test not only connectivity and the device, but the entire future model: installation, data, platform, integrations, operations, and economics.

At the first stage, the site or territory must be surveyed. For a building, this means entrances, floors, basements, technical rooms, metering nodes, cabinets, and meter installation locations. For a district, it means residential buildings, heating substations, pumping stations, manholes, transformer substations, commercial premises, and municipal buildings.

At the second stage, representative points must be selected for the pilot. The pilot should include different types of meters, connection conditions, wall and cabinet materials, access levels, and several problematic locations. This will help identify real limitations in advance.

At the third stage, the architecture must be described: devices, sensors, radio modules, LoRaWAN or NB-IoT, server layer, platform, integrations, users, and operational processes. For Jooby solutions, such an architecture may include radio modules for meters, sensors for analog metering devices, smart meters, LoRaWAN base stations, and Jooby RDC Dashboard for collecting and further transmitting data.

At the fourth stage, success criteria must be defined. For example, the percentage of successful transmissions, acceptable level of missed data, event delivery time, data accuracy, battery life, number of problematic points, integration readiness, and expected reduction in manual operations.

At the fifth stage, an implementation standard must be fixed: installation rules, signal requirements, list of compatible meters, transmission settings, maintenance scenarios, user roles, report format, and integration scheme. After that, scaling should proceed in batches, with each zone checked and installation quality controlled.

What should be in the checklist before scaling

Before moving from the pilot to mass deployment, the team should have a short but practical document detailing their IoT implementation strategy. It should include:

1. Project goal and expected effect
2. List of objects and connection points
3. Types of devices, meters, and sensors
4. Results of the connectivity check
5. Problem zones and ways to solve these problems
6. Requirements for the platform and integrations
7. User roles and access rights
8. Event processing rules and action algorithm for missing data
9. Device and battery maintenance model
10. Cost of one point when scaling

Such a checklist helps determine whether the project is ready for expansion. If some items remain undescribed, it’s better to refine the pilot than to transfer unresolved problems to thousands of devices.

An IoT pilot project does not scale if it only checks the operation of the device rather than the readiness of the entire system. Data transmission in a test area and a convenient dashboard do not yet mean that the solution will withstand industrial IoT deployment challenges.

For a pilot to become the foundation of scalable IoT infrastructure, the real conditions of the future project must be checked in advance: connection quality, installation, meter compatibility, data correctness, the platform, system integration, operational processes, and lifecycle economics. 

The closer the pilot is to real load and the real object environment, the lower the risk that the project will stop after the demonstration, rather than achieving the aim of proof of concept to production.