The IoT Builder’s
Field Notes
A practitioner’s companion to Mastering IoT & AIoT with Favoriot
Inside this companion
A companion, not a repeat.
The original book gave you the ladder. This companion gives you the thinking behind each rung — the questions I wish someone had asked me, the mistakes I’ve watched smart people make, and the mental models that changed how I build.
Every chapter here is independent. Every chapter is new. Read them in order, or jump to the rung where you’re standing right now.
Before you read: four honest questions
- When someone asks you to explain IoT in one sentence, do you reach for jargon to buy time?
- Do you know the difference between IoT and AIoT — not the acronyms, but the actual capability gap?
- Have you made even one real decision in the past month using sensor data you collected yourself?
- Could you sketch the five layers of an IoT stack on a whiteboard right now, without Googling?
Here is the honest thing about awareness: it is the most common rung, and it is the rung where people spend the most time going in circles. Not because IoT is complicated. Because the fog of buzzwords creates the illusion that understanding it requires a PhD or a six-figure budget. It does not require either.
The fog is the product of vendor marketing, conference theatre, and well-meaning engineers who cannot stop themselves from skipping straight to architecture when you ask them what IoT actually is. I have been guilty of all three at different points in my career.
The one-sentence test
The fastest way I know to test whether someone truly understands a technology is to ask them to explain it in one sentence to someone who has never heard of it. Not a LinkedIn sentence. A real one. If they cannot do it, they are not past awareness.
My one sentence: IoT is a system that connects physical things to networks so their real-time data can drive real decisions automatically. That is the whole thing. Everything else — protocols, gateways, edge computing, AIoT — is elaboration on that sentence.
“The fog of buzzwords creates the illusion that understanding IoT requires a PhD. It does not. What it requires is one honest sentence and the courage to say when you do not yet have it.”
— Dr. Mazlan AbbasThe AIoT distinction that actually matters
People ask me constantly: “What is the difference between IoT and AIoT?” Here is the distinction I use, and it is not technical. IoT answers the question “what is happening right now?” AIoT answers the question “what should we do about it — and why?” That is not a marginal upgrade. That is the difference between a monitoring system and an intelligent system.
The five-layer sketch that changes everything
Before I ask anyone to pick a platform or buy a sensor, I ask them to sketch the five layers on paper. Devices. Connectivity. Platform. Applications. Security. If they cannot label all five, we start there. The sketch does not need to be detailed. It needs to exist in their head, not just on a slide deck someone else made.
Layer 1 · Devices
Sensors, actuators, and microcontrollers that sense and interact with the physical world. This is where data is born.
Layer 2 · Connectivity
Wi-Fi, cellular, LoRaWAN, NB-IoT. The network layer moves data from where it is born to where it can be stored and processed.
Layer 3 · Platform
The middleware that ingests, manages, rules-checks, and stores device data. This is where most IoT projects get the decisions wrong.
Layer 4 · Applications
Dashboards, alerts, and intelligent applications that turn stored data into decisions and visible outcomes.
The real reason awareness stalls
I have watched hundreds of professionals hover on Rung 1 for months. The cause is almost never lack of intelligence or resources. It is that awareness without a use case feels like studying for an exam that has no date. The moment you attach IoT to a specific outcome you care about — reduce downtime by 20%, detect water leaks within five minutes, lower energy costs by 15% — the fog clears almost instantly.
The use case is not a destination. It is the flashlight. Without it, you are walking in a warehouse with the lights off.
Ready to climb to Rung 2? Three gates.
- You can explain IoT to a non-technical colleague in one sentence without hesitating and without jargon
- You can sketch all five layers of an IoT stack on any surface, from memory, clearly enough that someone else could explain it back to you
- You have named one specific outcome in your own work — not a technology, an outcome — that an IoT system could measurably improve
The foundation questions no vendor will ask you first
- Do you understand why most IoT projects fail — and can you say it without blaming the technology?
- Have you written down what an IoT platform must functionally do for your specific use case before looking at any product?
- Have you honestly calculated what building a platform in-house would cost across three years, including maintenance and the inevitable rebuilds?
- Do you know where vendor lock-in hides — and have you asked the four questions that reveal it before signing anything?
The most expensive rung is not Rung 4, where production infrastructure costs real money. The most expensive rung is Rung 2, because the mistakes you make here are structural. They echo for years. I have seen companies rebuild entire IoT architectures eighteen months into production because someone chose a platform based on a demo that looked impressive. The demo always looks impressive.
The real causes of the 90% failure rate
Every serious study puts the IoT project failure rate between 75 and 90 percent. Most commentary blames technology. That is wrong. The technology works. What fails is the thinking that precedes the technology — and specifically, these six patterns I see repeat across industries and geographies without exception.
Starting with a device, not an outcome
Every failed project I have reviewed began with a hardware decision before the business problem was articulated. “We bought 200 sensors” is not a project. It is a warehouse problem waiting to happen.
Treating the POC as the finish line
Twenty-three percent of IoT projects die at the POC stage. Not because the POC fails — because it succeeds in the lab and no one planned for what real-world deployment actually requires. The POC is a hypothesis test, not a product launch.
Underestimating the true cost of in-house builds
Building your own IoT platform feels like a strategic investment. It is almost always a strategic mistake. The infrastructure cost is visible. The ongoing maintenance, the security patching, the engineer retention, the scalability rewrites — those compound invisibly until suddenly they are not invisible at all.
Ignoring vendor lock-in until it is too late
Lock-in does not announce itself. It hides in closed APIs, proprietary data formats, export restrictions, and hardware-to-cloud dependencies. By the time you feel it, you are eighteen months in with a system that cannot talk to anything you did not buy from the same vendor.
Measuring the wrong things
Devices online is not a business metric. Data ingested is not a business metric. If you cannot connect your IoT system to revenue, cost, risk, or operational efficiency within thirty days of deployment, you are collecting data, not creating value.
Building for the engineer, not the decision-maker
The person who approves the budget is not the same person who can read a technical dashboard. If your system does not produce decisions that a business owner can act on within seconds of looking at it, your system is incomplete regardless of its technical elegance.
The four questions that expose lock-in
Before buying any sensor, gateway, or platform component, I ask four questions. If the answers are unclear, I walk away. Every time I have ignored this rule, I have regretted it.
Question 1
Can I send data via MQTT or REST? If the answer requires a proprietary SDK or a closed hardware stack, that is your first red flag.
Question 2
Can I access my raw data easily and export it freely? You do not own a platform if you cannot get your own data out of it without a support ticket.
Question 3
Can I connect this to any other platform or system I choose? Openness is not just a feature preference. It is a business continuity requirement.
Question 4
What happens if I want to switch vendors in eighteen months? The answer to this question reveals more about a vendor’s confidence in their product than any sales deck ever will.
“Flexibility today is freedom tomorrow. The best IoT platform is not the most feature-rich one. It is the one that grows without punishing you for the decisions you make today.”
— Dr. Mazlan AbbasWhat a platform must actually do
Before evaluating any platform, write down your functional requirements without looking at any product. Not features — requirements. What must the system do to solve your specific problem? Most teams skip this step and end up reverse-engineering their requirements from whichever platform they saw demonstrated last. That is evaluation by accident, not by design.
| Capability Area | Build In-House | Hyperscaler (AWS/Azure) | Dedicated Platform (Favoriot) |
|---|---|---|---|
| Time to first deployment | 3–12 months | 1–3 months | Days to weeks |
| Long-term maintenance cost | Very high | High + egress fees | Predictable subscription |
| Hardware flexibility | Custom-built | Limited | Any device, any protocol |
| IoT-specific features built-in | Build everything | Partial | Complete out of box |
| Lock-in risk | Internal dependency | ✗ High | ✓ Open APIs |
Ready to climb to Rung 3? Three gates.
- You can state, without hedging, why most IoT projects fail — and the answer is not “the technology did not work”
- You have written your functional platform requirements before evaluating any vendor product
- You have a clear and documented answer to why you are not going to build the platform yourself
The hardest thing about methodology is that it is boring. That is also why it works.
Every team I have worked with that skipped the four-week rhythm paid for it later. Not always in catastrophic failure — sometimes just in the slow erosion of momentum, credibility, and budget that comes from building the wrong thing at the wrong pace for the wrong user. The rhythm is not exciting. Shipping is exciting.
Method check: before you build anything
- Can you state your project’s intended outcome in one sentence — not what it will measure, but what decision it will change?
- Have you identified the smallest data set that proves the outcome, rather than the most comprehensive data set possible?
- Do you know how the data becomes a decision — including who makes it, how fast, and what happens when they do not act?
- Do you have real users committed to a real deployment in a real environment — not a lab simulation?
The teams that ship IoT projects in one month and the teams that spend eighteen months not shipping have almost identical technical skill. The difference is discipline about sequencing. What happens in week one determines what is possible in week four. The teams that try to do weeks two and three simultaneously with week one never finish anything worth finishing.
The four-week rhythm
I have used this rhythm across smart city deployments, industrial monitoring projects, environmental systems, and student capstone projects. It is not a methodology I invented — it is a compression of what the successful projects had in common and the failed ones did not.
- Name the decision that must change
- Identify who makes that decision today
- Define what success looks like in numbers
- Map the stakeholders who must be aligned
- List only data that drives the target decision
- Define collection frequency and accuracy needs
- Identify data gaps and dependencies
- Set ownership and governance rules early
- Define thresholds and alert conditions
- Design the action chain: alert → who → what
- Set automation vs. human-in-loop boundary
- Build the feedback loop for continuous learning
- Go live in real environment, not the lab
- Validate data accuracy against known baselines
- Confirm alerts trigger correctly
- Measure adoption: do users trust it enough to act?
The question every week must answer
At the end of each week, the team answers one question. Not “did we complete the tasks?” — that is a project manager’s question. The question I care about is: “If we stopped right now, does the user have something that changes a decision?” Week one: they should have clarity. Week two: they should have relevant data. Week three: they should have a working trigger. Week four: they should have a working system trusted by a real user.
“Data without action is just noise. The right data at the right threshold, triggering the right response for the right person — that is when IoT earns its seat at the operational table.”
— Dr. Mazlan AbbasThe three starter patterns for builders at Rung 3
If you are building your first real system, do not invent a new project category. Start with one of these three patterns. Each is small enough to finish in four weeks and complete enough to teach you everything you will later use at scale.
Environmental Monitor
ESP32 with temperature, humidity, CO2, and air quality sensors feeding a Favoriot dashboard with threshold alerts. Real enough to deploy in a classroom, office, or factory floor. Complete enough to teach every layer of the stack.
Mini Weather Station
Multi-parameter sensing via LoRaWAN or 4G, connected to the Favoriot cloud platform with location-tagged dashboards. Used in flood early warning, smart agriculture, road monitoring. The gateway pattern that every city-scale system builds on.
Smart Pole
A multi-service urban infrastructure platform: smart lighting, environmental monitoring, surveillance, and EV charging on a unified data backbone. The integration challenge that teaches you everything the single-sensor projects do not.
Why the threshold is “a real user, a real decision”
The threshold to move from Rung 3 to Rung 4 is specific for a reason. Not a demo. Not a slide. A real user acting on a real decision because of data your system produced. That threshold matters because it is the first time you discover what your users actually need as opposed to what you assumed they needed. Every production project I have seen succeed has passed this gate. Every one that stalled skipped it.
Ready to climb to Rung 4? One gate — and it is binary.
- You have shipped one working system to one real user, in a real environment, producing data that changed at least one real decision — not a demo, not a simulation, not a slide
The production readiness check no one runs early enough
- Can your system survive the permanent departure of the engineer who built it — without a multi-week knowledge transfer?
- Do you have a procurement playbook that allows a non-engineer to order the next 100 nodes without making critical decisions?
- Are your data governance and security postures written down, tested, and defensible to a non-technical stakeholder?
- Do your end users check your dashboard unprompted — or do they only look when you remind them?
The moment your pilot dashboard starts feeding decisions for a thousand users instead of ten, everything changes. Not the technology — the technology is doing what it was built to do. What changes is the operational context around it. Hardware becomes procurement. Data becomes governance. Alerts become service-level agreements. And the brilliant engineer who built it all is suddenly the most dangerous single point of failure in your organisation.
The operational questions that matter more than technical ones
Most teams at Rung 4 are excellent at architecture and poor at operations. Not because they are incapable — because they have never been in production before. The questions that keep you up at night at Rung 4 are not “does the data flow correctly?” They are: “What happens when the gateway at Site 7 goes offline at 3am?” and “Who owns the alert response for the cold chain breach on a public holiday?” and “How do we onboard the next twenty customers without rebuilding the tenant structure from scratch?”
Reliability
Your uptime SLA is not a technical metric — it is a trust contract. Every minute your platform is down, you are withdrawing from the credibility account you built with your users. 99.9% uptime means 8.7 hours of downtime per year. Know what that costs before you promise it.
Repeatability
The fastest production teams have a deployment playbook so clear that a person who has never seen the system can set up a new site in a defined time window. If your deployment relies on institutional memory rather than written process, you have a single point of failure masquerading as a team.
Trust
A dashboard your users check without being reminded is a dashboard they trust. A dashboard they check when you ask is a dashboard they tolerate. The difference between tolerated and trusted is the difference between a pilot and a product.
Teachability
Your operational playbook is only as good as the newest person who can execute it. If explaining your system requires more than a day of onboarding, it is too complex for production scale. Simplicity is a production virtue, not a beginner’s shortcut.
The skill most underestimated at Rung 4: data storytelling
I have a rule I apply to every production deployment: the dashboard is never the deliverable. The decision is. Every IoT team I have worked with at scale has eventually had to learn this, usually after a painful episode where their technically flawless dashboard sat unused because the person making the decision could not extract the relevant insight in under ten seconds.
Data storytelling at production scale means three things: knowing your audience, making the single most important number unmissable, and designing the alert so that the person who receives it knows immediately what action it requires. If your alert says “Threshold Exceeded — Value: 42.3°C” you are not done. If it says “Pump 7 temperature critical — maintenance team notified, estimated response time 12 minutes” you are getting closer.
“Dashboards that run and dashboards that matter are not the same thing. The difference is whether someone who was not in the room when it was built can look at it for ten seconds and know exactly what to do next.”
— Dr. Mazlan AbbasThe production patterns that scale
These are the use cases I have watched move successfully from single-site pilots to multi-site production deployments. The architecture pattern is the same across all of them. The platform layer does not change. Only the sensor types, the alert thresholds, and the decision owners change.
Ready to climb to Rung 5? Three gates — and honesty is the only tool.
- You have at least three deployments running on the same platform pattern, maintained by a team rather than a person
- Your end users act on your dashboards without being prompted — the data has earned their trust through demonstrated accuracy
- Your operational playbook is teachable — a capable person new to your organisation could execute it with one day of orientation
Mastery is not the top of the ladder. It is where the ladder widens.
The most common mistake I see from Rung 4 builders is treating Rung 5 as a reward for technical excellence. It is not. Mastery is a different kind of work. It is the work of turning what you know into what others can build. That is harder than any architecture decision I have ever made — and it compounds in ways that technical skill alone never does.
The mastery questions that require real honesty
- Have you brought another builder — not a colleague who observed, but one who can now independently execute — onto a platform you helped scale?
- Have you contributed to curriculum, training, or certification in any form — formal or informal, paid or pro bono?
- Are you actively investing in builders who are one or two rungs below you, with time rather than only money?
- If you left the IoT field tomorrow, would the work you have done continue to produce builders — or would it stop with you?
I started Favoriot because I believed — and still believe — that the IoT skills gap in Southeast Asia is not a technology problem. It is a teaching problem. There are enough platforms. There are not enough practitioners who know how to use them well enough to train the next wave. Every time I meet an engineer who is technically brilliant but cannot explain what they built to a business stakeholder, or a student whose IoT project works but makes no decisions, I see the same gap. The gap between building and building something that matters.
The compounding mathematics of teaching
Here is the math that drove everything we built at Favoriot’s education track: one trained lecturer becomes thirty trained students per cohort. Three cohorts per year, three years, and you have 270 practitioners in the field who carry the same foundational approach. One certified university program reaches those students plus researchers, plus industry partners, plus the graduates who go on to lead their own teams. The compounding is not linear. It is exponential — and it starts with one decision to invest time in a person rather than only a platform.
What mastery actually requires you to change
The shift from Rung 4 to Rung 5 is not about learning new technical skills. It is about changing what you measure. At Rung 4, you measure system uptime, alert accuracy, and deployment velocity. At Rung 5, you measure how many builders you have sent up the ladder behind you. Those are completely different metrics — and if you are still measuring only the former, you have not yet made the shift.
The Rung 5 operating principles
Every platform decision you make, document the reasoning. Not just the what — the why. The reasoning is what transfers to the next builder. The code they can eventually rewrite.
A training session is a gift to one cohort. A curriculum is a gift to everyone who teaches after you. Build for the person who will run the workshop when you are not in the room.
Certification is not a revenue line. It is a quality gate. The value of a certification is the signal it sends to employers and communities about what the holder can do — not just what they have studied.
The worst outcome for a student IoT project is that it stays in the lab. The best outcome is that it solves a real problem for a real organisation and the student learns what deployment requires. Build those bridges between classrooms and operations centres.
This is the most counterintuitive principle at Rung 5, and also the most important. The measure of mastery is whether the work continues without you. If it does, you have built something that matters. If it does not, you have built a dependency.
“The ladder is finite. The climb is repeatable. And once you have reached the top, your most important job is to lower the ladder for the person behind you.”
— Dr. Mazlan Abbas, Mastering IoT & AIoT with FavoriotThe role universities play — and what most of them are getting wrong
I spend a significant portion of my time working with universities across ASEAN on IoT education. The pattern I see repeatedly is institutions with active IoT projects, smart campus initiatives, and research grants — but everything operates in silos. Faculty A does not know what Faculty B built. The student in the engineering department and the student in computer science are solving the same problem independently with incompatible tools. The unifying layer — a shared platform, a shared data standard, a shared curriculum framework — is almost always missing.
The goal is not more IoT courses. The goal is a living ecosystem where learning compounds. Where a first-year project becomes a third-year research dataset. Where a capstone becomes an industry deployment. Where a lecturer’s expertise is encoded into curriculum that outlasts their semester assignment. That is an AIoT-ready university — and it is not built by buying more hardware. It is built by connecting what already exists.
There is no Rung 6. This is what comes next instead.
- The ladder stops widening technically and starts widening humanly — your leverage becomes the number of builders you have activated, not the complexity of the systems you maintain
- You invest time — not just endorsements — in builders who are one or two rungs below you, including students, junior engineers, and practitioners in adjacent industries
- You build or contribute to something that continues producing builders after your direct involvement ends: a curriculum, a certification program, a community, a platform others can learn on
The Ladder Is Yours to Lower
You started this companion wherever you started. The rungs are the same for everyone. The pace is yours to choose. What matters — and I mean the only thing that ultimately matters — is whether you pass it forward.
Come find us when you are ready. The Favoriot community runs on people who have climbed the ladder and stayed to lower it for the next builder. That is the only membership requirement.
© 2026 Favoriot Sdn Bhd · All infographics and frameworks are copyright Favoriot. This companion eBook is produced for educational use.
Leave a Reply