Crowdsourced Air-Quality Monitoring Using the FAVORIOT Developer Plan

1. Project concept

Malaysia AirWatch is a citizen-supported air-quality monitoring project. Schools, universities, community groups, businesses and individual volunteers install low-cost sensor stations at their locations.

Each station measures local air conditions and sends the readings to the FAVORIOT platform. The combined data appears on a public map showing air-quality patterns across Malaysia.

The project does not replace the Department of Environment’s official monitoring stations. It provides denser, neighbourhood-level observations that may help people identify local changes, pollution hotspots and unusual events.

The basic flow is:

flowchart LR
    A["Community sensor"] --> B["Wi-Fi or 4G"]
    B --> C["FAVORIOT"]
    C --> D["Quality checks"]
    D --> E["Public map"]
    D --> F["Alerts and analysis"]

2. Project objectives

The project should pursue five clear objectives:

1. Collect PM2.5 and PM10 data from many Malaysian locations.
2. Build a public community air-quality map.
3. involve schools, universities and citizens in environmental monitoring.
4. Detect unusual pollution patterns at neighbourhood level.
5. Create a national dataset for education, research and public awareness.

A good pilot target would be:

• 100 monitoring stations
• At least 10 states
• Urban, suburban and rural locations
• One reading every five minutes
• Six months of continuous operation
• At least 85% station uptime

3. Why the FAVORIOT Developer Plan fits

The current Developer Plan costs RM300 per month or RM3,000 per year. It includes:

• 500,000 API calls per day
• Unlimited devices
• Unlimited private and public dashboards
• Up to 30 widgets per dashboard
• Map widgets
• Device connectivity status
• Data import and export
• Edge Gateway
• Firmware OTA
• Advanced analytics and machine-learning models
• Email and Telegram notifications
• HTTP POST forwarding to external systems
• Customer accounts with designated access
• One-year data retention

These features make it suitable for a national crowdsourcing pilot. ⁠FAVORIOT pricing page

Estimated platform capacity

If each station sends one message every five minutes:

288\ messages\ per\ station\ per\ day

Theoretically, one Developer Plan can support about 1,700 stations at five-minute intervals. A safer operational ceiling would be around 1,300 to 1,500 stations, leaving capacity for testing, device management, retries and external applications.

4. Choose what the stations will measure

Required measurements

Every station should measure:

• PM2.5
• PM10
• Temperature
• Relative humidity

Temperature and humidity matter because low-cost particulate sensors can be affected by environmental conditions.

Optional measurements

Selected research-grade stations may also measure:

• Carbon dioxide
• Carbon monoxide
• Nitrogen dioxide
• Ozone
• Volatile organic compounds
• Atmospheric pressure
• Noise level

I would not put every sensor into the first version. Gas sensors can produce misleading readings without proper calibration. Start with PM2.5, PM10, temperature and humidity.

5. Build the standard AirWatch station

Recommended components

For locations without Wi-Fi, use:

• 4G LTE router or modem
• LoRaWAN gateway where local coverage exists
• Store-and-forward memory when connectivity is interrupted

Estimated hardware cost

These are planning estimates. The final cost depends on sensor model, enclosure, power and connectivity.

6. Define where sensors may be installed

Participants should place stations:

• Under a sheltered outdoor area
• Between 1.5 and 3 metres above ground
• Away from kitchen exhausts
• Away from cigarette-smoking areas
• Away from direct rain
• Away from air-conditioning outlets
• With unrestricted airflow
• Where the Wi-Fi signal is stable
• Where power is continuously available

The project should record the installation environment:

• Roadside
• Residential
• School
• University
• Industrial vicinity
• Commercial
• Rural
• Agricultural
• Coastal
• Forest-edge

Without this context, two readings may appear comparable when they are actually taken under very different conditions.

7. Create the FAVORIOT project structure

Create the following hierarchy in FAVORIOT:

Project

Malaysia AirWatch

Applications

• Community Air Quality Monitoring
• Station Health Monitoring
• Research and Analytics
• Public Air Quality Map

Groups

Groups can represent states:

• Johor
• Kedah
• Kelantan
• Melaka
• Negeri Sembilan
• Pahang
• Penang
• Perak
• Perlis
• Sabah
• Sarawak
• Selangor
• Terengganu
• Kuala Lumpur
• Putrajaya
• Labuan

For a larger deployment, create subgroups using districts or station categories.

Device naming convention

Use a consistent device ID:

MY-[STATE]-[DISTRICT]-[NUMBER]

Examples:

• MY-SGR-PUCHONG-001
• MY-JHR-JB-003
• MY-SWK-KUCHING-012

Do not use a volunteer’s name, house address or telephone number in the device ID.

8. Design the data payload

Each station should send a consistent JSON payload:

{
  "device_developer_id": "MY-SGR-PUCHONG-001@username",
  "data": {
    "pm1": 8.4,
    "pm25": 18.7,
    "pm10": 31.2,
    "temperature": 29.8,
    "humidity": 71.4,
    "latitude": 3.0321,
    "longitude": 101.6185,
    "location_type": "residential",
    "firmware_version": "1.0.0",
    "sensor_model": "PMS5003",
    "wifi_rssi": -63,
    "uptime_seconds": 86420,
    "quality_flag": "raw"
  }
}

FAVORIOT supports HTTPS, MQTT, WebSocket and CoAP for device connectivity. Each device can be given its own access token rather than sharing the account’s main API key. ⁠FAVORIOT platform documentation

9. Protect participant privacy

Exact household coordinates should not be displayed publicly.

Use two location levels:

• Exact coordinates: kept in the private administration records.
• Public coordinates: rounded or displaced by approximately 500 metres to 1 kilometre.

Public participants should see only:

• Station ID
• General area
• District and state
• Latest readings
• Historical trend
• Station status
• Sensor type
• Last update time

The registration form should explain:

• What information will be collected
• Which information will be public
• Who owns the contributed data
• How the data may be used
• How participants can withdraw
• Whether researchers may download the dataset

10. Develop the sensor firmware

The ESP32 firmware should perform these steps:

1. Start the particulate, temperature and humidity sensors.
2. Connect to Wi-Fi.
3. Synchronise the clock.
4. Allow the particulate sensor to stabilise.
5. Take several readings.
6. Remove clearly invalid measurements.
7. Calculate a short average.
8. Send the payload to FAVORIOT over HTTPS or MQTTS.
9. Confirm successful transmission.
10. Save failed readings locally.
11. Retry when connectivity returns.
12. Report station-health information.
13. Check for firmware updates.

Recommended sampling:

• Read sensors every 30 seconds.
• Calculate the median or trimmed mean over five minutes.
• Send one consolidated message every five minutes.

This reduces noise and consumes fewer API calls than transmitting every raw reading.

11. Test ten prototype stations

Do not immediately distribute 100 stations. Build ten prototypes first.

Place them in several conditions:

• Two beside an official or trusted reference station
• Two at universities
• Two at schools
• Two in residential areas
• One near a busy road
• One in a rural area

Run them for four weeks. During testing, check:

• Differences between units
• Humidity effects
• Missing data
• Sensor drift
• Wi-Fi failures
• Heat inside the enclosure
• Rain protection
• Firmware stability

Put all ten units beside one another for several days before deployment. This co-location test reveals whether one sensor consistently reads higher or lower than the others.

12. Create data-quality rules

Crowdsourced measurements require visible quality labels.

Suggested quality flags

Automatic checks

Flag a reading when:

• PM2.5 or PM10 is negative
• PM2.5 is far higher than PM10
• Temperature or humidity is outside plausible limits
• The same reading repeats for an unusually long time
• The value changes too sharply between intervals
• The station has weak connectivity
• The device clock is wrong
• Readings diverge greatly from nearby stations

A high reading from one low-cost station should be treated as a signal to investigate, not proof of a pollution incident.

13. Build the FAVORIOT dashboards

Public national dashboard

Include:

• Map of all active stations
• Latest PM2.5 readings
• Colour-coded air-quality categories
• National average
• Highest current readings
• State comparison
• Twenty-four-hour trend
• Last update time
• Explanation of the quality flags
• Clear non-regulatory disclaimer

State dashboard

Include:

• State map
• District comparison
• Hourly PM2.5 and PM10 trends
• Seven-day trend
• Active and offline stations
• Locations with unusual readings

Technical dashboard

Keep this private for administrators:

• Device connectivity status
• Wi-Fi strength
• Last message time
• Firmware version
• Sensor age
• Missing-data rate
• Battery or power status
• Stations requiring maintenance

Research dashboard

Include:

• PM2.5 versus humidity correlation
• Weekday versus weekend patterns
• Morning and evening peaks
• Urban versus rural comparisons
• Seasonal trends
• Anomaly detection
• Time-series forecasts

14. Configure rules and alerts

Create platform rules for:

Air-quality alerts

• PM2.5 exceeds the project threshold for three consecutive readings
• PM10 rises sharply within 30 minutes
• Several nearby stations detect the same increase

Station-health alerts

• No data for 20 minutes
• Device repeatedly reconnects
• Wi-Fi strength remains poor
• Sensor produces fixed values
• Firmware is outdated

Send technical alerts to the project team through Telegram or email. Avoid sending public health alerts until the measurements and interpretation method have been properly reviewed.

15. Recruit contributors

Potential participants include:

• Public and private universities
• Secondary schools
• TVET institutions
• Local councils
• Resident associations
• Environmental NGOs
• Makerspaces
• Technology companies
• Factories and industrial parks
• Farms and plantations
• Citizen scientists

Participation models

Sponsor a station

A company pays for stations to be installed at schools or community centres.

Build your own station

Universities, students and makers assemble a station using the approved design.

Host a station

FAVORIOT supplies the station while the participant provides electricity, Wi-Fi and a suitable location.

Research partner

A university supports calibration, analysis and publication.

16. Create the contributor onboarding process

Every participant follows the same steps:

1. Apply through an online form.
2. Provide the general proposed location.
3. Choose to build, sponsor or host a station.
4. Accept the data-sharing and privacy terms.
5. Receive a station ID and QR code.
6. Follow the installation guide.
7. Upload installation photographs.
8. Run the station for a seven-day probation period.
9. Pass the data-quality review.
10. Appear on the public map.

The QR code can open the public station page and display its readings, history and validation status.

17. Run a 12-week pilot

18. Pilot budget

Ten-station pilot

Internal staff time, travel across Malaysia and the development of a separate public web application would need their own allocation.

19. Success indicators

Technical indicators

• At least 85% station uptime
• At least 95% valid readings
• Less than 10% missing data
• Data delivered within ten minutes
• All stations remotely identifiable
• Firmware updates completed without visiting every station

Participation indicators

• Ten states represented during the first phase
• At least 20 partner organisations
• At least 100 active contributors
• At least five participating universities
• At least ten participating schools

Data indicators

• Six months of usable observations
• Verified co-location results
• Published data-quality method
• Monthly community air-quality reports
• At least three research or student projects using the data

20. How the project can grow

Phase 1: Ten-station technical pilot

Prove the sensor, firmware, platform and data-quality process.

Phase 2: One hundred community stations

Expand through universities, schools and resident associations.

Phase 3: Five hundred stations

Bring in local councils, corporate sponsors and environmental groups.

Phase 4: National operational network

Move to an Enterprise or dedicated arrangement when the project needs:

• Multiple administrative organisations
• Longer data retention
• Higher API volume
• Dedicated infrastructure
• Formal service levels
• Stronger data-governance controls
• Links with government or emergency systems

21. Important public disclaimer

The dashboard should carry a clear statement:

Malaysia AirWatch uses low-cost community sensors to provide local environmental observations. Its readings are indicative and may be affected by sensor accuracy, placement, humidity and maintenance. The data should not be treated as an official Malaysian Air Pollutant Index or used alone for medical, regulatory or emergency decisions. Refer to the relevant Malaysian authorities for official air-quality information.

Suggested project message

Your neighbourhood’s air should not be invisible.

Malaysia AirWatch allows schools, universities, communities and citizens to help measure the air around them. One sensor may tell us what is happening at one location. Hundreds of connected sensors can help us see patterns across the country.

Build a station. Host a station. Sponsor a community. Help Malaysia see the air we breathe.

The Gap Nobody Names Out Loud

Most final-year IoT projects die a quiet death. Not because the idea was bad, but because nobody mapped out what happens after the demo. A student builds a working prototype, presents it to a panel, gets a grade, and the device goes into a drawer. The organisation that could have used it never finds out it existed. This is not a motivation problem or a talent problem. It is a missing roadmap, and it is one of the more fixable gaps in how technical education connects to industry.

Favoriot has watched enough student projects go through this cycle to notice a pattern in the ones that do not die in the drawer. They tend to follow a similar four-stage path, whether the project is an environmental sensor network, a predictive maintenance tool, or a smart campus dashboard. Naming that path out loud is the point of this roadmap.

Stage 1: Classroom Foundation

Every real pilot starts as coursework, and that is exactly as it should be. The classroom stage is where a student gets comfortable with device provisioning, data streaming, and dashboard design on a platform that behaves the same way in production as it does in a lab exercise. A few things worth getting right at this stage:

• Build on infrastructure that will not need to be replaced later. Prototypes built on toy platforms usually get rebuilt from scratch the moment a real organisation shows interest, which wastes months of momentum.
• Document assumptions early, including what sensors were used, what data intervals were chosen, and why. These decisions get questioned again at the validation stage, and having a clear answer ready saves a lot of back-and-forth.
• Treat the grading milestone as a checkpoint, not an endpoint. A finished assignment and a finished product are two very different things, and conflating them is where most projects stall.

Stage 2: Site Validation

This is where a project either proves itself or reveals problems that never showed up in a controlled classroom environment. Moving a system onto an actual site, whether that is a factory floor, a farm, or a campus building, exposes it to conditions no lab can fully simulate: patchy connectivity, dust, humidity, or simply a device sitting somewhere nobody remembers to check on.

Favoriot’s role at this stage is largely about instrumentation and support. Project teams get help translating a working prototype into something that can run unattended on real infrastructure, along with monitoring to catch failures before they become embarrassing site visits. Validation at this stage usually answers three questions: does the system keep working without a student standing next to it, does the data it produces hold up against ground truth, and does it survive contact with an environment nobody designed for it.

Stage 3: User Feedback

A system that works technically can still fail completely if the people meant to use it never open the dashboard. This stage is easy to skip because it is less technically interesting than the previous one, but it is often where the most useful revisions happen.

Real users, whether that is a plant supervisor, a farm manager, or a facilities team, tend to ask for things a student would never think to build: a simpler alert threshold, a report formatted for a specific meeting, a mobile view because nobody at the site sits at a desk. Incorporating this feedback is what separates a project that impresses an organisation once from one that gets asked to stay.

Stage 4: Organisational Adoption

The final stage is where a pilot either gets absorbed into how an organisation actually operates or quietly winds down once the semester ends. Adoption depends less on the technology at this point and more on questions like who owns the system now that the student has graduated, what budget covers its continued operation, and whether it integrates with existing workflows rather than sitting beside them as a separate tool.

Projects that reach this stage successfully usually share a few traits:

1. A named owner inside the organisation, not just an enthusiastic contact who championed the pilot informally.
2. A clear cost picture, so continuing the system is a budget line rather than a favour someone has to keep asking for.
3. Integration with an existing decision, such as maintenance scheduling or resource allocation, rather than a standalone dashboard competing for attention.

Signals a Project Is Ready for the Next Stage

Not every project needs to rush through all four stages, and pushing one forward before it is ready usually backfires. A rough gut check for readiness at each transition:

• Ready to move from classroom to site: the prototype has run for at least a few consecutive days without manual intervention.
• Ready to move from validation to user feedback: the data being produced has been checked against a real-world reference and holds up.
• Ready to move from feedback to adoption: at least one real user has asked to keep using the system after the pilot period ends.

That last signal is worth paying attention to. It is a far more reliable indicator of readiness than any grade a panel could give.

Closing the Loop

None of this requires a student to become a business development team. What it requires is a roadmap that exists before the project starts, so momentum built in the classroom does not evaporate the moment the semester does. Favoriot supports project teams through each of these stages, from platform access through to the conversations that turn a pilot into something an organisation actually keeps running.

If a student, supervisor, or department has a project that feels ready to move beyond the classroom, reaching out costs nothing and usually clarifies which stage of this roadmap it is actually standing on.

Getting an IoT prototype to work feels like a major victory.

The sensor is collecting data. The microcontroller is connected. MQTT messages are flowing. The dashboard is displaying beautiful graphs. Perhaps an alert appears when a reading crosses a threshold. You demonstrate it to your lecturer, manager, customer, or potential partner, and everyone around the table seems happy.

Then someone asks the question that changes the entire conversation:

“Can we deploy this at our actual site?”

Suddenly, the prototype that looked complete feels like only the beginning.

I have seen this happen many times. A prototype proves that an idea is technically possible, but putting that same system into daily operation introduces a completely different set of challenges. Instead of one device sitting comfortably on a laboratory table, you may have dozens or hundreds of devices scattered across buildings, factories, farms, substations, rivers, water facilities, or remote locations.

This is the gap Favoriot is designed to help close.

The objective is simple:

Prototype → Real Site → Operational Pilot → Multiple Sites → Enterprise

Let me explain how to move through these stages practically.

Step 1: Start With the Operational Problem, Not the Technology

Before adding more features to your prototype, return to the original problem.

Ask yourself:

1. What problem are we trying to detect or prevent?
2. Who experiences this problem?
3. How is the problem being handled today?
4. What information is currently missing?
5. How quickly must someone know when something goes wrong?
6. Who should respond when an abnormal condition occurs?
7. What measurable improvement should the IoT system produce?

Suppose you have built a temperature monitoring prototype.

The technical description might be:

“Our ESP32 sends temperature readings through MQTT every 30 seconds.”

That is useful for developers, but it does not explain why an organisation should deploy it.

The operational description is much stronger:

“Maintenance personnel currently discover overheating equipment during scheduled inspections. Our system continuously monitors temperature and alerts them when abnormal conditions occur.”

Now we have a reason for the technology to exist.

Before putting your prototype into operation, make sure you can explain the operational problem in one or two sentences.

Step 2: Keep the Parts of Your Prototype That Already Work

Moving from prototype to operation does not mean throwing everything away and starting again.

If something already works reliably, keep it.

Your existing solution may already include:

• Sensors
• ESP32 or Arduino devices
• Raspberry Pi
• Industrial gateways
• PLC interfaces
• LoRa or LoRaWAN devices
• Cellular connectivity
• Wi-Fi
• Custom hardware
• Existing firmware

The question is not:

“How do we rebuild everything?”

The better question is:

“What is missing between this working prototype and an operational deployment?”

Very often, the missing piece is not another sensor.

It is the software and operational structure surrounding those sensors.

Your architecture begins moving from:

Sensor → Dashboard

towards:

Sensor → Device → Network → Favoriot → Rules → Dashboard → Alert → User → Action

That is a much more realistic operational architecture.

Step 3: Connect Your Devices to Favoriot

Once your hardware is working, the next step is to move the device data into a platform that can support the project as it grows.

Favoriot can provide the common platform layer between your devices and applications.

A simple architecture could look like this:

Sensors

↓

Microcontroller / Gateway

↓

Wi-Fi / Cellular / LoRaWAN / Network

↓

MQTT / REST API

↓

Favoriot

↓

Dashboard / Application / Alerts / Analytics

This means developers and system integrators do not need to build every software component themselves before putting the project at a customer site.

You can concentrate on solving the customer’s problem while Favoriot handles the IoT platform layer.

Step 4: Design for 100 Devices Even If You Currently Have Only One

A prototype normally starts with one device.

That is perfectly fine.

But operational deployment requires you to start thinking about a fleet of devices.

Imagine that your prototype monitors river levels.

Today:

• 1 sensor
• 1 ESP32
• 1 dashboard
• 1 developer

Tomorrow:

• 10 monitoring stations
• 20 sensors
• multiple gateways
• several users
• multiple dashboards
• different alert thresholds

Later:

• 100 monitoring locations
• hundreds of devices
• multiple districts
• different maintenance teams
• management dashboards
• external applications

The question therefore changes.

Instead of asking:

“Is my sensor sending data?”

you need to ask:

• Which devices are online?
• Which devices have stopped sending data?
• Which device belongs to which location?
• How frequently should each device report?
• What happens when communication is interrupted?
• Who can access each dashboard?
• How long should data be retained?
• Which applications need access to the data?
• What happens when we add another 100 devices?

You do not necessarily need 100 devices today.

You simply need to avoid designing something that becomes impossible to manage when the project succeeds.

Step 5: Turn Sensor Data Into Operational Information

Connecting devices is only the beginning.

Consider this reading:

Temperature: 67.3°C

Interesting.

But what should someone do with it?

An operational system needs context.

For example:

• Normal operating temperature: below 50°C
• Warning level: 50°C to 60°C
• Critical level: above 60°C
• Current reading: 67.3°C
• Equipment status: Critical
• Required action: Maintenance inspection

Now the data means something.

A practical operational flow might become:

Sensor detects abnormal condition

↓

Device sends data

↓

Favoriot receives the reading

↓

Rule identifies abnormal condition

↓

Alert is generated

↓

Responsible person receives notification

↓

Maintenance team investigates

↓

Problem is resolved

This is where IoT starts becoming operationally useful.

Step 6: Build Dashboards Around People, Not Sensors

One common prototype mistake is putting every available measurement onto a dashboard.

Temperature.

Humidity.

Voltage.

Current.

Battery.

Signal strength.

Timestamp.

Device ID.

Pressure.

Flow rate.

Everything gets a graph.

It looks impressive during a demonstration. Unfortunately, the person operating the system may have no idea where to look first.

Instead, design dashboards according to roles.

For technicians

Show information such as:

• Device status
• Current readings
• Battery level
• Communication status
• Recent alarms
• Sensor history

For operations managers

Show:

• Number of active sites
• Current abnormal conditions
• Unresolved alerts
• Site performance
• Historical trends
• Response status

For senior management

Show:

• Major operational exceptions
• Performance indicators
• Downtime trends
• Operational risks
• Cost or resource implications

The dashboard should answer one basic question:

“What do I need to know or act upon right now?”

Step 7: Add Useful Alerts Before Fancy AI

There is often pressure to put AI into everything.

I would resist that temptation at the beginning.

First, make sure the organisation can reliably detect simple abnormal conditions.

For example:

• Temperature exceeds 60°C.
• Water level reaches a dangerous threshold.
• Electricity consumption suddenly increases.
• Pressure falls below normal.
• A device has stopped transmitting.
• Battery level becomes critically low.
• A pump operates longer than expected.
• A machine starts behaving outside its normal operating range.

These may appear simple, but they can solve very expensive problems.

Once sufficient operational data has been collected, more advanced analysis can become useful for detecting patterns, forecasting problems, identifying anomalies, or supporting decisions.

The sequence should normally be:

Collect → Monitor → Alert → Understand → Predict

rather than:

Prototype → AI

Step 8: Put It Into One Real Site

Now comes the important part.

Take the prototype out of the laboratory.

Choose one real operating environment.

Do not immediately deploy across 50 locations. Start with somewhere small enough to manage but real enough to expose problems.

At the site, test things that laboratory demonstrations rarely reveal:

1. Connectivity
   • Is Wi-Fi reliable?
   • Is cellular coverage sufficient?
   • Are there dead zones?
2. Power
   • What happens during outages?
   • Can devices restart automatically?
3. Sensors
   • Are readings stable?
   • Does weather affect them?
   • Do they require recalibration?
4. Hardware
   • Can enclosures handle heat, rain, dust, or vibration?
   • Are cables properly protected?
5. Users
   • Do people understand the dashboard?
   • Are alerts meaningful?
   • Are there too many notifications?
6. Operations
   • Who responds?
   • How quickly?
   • What happens after an alert?

You will probably discover things you never expected.

Good.

That is exactly why the real-site stage exists.

Step 9: Turn the Real-Site Test Into an Operational Pilot

There is an important difference between testing whether technology works and proving whether the technology solves an operational problem.

A pilot should have measurable outcomes.

Do not define success as:

“Twenty sensors successfully transmitted data for three months.”

That proves connectivity.

Instead, measure things such as:

• Reduction in manual inspections
• Faster detection of abnormal conditions
• Faster response times
• Reduced downtime
• Reduced energy consumption
• Reduced water losses
• Reduced equipment failures
• Better maintenance planning
• Fewer unnoticed incidents

For example:

Before Favoriot

Technicians inspect equipment manually every four hours.

After deployment

Equipment is monitored continuously and maintenance personnel receive alerts when abnormal conditions occur.

That tells management why the project matters.

Step 10: Prove the Business Value Before Expanding

This stage is often forgotten.

A technically successful pilot does not automatically become a commercial project.

Before asking the customer to expand, build a simple business case.

Document:

1. The original problem
2. How the problem was previously handled
3. What was deployed
4. What Favoriot monitored
5. What abnormal conditions were detected
6. What actions were taken
7. What improved
8. What money, time, resources, or risks were reduced
9. What expansion would cost
10. What the organisation gains from expansion

The objective is to move the conversation away from:

“The technology works.”

towards:

“The organisation benefits from using it.”

That difference can determine whether your pilot ends with a presentation or continues into a real project.

Step 11: Expand Carefully

Once the pilot proves operational value, you have evidence to justify expansion.

A sensible progression is:

1 Prototype

↓

1 Real Site

↓

5 Sites

↓

1 Department

↓

Multiple Departments

↓

Organisation-wide Deployment

↓

Multiple Locations

At each stage, learn before expanding again.

Do not simply multiply the number of sensors. Improve the operating model as well.

Ask:

• Who owns the system?
• Who maintains the devices?
• Who receives alerts?
• Who handles technical support?
• Who manages users?
• Who reviews performance?
• Who decides when more sites should be added?

Technology can scale quickly.

Organisations usually scale more slowly.

Plan for both.

Step 12: Move Towards Favoriot Enterprise When the Project Requires It

As deployment grows, organisations may require more control over their IoT environment.

The conversation may expand into:

• Enterprise deployment
• User management
• Data ownership
• Security requirements
• Custom dashboards
• API connections
• Existing enterprise applications
• Multiple sites
• Larger device fleets
• On-premise requirements
• Internal operational workflows

At this point, Favoriot can become part of the organisation’s wider operational architecture rather than simply the platform used during prototyping.

The progression becomes:

Favoriot for Prototype

↓

Favoriot for Pilot

↓

Favoriot for Department

↓

Favoriot for Organisation

↓

Favoriot Enterprise

The important point is that you do not have to make this jump on day one.

Grow the architecture together with the project.

Step 13: For System Integrators, Build What Makes You Valuable

Many system integrators may hesitate to enter IoT because they believe they need their own large software development team.

You do not necessarily need to build an IoT platform yourself.

Your strengths may already be elsewhere.

You can focus on:

1. Customer relationships
2. Understanding the customer’s operational problems
3. Site surveys
4. Sensors and hardware
5. Connectivity
6. Installation
7. System configuration
8. Industry knowledge
9. Training
10. Support and maintenance

Favoriot can provide the IoT platform underneath the solution.

This creates a simple partnership model:

You own the customer. You understand the problem. You deliver the solution. Favoriot powers the IoT platform.

Instead of spending months building platform functions, your team can spend more time winning customers and solving their operational problems.

The Complete Prototype-to-Operation Checklist

Before moving your prototype into operation, ask whether you have completed these steps:

Problem

• Have we clearly defined the operational problem?
• Do we know who experiences it?
• Do we know what improvement we want?

Technology

• Are the sensors reliable?
• Is the hardware suitable for the actual environment?
• Is connectivity reliable?
• Can devices recover from failures?

Platform

• Are devices connected to Favoriot?
• Is data structured properly?
• Can devices be managed as the deployment grows?

Visibility

• Are dashboards designed for actual users?
• Can users quickly identify abnormal conditions?

Alerts

• Have meaningful thresholds been defined?
• Does the correct person receive the alert?
• Is there a clear response process?

Pilot

• Has the system been tested at a real site?
• Has it operated long enough to expose practical problems?
• Have actual users tested it?

Value

• Can we measure operational improvements?
• Can we show what time, cost, effort, or risk has been reduced?
• Is there a business case for expansion?

Scale

• Can we move from one site to multiple sites?
• Who owns and maintains the system?
• Is there a plan for enterprise deployment?

If you cannot answer some of these questions yet, that is not necessarily bad news.

It simply tells you what needs to happen next.

A Simple Favoriot Path From Prototype to Operation

If I had to reduce the entire process to one practical roadmap, it would be this:

1. BUILD

Create your working IoT prototype.

↓

2. CONNECT

Connect the devices to Favoriot using MQTT or REST API.

↓

3. SEE

Create dashboards that show what is actually happening.

↓

4. ALERT

Define conditions that require human attention.

↓

5. DEPLOY

Install the system at one real site.

↓

6. LEARN

Observe hardware, connectivity, data, user, and operational issues.

↓

7. PROVE

Measure whether the system solves the original operational problem.

↓

8. EXPAND

Move from one site to several sites.

↓

9. OPERATE

Establish ownership, maintenance, alerts, support, and operating procedures.

↓

10. SCALE

Move towards departmental, organisation-wide, or Favoriot Enterprise deployment.

Your Prototype Is Not the Finish Line

There is something satisfying about watching the first sensor reading appear on a screen.

For developers, students, researchers, and engineers, that moment feels like success.

And technically, it is.

But I have learned that the bigger opportunity begins after that moment.

The question is no longer whether we can connect a device.

The question becomes whether we can turn that connected device into something an organisation depends on every day.

That means moving beyond sensors and dashboards towards operational visibility, alerts, actions, measurable outcomes, and a system that can continue working when the developer who built the original prototype is no longer standing beside it.

This is where Favoriot wants to help developers, researchers, startups, universities, and system integrators cross the difficult gap between “It works” and “We use it every day.”

So if your prototype already works, resist the temptation to keep adding features simply because you can.

Take it somewhere real.

Connect it.

Test it.

Break it.

Fix it.

Measure what changes.

Prove its value.

Then scale it.

Your prototype works. Now put it into operation.

If you have an IoT prototype sitting in your laboratory, office, university, or workshop and you are wondering how to move it to a real site, share your biggest challenge in the comments. I would be interested to hear what is stopping your project from taking that next step, because sometimes the most difficult part of IoT is not building the prototype. It is making sure the prototype gets the chance to become something real.