Category: Applications

The Electricity Bill Arrives Too Late: Why Operational Visibility Matters

There is something interesting about electricity bills. They are very good at telling us what has already happened.

They can tell us how much electricity we consumed and how much we need to pay. For commercial facilities, they can also reveal the financial impact of Maximum Demand. The problem is that by the time we see the bill, the event that caused the cost may have happened weeks earlier.

That is a good example of what I call operational blindness.

The Problem Is Not Lack of Data

I recently looked at an IoT project developed to monitor Maximum Demand in real time. The problem it addressed was surprisingly common.

A large facility can have air-conditioning systems, computers, laboratory equipment, motors and other electrical loads operating simultaneously. At certain times, these loads can push electrical demand sharply upward.

Without continuous monitoring, the people managing the facility may not realise that a demand spike is happening.

The spike occurs. The cost is incurred. The bill arrives later.

Only then does somebody ask, “What happened?”

The organisation had data, but it did not have visibility when the information could still influence an operational decision.

Seeing the Problem While It Is Happening

The project approached the problem differently. Electrical parameters such as voltage, current, power factor and demand were continuously measured and transmitted through an IoT architecture.

Operators could then observe demand behaviour as it happened rather than depending entirely on periodic readings and historical bills.

During testing, the system captured a live demand peak of 664.8 kW, compared with 680 kW recorded for billing purposes.

That difference tells an interesting story. Real-time IoT monitoring can provide a sufficiently close picture of what is happening operationally to help people recognise potentially costly conditions earlier.

The Dashboard Is Not the Real Value

We sometimes become too fascinated by dashboards. We talk about graphs, gauges, sensors, protocols and cloud systems.

But nobody wakes up in the morning saying, “I need another dashboard.”

What the operations team really needs is an answer to practical questions:

  1. Are we approaching a costly demand threshold?
  2. When do our highest demand periods normally occur?
  3. What activities coincide with those peaks?
  4. Is something behaving differently today?
  5. Should somebody act now?

That changes the purpose of IoT. We are no longer collecting data simply because we can. We are giving people enough visibility to make a decision while there is still time to act.

From Seeing to Predicting

The next step becomes even more interesting.

Once months or years of operational data have been collected, machine learning can begin looking for patterns that humans may miss. Instead of only showing that demand is high, the system could eventually warn that current conditions resemble patterns that previously led to a demand spike.

This moves us from monitoring towards early warning.

For me, that is where AIoT becomes meaningful. IoT allows us to see the physical world. AI helps us understand what those observations may mean.

Technology creates value when it shortens the distance between something happening and somebody knowing about it.

Because when the electricity bill finally arrives, the opportunity to change what happened last month is already gone.

[Note: This is one of Favoriot‘s Use Case – Energy Monitoring]

What Taiwanese Companies Taught Me About Building IoT Together

Knowing your place in the value chain

During my recent meetings with Taiwanese companies, one thing stayed with me. They understood clearly where they fit in the IoT value chain. Each company had its own area of focus, and its people could explain what they did well and how their capabilities might work with others.

Some specialised in hardware and connectivity. Others focused on sensors, gateways, energy systems, communications or software. They were not trying to own every part of the solution. They had chosen a role, built experience in it and were open to collaborating with companies whose strengths filled other gaps.

That way of thinking feels practical to me. IoT projects bring together many moving parts, from devices in the field to networks, data platforms and applications. It is difficult for one company to be equally strong in every layer. A well-matched group of partners can bring the right expertise together around a customer’s needs.

Where FAVORIOT fits

FAVORIOT’s role is to provide an AIoT platform for operational visibility. We help organisations collect data from connected assets, understand what is happening and respond when attention is needed. That role can sit alongside partners who provide devices, connectivity, specialist applications, deployment services or customer access.

For me, the meetings were a useful reminder that we do not need to own every layer to contribute meaningfully. We need to make our part of the stack useful, clear and practical to connect with the strengths of others.

A partner does not have to sell every part of a solution either. Each company can focus on what it knows best, while the group works out how those capabilities fit together for a particular project.

What a partner network can make possible

A network of companies with complementary strengths can offer customers several advantages:

  • More complete solutions: Customers can bring together devices, networks, platforms and services that suit their needs without relying on one supplier to cover everything.
  • Clearer project roles: When each partner knows its area of responsibility, planning and coordination can become easier.
  • Access to new markets: Partners can introduce one another to industries, regions and customer groups that would take longer to reach alone.
  • Faster delivery: Teams can combine existing products and experience instead of building every component from scratch.
  • More choice: Customers can compare options based on their budget, site conditions, preferred hardware and technical requirements.
  • Shared credibility: A trusted relationship with one partner can help a customer feel more comfortable meeting the rest of the team.
  • More routes to market: Several partner channels can create opportunities even when one sales route slows down.
  • Room to grow together: A successful project may lead to new services, markets and joint offerings.

A shared path forward

What I appreciated about these meetings was the clarity. The companies knew what they did well, and they were willing to discuss how their strengths could support a broader solution.

That is a useful lesson for IoT businesses. Growth does not always come from doing more things ourselves. Sometimes it comes from becoming very good at a clear role and building working relationships with others who bring different capabilities.

When every partner understands its contribution, the customer has a better chance of getting a solution that works as a whole. Each company also gains a clearer path to contribute and grow.

Stop Selling “Smart City.” Start Selling the Thing That Actually Works.

A colleague in Bangkok sent me something last month that made me stop scrolling.

He’d been reviewing procurement data across a handful of ASEAN municipalities, trying to understand why so many “smart city” line items in city budgets kept getting quietly renamed, restructured, or dropped altogether after year two. Not cancelled outright. Just… rebranded into something else. A flood monitoring project. A cold chain upgrade. A dengue alert system.

Same money. Same sensors, half the time. Different name on the invoice.

Why does that happen?

The label became the liability

Here’s the uncomfortable finding buried in that data: in the very countries where “smart city” programs have run the longest, the term itself has started to carry baggage. Mention it in a council meeting now and you get polite nods and quiet skepticism. People have seen the glossy master plans. They’ve seen the dashboards nobody looks at after the ribbon-cutting. “Smart city” has become shorthand for over-promised and under-delivered, and everyone in the room knows it, even if nobody says it out loud.

I’ve sat in enough of those rooms myself, going back to my REDtone IoT and FAVORIOT days, to recognize the exact moment a pitch loses the audience. It’s not when the tech is weak. It’s the second you say “smart city” as the category, instead of naming the actual problem you’re solving.

Compare these two openings.

“We’re deploying a smart city platform for your municipality.”

Versus:

“We’re building a system that tells you a flood is coming to Nakhon Si Thammarat 36 hours before it hits, instead of after.”

One is a category. The other is a promise you can be held to.

Nakhon Si Thammarat isn’t hypothetical

I keep coming back to Nakhon Si Thammarat because it’s not a thought experiment. That province has taken real, repeated flood losses, year after year, the kind that show up in disaster relief budgets and insurance claims long before anyone writes a case study about them. Nobody there needs convincing that flood early warning has value. The ROI narrative writes itself: fewer evacuations done blind, fewer bridges washed out with no warning, fewer farmers finding out their fields are underwater from a neighbor’s phone call instead of a sensor.

That same budget line could have been labeled “smart city resilience initiative.” Would it have moved as fast through approval? I doubt it.

Vertical, not category

This is the part I think a lot of us in the industry got backwards for years. We built the category first, dengue and flood and cold chain as features, sub-modules living inside something bigger called Smart City. It felt efficient. One platform, many use cases, one procurement conversation.

But procurement doesn’t buy platforms. Health ministries buy outbreak prevention. Disaster management agencies buy lead time. Cold chain operators buy spoilage reduction they can put a ringgit figure next to. Nobody in those rooms has a budget line called “digital transformation.” They have a budget line called “vaccine wastage,” and that number is already too high, and somebody upstairs is asking why.

Cold chain monitoring, dengue and health surveillance, flood and disaster response, environmental monitoring, these are not features of a smart city. They are the smart city, minus a label that’s stopped helping and started hurting.

The money still often sits inside a smart city budget allocation. That part hasn’t changed. What’s changed is what you say out loud in the pitch meeting.

What I tell founders now

When a founder asks me how to position an IoT solution for government or municipal buyers these days, I tell them the same thing every time: find the named domain. Not the umbrella term. The named domain.

Don’t say you do smart agriculture. Say you cut fertilizer waste for palm oil smallholders by a measurable percentage. Don’t say you enable smart healthcare. Say you cut the time between a dengue cluster forming and a health officer knowing about it, from weeks to days.

Is this just marketing, a coat of paint on the same technology? Partly, yes. But it’s also something more honest than marketing. It’s an admission that “smart city” was always too big a promise for any single vendor, any single deployment, any single budget cycle to keep. The category asked cities to imagine a transformed future. The vertical asks them to solve a problem they already have a number attached to.

I’ve watched too many pilots die waiting for the transformed future to arrive. I’d rather help ship the flood warning that works.

The question worth sitting with

If you’re building or selling IoT into government right now, ask yourself honestly: could a mayor explain what you do in one sentence, using a number, without saying the words “smart city” at all?

If the answer is no, you don’t have a weak product. You have a pitch still hiding inside a category that’s already lost the room’s trust.

I wrote a deeper technical take on this over at IoT World.

Malaysia’s IoT Market Has The Infrastructure. So Why Is Adoption Still Crawling?

Every few months a new market research report lands in my inbox with a headline number for Malaysia’s IoT market. Billions of dollars. Double-digit CAGR. Smart city spend projected to grow at 27% a year through 2034. On paper, we look like a country sprinting toward a connected future.

I have been in this industry long enough, from MIMOS to REDtone IoT to building FAVORIOT from scratch, to know the difference between a market projection and a market. The projection is what analysts model when they extrapolate 5G rollout numbers and government budget announcements. The market is what actually gets deployed, paid for, and kept running past the pilot phase. In Malaysia right now, there is a real gap between the two, and I think it is worth naming exactly where that gap comes from.

The Infrastructure Story Is Genuinely Good

Let’s give credit where it belongs first, because the connectivity layer has moved fast. 4G coverage sits above 96% of populated areas. 5G adoption crossed 52% by the end of 2024, and coverage reached over 82% of populated areas by 2025. Malaysia has more than 7,000 5G sites deployed and pulled in over RM86 billion in data center investment in 2024 alone, making the country Southeast Asia’s leading data center hub.

That is not a small achievement. A country cannot build an IoT economy without pipes to carry the data, and Malaysia’s pipes are, by regional standards, excellent. If you had told me in my MIMOS days that we would have this level of physical infrastructure by 2026, I would have been thrilled.

But infrastructure was never the constraint. Demand was.

The Roadmap We Wrote, And The Reality We Got

Go back to the National IoT Strategic Roadmap, the document MIMOS helped shape more than a decade ago. It forecast IoT applications and services reaching RM34 billion by 2025, up from RM7.5 billion in 2020. Device production was projected to hit RM4.3 billion in the same window.

Nobody in this industry seriously believes we hit those numbers. I do not say that to be cynical about the roadmap. I say it because the gap between what we projected and what materialized is the single most instructive data point in this entire market. It tells us the bottleneck was never technological capability. It was adoption discipline, and adoption discipline is a much harder problem to solve with a budget allocation.

Seven Reasons Growth Keeps Stalling

I want to walk through the actual mechanics of why, because “slow adoption” is too vague to act on. Here is what I see happening on the ground, backed by what the data confirms.

SMEs are still building the foundation IoT depends on. Malaysia’s economy runs on small and medium enterprises, and a recent survey found only about 35% of surveyed SMEs had implemented basic digital systems beyond simple accounting software. You cannot sell predictive maintenance sensors to a factory floor that has not digitized its production logs yet. IoT vendors keep pitching step five to companies that are still working through step one, and the pitch lands as noise rather than opportunity.

The payback math does not match buyer expectations. Deploying an IoT platform requires real upfront investment in hardware, software, and integration with legacy systems, and for SMEs this cost is a genuine barrier to entry even when the long-term ROI is positive. Malaysian buyers, especially in manufacturing and plantation sectors, want a return inside 12 to 18 months. Most honest business cases for connected infrastructure deliver in 24 to 36. That gap kills deals at the finance desk long before the technical evaluation even starts.

We have a talent bottleneck on both sides of the table. Adoption requires skills in IoT, data analytics, cybersecurity, and cloud computing, and Malaysia faces a real shortage of professionals who can manage these deployments end to end. This hits twice. Customers cannot maintain what they buy, and system integrators cannot scale delivery teams fast enough to take on more projects. I see this constraint directly in how far my own SI partners can stretch their capacity.

We have become excellent at pilots and mediocre at scale. I have written about this before, going back years: many organizations in Malaysia are still exploring what IoT can do rather than actually implementing it at scale. Government and GLC procurement cycles routinely stretch 12 to 24 months, and by the time a tender closes, the internal champion who pushed for the pilot has often moved to a different role. The institutional memory that would carry a pilot into a fleet-wide rollout simply evaporates.

5G hype outran 5G reality, and it dented confidence broadly. This one deserves more attention than it gets. 5G speeds actually fell 46% as user numbers scaled during 2024 and 2025, with real-world performance landing at roughly half of what marketing promised. Enterprise deployments involving sensors and remote machinery hit ceiling effects faster than expected. The irony is that most industrial IoT use cases never needed 5G in the first place. NB-IoT, LoRaWAN, and plain 4G cover the majority of real deployments. But 5G dominated the boardroom conversation for two years, and when it underdelivered, some of that disappointment bled into skepticism about connected technology in general.

Security fear has outpaced security literacy. IoT devices expand the attack surface for cybercriminals, and data privacy regulations around data ownership add another layer of complexity. Malaysia’s breach history has not helped confidence here. 2023 recorded the highest number of data breaches on record, with fifteen ransomware cases reported per week. For risk-averse government agencies and GLCs, “where does my data actually sit” has become a conversation-ending question, and few local vendors carry the certifications to answer it with authority.

Policy attention has moved on to AI, and IoT lost its dedicated spotlight. Look at where Budget 2026 puts its weight. RM53 million for the Malaysia Digital Acceleration Grant targeting blockchain, AI, and quantum computing. RM18.1 million for the National AI Office. RM2 billion earmarked for a Sovereign AI Cloud. IoT is barely named as a standalone priority anymore. Compare that to Budget 2025’s allocation of just RM15.1 million for smart city development under the Housing and Local Government Ministry, a rounding error next to the AI figures. Without a dedicated policy push, and without a compliance mandate the way India’s FASTag requirement forced RFID adoption almost overnight, Malaysian IoT adoption stays voluntary. Voluntary adoption is slow adoption by definition.

The Pattern Underneath The Pattern

Put these seven factors together and a single story emerges. Malaysia does not have a technology problem. It has a demand-side maturity problem sitting on top of a fragmented supply side. The billions poured into 5G, fiber, and data centers were supply-push investments, and they worked. The AI Nation agenda is also supply-push. What never got properly addressed is demand-pull: regulatory mandates that force adoption where voluntary uptake has failed, financing instruments that convert IoT capex into manageable opex, and system integrator capacity that can deliver at the scale procurement teams keep promising.

Where This Actually Gets Interesting

Here is the part I think most people in the industry are missing, and it is the reason I am not pessimistic about where this goes next.

AI cannot function in the physical world without sensor data. Every company now scrambling to bolt AI onto their operations is going to discover, within the next year or two, that they have nothing meaningful to feed their models. You cannot build a predictive maintenance AI without machine telemetry. You cannot build a smart agriculture AI without soil and climate sensors. You cannot build a smart building AI without occupancy and energy data. The instrumentation layer that IoT was supposed to build over the last decade is exactly the layer AI needs and mostly does not have.

Malaysia spent ten years underinvesting in that instrumentation layer relative to its own roadmap. That is the bad news. The good news is that the correction is coming, driven not by an IoT mandate but by AI ambition that will hit a wall without sensor data behind it. Companies that quietly kept building connected infrastructure through this slow period, the ones who treated IoT as the unglamorous plumbing rather than the headline act, are positioned to become the data supply chain for Malaysia’s AI Nation agenda.

That is not a consolation prize. That is the actual opportunity. The market did not fail. It just took longer to arrive at the reason it needed to exist.

Malaysia’s IoT-specific market figures vary considerably across research houses, and several published reports use templated methodology that should be treated with caution. The directional pattern across every credible source, however, is consistent: infrastructure has outpaced adoption, SMEs remain the binding constraint, and enterprise pilots are not converting to scale at the rate the roadmap assumed.

Why I Want More Malaysian Students to Brag About Their Projects

Malaysian students build impressive projects but rarely share them publicly. Here is why that needs to change, and what students, lecturers, and institutions can do about it.

Have you ever built something and then kept it to yourself?

I have seen this happen too many times, and it bothers me more than I probably let on. A student spends weeks getting an IoT sensor to talk to a cloud platform, wires everything up, writes the code, stays up late debugging, and then… nothing. They submit the assignment, get their marks, and move on. Nobody outside that classroom ever knows the project existed.

That project deserved better. And honestly, so did the student.

The Culture of Hiding Our Work

I think we have a cultural habit in Malaysia of downplaying what we build. We are taught, from a young age, that showing off is rude. That humility means staying quiet. That if your work is good, people will somehow find out on their own.

But in the world we are living in today, that thinking is holding our students back.

I recently wrote about how some students in Malaysia are still learning IoT using Blynk, ThingSpeak or Favoriot, platforms that have genuinely served the community well over the years. My concern was not with the tools themselves, it was with the possibility that some students might complete their programmes without being exposed to more current, industry-relevant environments. The response to that piece was warm and it opened a much bigger conversation I want to continue here.

Because there is a second problem, and it sits right next to the tools issue. Even when students build something impressive, they rarely tell the world about it.

What “Bragging” Really Means

I want to be careful with my word choice here, because when I say I want Malaysian students to brag, I do not mean arrogance. I mean documentation. I mean visibility. I mean the courage to say, “I built this, and here is how I did it.”

In the global tech community, sharing your work is not showing off. It is how you contribute. It is how you invite feedback, attract collaborators, and build a reputation before you even graduate. Every time a developer writes a blog post about what they learned building a project, every time a student posts a short video demo on LinkedIn or YouTube, every time someone publishes their code on GitHub with a clear README, they are adding value to the community.

They are also building something that a CV alone cannot carry: a visible portfolio of thinking.

I Have Seen What Happens When Students Share

When students do step forward and share their work, remarkable things happen. I have seen students connect with mentors because someone stumbled across their blog. I have seen project ideas get picked up by companies that were looking for exactly that kind of solution. I have seen young engineers get job offers because a hiring manager found their GitHub repository.

And I have seen something perhaps more important: the student’s own confidence change. When you write about your project publicly, you are forced to explain it clearly. You start to understand what you actually built. You start to see what worked and, more importantly, what did not. That reflection is part of the learning that never shows up in an exam.

The Platforms Are Already There

There is no shortage of places where Malaysian students can share their work. LinkedIn is the obvious starting point, and yet I still see so many profiles with nothing more than a degree listing and a generic summary. Imagine if every final year IoT project at a Malaysian university had a proper LinkedIn post, with photos, a short explanation of the problem it solved, and the tech stack used.

GitHub is equally powerful. A well-documented repository says more about an engineer’s capability than almost anything else. Medium or WordPress and personal blogs remain excellent homes for longer technical write-ups. YouTube or TikTok are perfect for demo videos. Even short-form platforms have an audience hungry for genuine student work.

The tools to publish are free. The audiences are there. What is missing is the habit and the encouragement.

What Lecturers and Institutions Can Do

I want to be fair here: this is not entirely on the students. If we want a culture shift, we need to start from inside the institutions.

Imagine if project documentation and public sharing were built into assessment rubrics. Imagine if a student was graded not only on whether the sensor collected data correctly but also on whether they could explain the project clearly to a non-technical audience. Imagine if universities celebrated student projects the way they celebrate sports achievements.

Some institutions are already doing this, and I applaud them. But it needs to be more systematic. Students should graduate not just with technical skills but with the confidence and habit of communicating those skills to the world.

A Personal Challenge

If you are a student reading this, I want you to do one thing this week. Pick a project you are working on or have completed. Write about it somewhere public. It does not have to be perfect. It does not have to be long. Just write honestly about what you were trying to solve, what you used to solve it, and what you learned in the process.

That one post could be the start of something you cannot predict yet.

If you are a lecturer or a programme coordinator, think about how you can make sharing a formal part of the learning journey. Not as a burden, but as a skill that students will use for the rest of their careers.

Malaysia has genuinely talented engineering students. I have met many of them, worked alongside some of them, and been impressed by what they can build when given the space to do it. My concern is that too much of that talent is invisible to the industry because no one taught them that visibility is part of the job.

So tell me, if you could make one change to how Malaysian engineering education celebrates student work, what would it be?

Why Malaysia Must Stop Treating IoT as a Final Year Project Toy

Every year, I meet students who proudly show me their IoT projects, and I can almost predict what will appear on the table before the demonstration even begins. There will be a sensor, a microcontroller, a few wires, a mobile app, and a dashboard showing temperature, humidity, distance, motion, water level, or some other familiar reading. The student will explain how the system works, the lecturer will nod, the evaluator will ask a few questions, and everyone will feel relieved when the demo runs without embarrassment. For a few minutes, the project looks alive, impressive, and full of promise.

Then, after the presentation, something strange happens. The device is switched off. The components are kept in a box. The dashboard is no longer opened. The video may be uploaded somewhere, but after that, the whole thing quietly disappears into the graveyard of final year projects. Nobody continues collecting data. Nobody studies the pattern. Nobody asks whether the system can be deployed in a real site. Nobody asks whether the idea can be improved, commercialised, or connected to an actual industry problem. It simply ends where it started, on the classroom table.

Each time I see this, I ask myself, “Is this what IoT has become in Malaysia? A temporary demo to pass an assessment?”I am not saying this to mock students. Far from it. I respect students who spend sleepless nights trying to make their projects work. I know the pain of troubleshooting something that refuses to behave when people are watching. Anyone who has handled hardware knows that sensors have a strange sense of drama. They work perfectly at midnight, then suddenly become shy during the presentation.

But my concern is bigger than the student project itself. My concern is that Malaysia has treated IoT for too long as something small, experimental, academic, and temporary, when in reality, IoT should already be part of how we manage our cities, farms, buildings, factories, transport systems, utilities, campuses, and public services. IoT is not a toy. It is infrastructure intelligence. Malaysia must start treating it that way.

The Problem Is Not the Students

Let me say this clearly. The problem is not the students. Many of them are creative, hardworking, and eager to learn. They work with limited budgets, limited time, borrowed components, weak WiFi, and sometimes unclear project guidance. They do what they can with what they have, and for that, they deserve encouragement. The issue is not their effort. The issue is the way we have framed IoT in education, industry, and sometimes even government projects.

For many years, IoT has been taught and demonstrated as a sensor to dashboard exercise. Connect the device. Send the data. Show the graph. Done. That is useful as a starting point, but it is a dangerous place to stop. When IoT is presented only as a dashboard project, students naturally assume that the job is complete once data appears on the screen. They do not always ask what happens after the data appears, who will use it, what decision it supports, what action must follow, what happens when the device fails, or whether the system can survive outside the classroom.

Maybe we taught them to build the wrong finish line, I thought to myself. The finish line should not be “the data appears.” The finish line should be “someone makes a better decision because the data appeared.” That is the difference between a demo and a real solution.

A Sensor Is Not a Solution

One of the biggest misunderstandings about IoT is the belief that once a sensor is connected, the problem is solved. This is like saying a thermometer cures fever. A thermometer does not cure anything. It only tells you something is wrong. What matters next is the interpretation, the decision, the treatment, the follow up, and the responsibility of the person who acts on that reading.

IoT works the same way. A temperature sensor in a cold room does not protect vaccines or food by itself. It only provides signals. The real value begins when the system detects abnormal readings, alerts the right person, records the evidence, helps the operator respond quickly, and supports compliance reporting. A water level sensor near a river does not prevent flooding by itself. It becomes useful only when the data is trusted, the alert reaches the correct agency, the response process is clear, and residents receive warnings early enough to act. A vibration sensor on a machine does not prevent downtime by simply producing numbers. It becomes useful when those numbers are analysed, compared against patterns, and linked to maintenance decisions before the machine fails.

That is why I always say the dashboard is not the destination. The dashboard is only the window. The real question is what we do after looking through that window. If we see a problem and nobody acts, then the system has failed quietly. It may still look beautiful on a screen, but it has not changed anything in the real world.

Malaysia Has Too Many Real Problems for IoT to Remain in the Lab

Malaysia does not lack problems that need better visibility. We have floods that still catch people by surprise, buildings wasting energy after office hours, farms that need better monitoring of soil, water, and climate, logistics operators that must prove temperature compliance, factories that want to reduce downtime, public facilities that need better maintenance, and local councils trying to manage waste, traffic, drainage, parking, lighting, and public complaints with limited manpower.

These are not imaginary classroom problems created for a semester project. These are real operational issues that cost money, time, trust, and sometimes safety. Yet many organisations still operate using manual checks, WhatsApp updates, delayed reports, and reactive decisions. Someone must visit the site. Someone must take a photo. Someone must key in data. Someone must send a message. Someone must wait for approval. By the time the information reaches the decision maker, the problem may already have grown bigger.

This is where IoT should become serious. IoT should help Malaysia see earlier, respond faster, and plan better. It should reduce blind spots in operations. It should help people move from guessing to knowing, and from reacting late to acting early. But that will not happen if IoT continues to be treated as a decorative technology for exhibitions, competitions, and one off prototypes.

A smart city is not built from disconnected demos. A smart factory is not built from one sensor reading on a laptop. A smart farm is not built from a project that stops after the student graduates. Real IoT needs continuity, ownership, maintenance, platforms, training, security, and people who care about the outcome, not just the device.

The Final Year Project Mindset Is Too Small

Final year projects are important. They help students learn, test ideas, make mistakes, and gain confidence. I fully support that. But when the final year project mindset becomes the national mindset, we have a problem. The final year project mindset usually asks whether the system can work for the demo, whether the data can appear on a screen, whether the poster looks good, whether the report can be submitted, and whether the panel can be impressed.

A national IoT mindset asks much harder questions. It asks whether the system can solve a real problem, work outside the lab, scale to multiple sites, be maintained for years, protect the data, support daily decisions, reduce cost, reduce risk, improve service delivery, and continue after the project team leaves. These are the questions Malaysia must start asking more seriously.

We cannot keep celebrating prototypes while ignoring adoption. We cannot keep launching pilots that never move into operations. We cannot keep confusing activity with progress. There is a big difference between building something and making it useful. Malaysia has built many IoT things. Now we must make them useful.

Stop Asking Only “Can It Connect?”

One of the most common questions in IoT is, “Can it connect?” Of course, connectivity matters. Without connectivity, the device becomes an island. But connectivity alone is not enough. A connected device that sends meaningless, unreliable, unsecured, or unused data is not a success. It is only a noisy device.

The better questions are more practical. Can it connect reliably? Can it recover when the network fails? Can it send clean and meaningful data? Can it protect that data? Can it trigger the right response? Can it help the user decide faster? Can it reduce manual work? Can it be supported for years, not weeks?

This is where many IoT projects become weak. They focus too much on the first connection and not enough on long term usefulness. I have seen systems where the data appears nicely on the dashboard, but nobody knows what threshold should trigger an alert. I have seen dashboards that look impressive, but no department has agreed who is responsible when something abnormal happens. I have seen projects where the devices were installed, but after a few months, nobody checked whether the data was still accurate.

That is not IoT maturity. That is technology theatre. It looks good from far, but when you stand closer, you realise the system has no operational backbone.

IoT Must Belong to the People Who Own the Problem

Another mistake I often see is when IoT is handed entirely to the technical team. The technical team can connect devices, configure networks, set up platforms, and build dashboards. That part is important. But they cannot define business value alone. Technology people can build the pipe, but the people who face the pain must define what should flow through it and what should happen after that.

If the project is about energy, the energy manager must be involved. If the project is about farming, the farm operator must be involved. If the project is about city services, the relevant local council department must be involved. If the project is about machine maintenance, the maintenance team must be involved. If the project is about cold chain, the operations and compliance teams must be involved.

IoT fails when it becomes a technology project without an operational owner. The people who feel the pain must be part of the design from day one. They know the messy details. They know where problems happen. They know which alerts matter and which alerts will be ignored. They know what kind of information is useful at 8 a.m. on a busy Monday, and what kind of dashboard nobody will ever open after the vendor leaves.

Who owns the pain? That is the question I often ask myself. Because the person who owns the pain should also own the outcome.

Cybersecurity Must Be Built In From the Beginning

When we connect more devices, we also create more openings. This is the side of IoT that many people do not like to talk about during cheerful demos. A connected device can provide visibility, but a poorly secured device can also become a weak door into a larger system. That is why IoT cannot be treated casually, especially when it starts moving into buildings, factories, campuses, farms, utilities, transport systems, and critical services.

Every IoT project should ask security questions from the beginning. Who can access the device? How is the device authenticated? Can the firmware be updated safely? Can the data be altered? Can someone fake a reading? Can unusual device behaviour be detected? What happens when the device is stolen, damaged, or hijacked? How do we separate normal failure from suspicious activity?

AI can help detect abnormal patterns and support faster response, but AI is not a magic shield. A weak IoT architecture with AI added later is still weak. It is like putting a fancy lock on a wooden door that is already cracked. Security must be designed into the system, not sprinkled on top after the project becomes popular.

This is why I often remind people that IoT is no longer just an engineering conversation. It is also a cybersecurity conversation, a governance conversation, and a trust conversation. Once a device is connected to a larger environment, it becomes part of a bigger responsibility.

The AI Conversation Makes IoT More Important

Today, everyone wants to talk about AI. AI is in every conference, proposal, workshop, policy conversation, and almost every company profile. Sometimes it feels as if even the office pantry will soon claim to have an AI powered coffee strategy. I understand the excitement because AI is powerful, but we must remember something very basic.

AI needs data. Not just old data sitting in spreadsheets, but live, real world, operational data. Data from machines, buildings, vehicles, rivers, farms, cold rooms, energy meters, production lines, and public facilities. Where does that data come from? It comes from IoT.

IoT is the bridge between the physical world and digital intelligence. Without IoT, many AI systems are left guessing from outdated, incomplete, or manually entered information. This is why I find it strange when people say IoT is old news and AI is the future. To me, that is like saying the brain is important, but the nerves are no longer needed.

AI may be the brain, but IoT is part of the nervous system that senses what is happening in the real world. If the nerves are weak, the brain receives poor signals. When the signals are poor, the decisions will also be poor. Malaysia cannot build serious AI for real world operations while treating IoT as an afterthought. The two must grow together.

We Need Local Capability, Not Permanent Dependency

There is another issue that we must discuss honestly. Many students and developers in Malaysia still use overseas IoT platforms by default. They use them because tutorials are easy to find, examples are everywhere, and seniors have used them before. I understand this completely. When a student is rushing to complete a project, the easiest path becomes the most attractive path.

But at a national level, we must ask a bigger question. Do we want to remain only users of other people’s platforms, or do we want to build our own capability as well? This is not about rejecting global platforms. There is nothing wrong with learning from global tools. They have their strengths, and they serve many use cases well. But if every university, student, agency, and company only learns using external platforms, then our local ecosystem will remain thin.

We will produce users, not builders. We will produce dependency, not confidence. We will produce projects, not capability. Malaysia needs local platforms, local examples, local documentation, local support, local case studies, and local success stories. We need students who can say they built something using a Malaysian IoT platform like Favoriot, and that project can be extended into a real solution. We need lecturers who can expose students to platforms that understand local industry needs. We need system integrators who can build faster because they are not starting from zero every time. We need government and industry buyers who care about long term ownership, data governance, and local support.

This is how an ecosystem grows. Not through slogans, but through usage, trust, and repeated real deployments.

Pilots Must Stop Dying After the Launch Photo

Malaysia loves pilot projects. We launch pilots with banners, speeches, handshakes, group photos, and sometimes a nice gimmick where someone presses a button on stage. I have nothing against pilots. A pilot is useful when it helps us learn, reduce risk, and prepare for wider adoption. But a pilot becomes wasteful when it ends at the launch photo.

Too many IoT pilots do not answer the most important questions. What did we learn? Did the system solve the original problem? Who used the data? What decision changed? What cost was reduced? What risk was avoided? What process improved? What failed? What should be changed before scaling? Can this model be repeated in another location?

If we cannot answer these questions, then the pilot was not a learning exercise. It was a performance. A good pilot must have a path to adoption. It must be designed with scale in mind, even if the first version is small. It must include training, maintenance, user feedback, support, and measurable outcomes.

Small pilots are fine. Small thinking is not.

Universities Must Raise the Standard

Universities have a major role to play because they are not just producing graduates. They are shaping how the next generation understands technology. If IoT is taught only as a technical connection exercise, students will graduate thinking that connectivity is the main achievement. But if IoT is taught as a complete system, students will begin to think like solution builders.

They will understand sensors, communication, platforms, data quality, cybersecurity, analytics, user needs, operations, and business value. They will learn that the real world is not as friendly as the lab. In the lab, the WiFi usually works. In the field, the signal disappears when you need it most. In the lab, the power supply is stable. In the field, someone may unplug the adapter because they need the socket. In the lab, the sensor is clean. In the field, it faces heat, rain, dust, insects, vibration, curious hands, and sometimes people who have no idea why the device is there.

This is why students need exposure to real problems. Let them work with local councils, farms, factories, hospitals, logistics companies, buildings, and campuses. Let them talk to actual users. Let them understand frustration, constraints, budgets, maintenance, and accountability. A student who has seen real operational pain will build differently. That student will not simply ask whether a value can appear on a dashboard. That student will ask whether the data can help someone act before the problem becomes worse.

That is the kind of graduate Malaysia needs.

Government and Industry Must Demand Outcomes

The responsibility is not only on universities. Government agencies, local councils, GLCs, enterprises, and private companies must also change how they buy and evaluate IoT. Do not buy IoT because it sounds modern. Do not install sensors because other cities have sensors. Do not ask for dashboards because dashboards look impressive in meeting rooms. Ask for outcomes.

Before starting an IoT project, the buyer should ask what decision the system supports, who will respond to alerts, how success will be measured, how the system will be maintained, how the data will be protected, and how the project will continue after year one. They should also ask what happens when the vendor is no longer standing beside the dashboard during a demo. That is where the truth normally appears.

This is where procurement must become smarter. If the tender only asks for devices and dashboards, the result will be devices and dashboards. If the tender asks for operational outcomes, response workflows, security design, data ownership, maintenance, training, and measurable impact, then vendors will have to design more serious solutions.

Malaysia must stop buying gadgets and start buying operational intelligence.

IoT Is a Long Term Commitment

Many people underestimate what happens after installation. The project is not finished when the devices are installed. In many ways, that is when the real work begins. Devices need monitoring. Sensors need calibration. Users need training. Alerts need tuning. Dashboards need improvement. Data needs review. Network issues need troubleshooting. Reports need refinement. Processes need updating. Budgets need planning.

IoT is not a one day event. It is a living system. This is why the final year project mindset is dangerous when applied to real deployments. In a student project, the goal is often to complete and submit. In a real deployment, the goal is to operate, improve, and sustain.

The system must still work after the excitement fades. It must still provide value when nobody is clapping. It must still help the user on an ordinary Tuesday morning when something goes wrong and people need answers fast. That is the true test of IoT. Not the demo. The ordinary day.

From Prototype Pride to Operational Discipline

We should still be proud of prototypes, but we should not stop there. A prototype is a question. A real deployment is an answer. A prototype asks whether an idea can work. A real deployment answers by showing how it improves operations.

Malaysia has enough prototypes. What we need now is discipline. We need discipline in defining problems, designing systems, securing devices, managing data, training users, measuring outcomes, scaling what works, and stopping what does not. This is not glamorous work. It may not look as nice as a launch ceremony, but this is where real progress happens.

Behind every useful IoT system, there are people doing boring but necessary things. They check data quality, fix device issues, improve alerts, train staff, review reports, update workflows, and make sure the system continues to serve the people who depend on it. That is how IoT becomes part of daily operations. Not through magic. Through discipline.

The Malaysia I Want to See

I want to see Malaysian students building IoT projects that do not disappear after final presentations. I want to see lecturers guiding students toward real world problems, not repeated versions of the same safe ideas. I want to see universities using local platforms and building stronger links with industry. I want to see local councils using IoT to manage floods, waste, parking, lighting, and public facilities more intelligently.

I want to see factories using IoT to reduce downtime and improve maintenance. I want to see farms using IoT to improve productivity and reduce waste. I want to see buildings using IoT to cut energy costs and support sustainability goals. I want to see local system integrators building reusable solutions instead of starting from scratch for every customer. I want to see Malaysia take IoT seriously as a foundation for AI, smart cities, and national competitiveness.

Most of all, I want us to stop underestimating our own ability. We have the talent. We have the problems. We have the technology. We have local platforms. We have universities. We have industries that need better data. What we need now is the courage to connect all of these pieces into something bigger.

IoT Was Never Meant to Stay on the Classroom Table

The blinking LED was never the final achievement. It was only the first sign that something could be connected. The real achievement comes when that connection creates awareness, that awareness leads to action, and that action improves lives, services, businesses, and national capability.

Malaysia must stop treating IoT as a final year project toy because the world has already moved on. IoT is now part of infrastructure, cybersecurity, AI, sustainability, smart cities, industrial growth, and operational decision making. If we continue treating it as a small student experiment, we will produce many demos but too few outcomes. That would be a waste, not just of components or project budgets, but of potential.

Maybe the problem is not that Malaysia lacks IoT projects, I thought to myself. Maybe the problem is that too many of them are never allowed to grow up.

So let us allow them to grow. Let us move IoT from the classroom table to the operations room, from assignment marks to measurable outcomes, from dashboards to decisions, from prototypes to platforms, and from toys to infrastructure. Malaysia does not need more blinking LEDs to prove that we can connect things. Malaysia needs connected systems that help us think, act, and build better.

What do you think? Are we ready to treat IoT as serious national capability, or are we still too comfortable celebrating prototypes that never leave the lab? I would love to hear your thoughts in the comments.

The Hidden Trap Destroying IoT Platforms: 3 Silent Mistakes Founders Don’t See Until It’s Too Late

Many IoT platforms began their journey with strong foundations. They had capable engineering teams, promising technology, and even early customer traction. In the early stages, everything appeared to be moving in the right direction.

Yet over time, many of these platforms quietly stalled. Some remained small niche products. Others slowly faded from the market.

The collapse rarely happened suddenly. It emerged gradually, almost invisibly.

From observing the evolution of many IoT platforms over the years, three recurring patterns often appear. These are what I refer to as the three silent killers of IoT platforms.

1. The “Nice Platform” Problem

The first and most common challenge is what I call the “Nice Platform” problem.

Technically, everything works as expected. Sensors transmit data. Dashboards display attractive charts. Connectivity is stable. Demonstrations during presentations look impressive.

Customers often respond with comments like, “This is very interesting.”

But the real question is much deeper than whether the technology works.

Is the platform essential to the customer’s operations?

Many IoT platforms unintentionally position themselves as helpful tools rather than critical systems. They focus heavily on features such as:

• dashboards
• device connectivity
• data visualisation

These capabilities are useful. They demonstrate the power of connected systems.

But organisations rarely allocate long-term budgets for visualisation tools alone.

Businesses invest in solutions that directly influence outcomes. What they are truly paying for are measurable results such as:

• reducing equipment downtime
• preventing operational accidents
• lowering energy consumption
• avoiding regulatory penalties
• increasing workforce productivity

When a platform is tightly connected to these outcomes, it becomes embedded in the customer’s daily operations. It becomes part of their operational backbone.

But when the platform only provides visibility without directly influencing decisions or actions, it remains optional.

And optional systems are the first to disappear when budgets tighten.

This explains why the most successful IoT deployments focus on mission-critical problems. Examples include:

• predictive maintenance in industrial environments
• fleet safety monitoring for logistics operations
• cold chain compliance for pharmaceutical distribution
• energy optimisation for large buildings

These systems cannot simply be turned off without significant operational consequences.

That is the difference between interesting technology and essential infrastructure.

2. The Customisation Trap

The second silent killer appears much later in the journey, often after the platform begins acquiring its first paying customers.

Early adopters frequently request modifications. They ask for specific dashboards, specialised workflows, or integrations with legacy enterprise systems.

At the beginning, these requests appear reasonable.

A startup needs revenue. The team wants to satisfy its customers. Agreeing to customise the platform seems like a practical decision.

However, a hidden risk gradually emerges.

Over time, the platform begins to fragment.

Instead of maintaining a single scalable product, the engineering team finds itself supporting multiple customer-specific versions:

• one version tailored for customer A
• another variation for customer B
• a different configuration for customer C

The product gradually shifts from a platform to a collection of bespoke solutions.

Engineering resources originally intended to improve the core platform are redirected to meet project-specific requirements.

At this stage, the business begins to resemble a consulting company rather than a product company.

The consequences are predictable:

• development cycles slow down
• engineering teams become stretched
• product direction becomes unclear
• operating margins shrink

Scaling becomes increasingly difficult because each new customer introduces new complexity.

Many IoT startups unintentionally move into this trap. They begin with a platform vision but gradually become project delivery organisations.

The strongest platform companies remain disciplined about this boundary.

They continuously ask a simple but critical question:

Is this a reusable product feature or a one-off project request?

If the capability cannot benefit many customers across different industries, it may not belong in the core platform.

Maintaining this discipline is difficult in the early stages when revenue pressure is high. Yet it is often the difference between building a scalable platform and building a services business.

3. The Ecosystem Illusion

The third silent killer relates to ecosystem development.

Many platform founders assume that once the platform is launched, developers and partners will naturally begin building solutions on top of it.

The belief is simple: build the platform first, and the ecosystem will follow.

In practice, ecosystems rarely grow automatically.

Developers and partners choose platforms based on several practical considerations:

• the size and activity of the ecosystem
• the availability of development tools and documentation
• the potential economic opportunity

The economic factor is frequently underestimated.

Developers invest their time where they can build sustainable businesses. If there is no clear revenue path, most will quickly move to other platforms.

This is one of the key reasons large ecosystems expanded rapidly. Platforms such as:

Amazon Web Services
Shopify
Salesforce
Apple

created strong developer communities by building clear economic incentives.

Developers could launch products, attract customers, and generate revenue through these platforms.

In many IoT platforms, the ecosystem layer is incomplete. APIs and SDKs are available, but the economic model is unclear.

For an ecosystem to grow meaningfully, partners must clearly understand:

• how they can generate revenue
• how easy it is to build solutions on the platform
• how large the addressable market is

Without these signals, the ecosystem remains limited.

Developers may experiment with the platform, but long-term commitment rarely materialises.

Why These Killers Are Difficult to Detect

One of the most dangerous aspects of these challenges is their subtle nature.

None of them produces immediate crises.

The company may still:

• secure new pilot projects
• receive industry recognition
• release new product features
• attract positive feedback from users

From the outside, everything appears healthy.

But internally, warning signs slowly emerge. Growth begins to plateau. Profit margins tighten. The product roadmap becomes fragmented.

Eventually, the platform struggles to reach the scale necessary to compete globally.

This pattern explains why many IoT platforms remain respectable but small companies rather than evolving into global infrastructure providers.

The difference between the two often lies not in technological capability but in strategic discipline.

For IoT platforms to achieve long term impact, they must move beyond attractive dashboards and connectivity features. They must anchor themselves in mission-critical outcomes, protect the integrity of their core product, and build ecosystems where partners can thrive economically.

Only then can a platform move from being an interesting technology to becoming part of the digital infrastructure that organisations truly depend on.

These lessons continue to shape how many leaders in connected systems approach platform strategy today, especially as IoT, AI, and edge computing converge to redefine how digital infrastructure is built and secured.

Building IoT Alone vs Building Together: Why Local Platforms Change Everything

I want to share something that has been sitting heavily in my heart for a while.

Every time I speak to engineers, lecturers, startups, or research teams, I ask a simple question.

“What IoT platform are you using?”

The answers came quickly.

From abroad.
From overseas.
From a big global brand.
Or… “We built our own server.”

I nodded. I smiled. But inside, something felt heavy.

Why are we still doing this to ourselves?
Why do we keep believing the best tools must come from somewhere else?

That moment stayed with me long after the talk ended

We Are Obsessed With Dashboards, But Forget the Foundation

Let me be honest.

Many IoT teams I meet are not obsessed with devices. They are obsessed with dashboards.

Big screens.
Live charts.
Green indicators that say “OK”.

Nothing wrong with that. Dashboards matter. Visibility matters.

But when I dig deeper and ask, “Who do you actually work with behind that platform?”
Silence.

They have never met the platform provider.
Never spoken to an engineer there.
Never sat down to plan a market together.

How do you build something meaningful when you do not even know who is behind the engine?

That is the first quiet weakness nobody talks about.

Depending on a Distant Platform Feels Safe. Until It Isn’t.

Using a foreign platform feels comfortable.

It feels established.
It feels global.
It feels like you are standing on something big.

But distance has a price.

No close collaboration.
No shared story.
No joint effort to help your product grow beyond a pilot.

When something breaks, you open a ticket.
When something stalls, you wait.
When you want to commercialise, you are on your own.

I thought to myself, is this really what building an ecosystem looks like?

Local Platforms Are Not “Second Choice”. They Are Strategic Choices.

This is where my heart always leans forward.

When a university, a startup, or a solution provider works with a local IoT platform like Favoriot, something changes.

You do not just get software.

You get people.
You get conversations.
You get arguments on whiteboards.
You get someone who cares because your success is their success, too.

We can sit together.
We can shape the solution together.
We can plan how it reaches the market together.

That closeness is not a luxury. It is a multiplier.

Cross-Marketing Is Not a Buzzword. It Is Survival.

Let me put this simply.

Your market is never big enough on its own.
Neither is mine.

But when we walk into each other’s markets together, something opens up.

Your customers see us.
Our users see you.
Stories start travelling.

If a project uses our platform, we talk about it.
We highlight it.
We share it across our channels.

And no, this is not charity.

It is shared growth.

I remember thinking, why should every company shout alone when we can amplify each other’s voices?

Bundling Is About Completing the Story, Not Selling More Stuff

Here is another truth most people avoid.

Almost nobody builds everything themselves.

You may focus on air quality.
But your hardware comes from overseas.
Your connectivity comes from someone else.
Your cloud might sit on Azure or AWS.

That is normal.

What matters is how these pieces come together for the customer.

A single product often feels incomplete.
A bundled solution feels finished.

Your sensor plus our platform.
Your analytics plus our alerts.
Your service plus our visibility.

The customer does not want components.
They want relief.
They want clarity.
They want answers.

Bundling is not about pushing more.
It is about removing friction.

Ego Is the Silent Killer of IoT Ecosystems

This is the part that makes people uncomfortable.

Ego.

The belief that “we can do everything ourselves.”
The fear that collaboration means losing control.
The worry that sharing space means shrinking your brand.

I have seen this mindset slow down brilliant teams.

I told myself, collaboration is not surrender.

Working with partners does not make you smaller.
It makes you reachable.

It gives you angles you cannot create on your own.

Universities, Startups, Platforms. We Need Each Other.

Universities have ideas.
Startups have hunger.
Platforms have structure.

Separately, we struggle.
Together, we move.

When a university builds a project on a local platform, that project does not end as a report.
It becomes a case study.
A reference.
A stepping stone to something real.

When a startup launches on a local platform, it does not just deploy.
They learn how to sell.
How to explain value.
How to survive their first customers.

I often whisper to myself, this is how ecosystems are supposed to feel.

Why This Matters More Than Ever

We talk about national capability.
We talk about digital sovereignty.
We talk about nurturing local champions.

But these words mean nothing if we keep outsourcing belief.

Supporting local platforms is not about patriotism.
It is about practicality.

Local platforms understand local constraints.
Local regulations.
Local customers who call you at 2 a.m.

And when you grow, they grow with you.

A Quiet Invitation

If you are building IoT solutions today, pause for a moment.

Ask yourself:

Who do I actually collaborate with?
Who knows my product beyond a ticket number?
Who will walk with me to the market?

If the answer feels distant, maybe it is time to rethink.

Not to abandon global tools.
But to anchor your growth closer to home.

I believe ecosystems are built by hands that reach out, not by fingers that point outward.

Let us talk.
Let us partner.
Let us bundle, cross-promote, and craft stories that travel beyond dashboards.

Contact Favoriot and let’s build IoT solutions together.

I would love to hear your thoughts.
Share your experience in the comments.

I Started a Startup at 56. This Is What the Journey Really Taught Me.

Techtamu Talk | 17 January 2026

On 17 January 2026, at around 10 in the morning, I stood before a room full of students, founders, and curious minds.

Before I spoke, I paused for a second.

“How do I explain a journey that never followed a straight line?”

Entrepreneurship, at least in my life, was never a planned destination. It was a series of connected experiences that only made sense much later.

That lecture was not about IoT.
It was not about startups.
It was about life, timing, courage, and knowing when to let go.

You Only Understand the Journey When You Look Back

I opened the session with a quote from Steve Jobs that has stayed with me for years:

You can’t connect the dots looking forward. You can only connect them looking backward.

That sentence explains my life better than any resume ever could.

When you are young, you worry too much about choosing the “right” path. The right course. The right job. The right company.

What nobody tells you is this.
Every experience counts, even the ones that feel like detours.

You just won’t see it yet.

From a Curious Child to a Technology Lifelong Learner

My interest in technology did not start in a lab or a classroom.

It started at home.

My late father was a clerk. But in the evenings, he repaired televisions and radios. I would sit beside him, watching circuits come back to life.

“So this is how things work.”

Then came science fiction.

Cartoons like The Jetsons showed a future that felt impossible at the time. Video calls. Smart watches. Flying machines.

Today, many of those ideas sit quietly in our pockets.

That early exposure planted a question in my mind that never left me.

“What if we could actually build these things?”

Living in Four Different Worlds

I consider myself fortunate. Few people get to experience all four.

Academia.
Corporate.
Government.
Startup.

I began as a lecturer at Universiti Teknologi Malaysia, immersed in theory and research. Later, I joined the corporate world at Celcom, where reality hits hard and fast. Customers matter. Deadlines matter. Revenue matters.

At MIMOS, I worked on national-scale research, including wireless sensor networks, long before the term IoT became popular.

Then came REDtone, where I helped build IoT initiatives inside a corporate structure.

Each world taught me something different.

But they also gave me baggage.

Experience gives confidence.
It also gives fear.

Young founders often believe everything is possible.
Older founders carry doubt.

“What if this fails?”
“What if I lose my savings?”

That voice gets louder with age.

Silicon Valley Changed Everything

At 56, I joined an immersion trip to Silicon Valley.

That trip changed my identity.

I walked into Plug and Play Accelerator and saw cubicles, whiteboards, and founders who looked just like us. That was where companies like Dropbox began.

I remember thinking:

“If this guy can do it, why can’t we?”

That was the moment I stopped seeing myself as a CEO-in-waiting.

I started seeing myself as an entrepreneur.

Not someday.
Not after retirement.
Now.

Starting Late Comes With a Price

I started my startup using personal savings. No incubator. No startup playbook. No fancy terms like ‘MVP’ or ‘pitching decks’.

Just belief and experience.

Our first idea was a smartwatch for the elderly with fall detection and emergency alerts. It looked noble. It sounded meaningful.

It failed.

The market was too small.
Children did not want to pay.
The device did not suit care homes.

That was my first real startup lesson.

Good intentions do not build businesses.
Paying customers do.

Learning the Art of the Pivot

In the startup world, pivoting is survival.

We repurposed the watch for Hajj and Umrah pilgrims. New market. Same core idea.

New problems appeared.

Unrealistic pricing expectations.
Battery life demands that defy physics.
Hardware sourcing from China.
Network roaming issues.
Travel agencies are unwilling to add cost.

Then came COVID-19. We proposed quarantine monitoring. It went nowhere.

Eventually, I made one of the hardest decisions of my life.

Ending a product.

I shared this honestly during the lecture.

Ending a product feels like ending a child you raised with love.
But holding on too long can kill the company.

A CEO must choose growth over attachment.

When More Products Mean Less Identity

We built other solutions too.

A civic complaint app sounded promising. Until each client wanted heavy customization and complaint volumes exploded beyond what they could manage.

A consumer tracking app failed because people care deeply about privacy and free alternatives already exist.

At some point, I realized something painful.

When you build too many products, people no longer know who you are.

Neither do you.

The Shift That Saved the Company

That realization led to our biggest change.

We stopped building products for users.

We started building a platform for builders.

That platform became Favoriot.

An IoT platform that lets others connect devices, visualize data, and deploy solutions quickly. Over time, intelligence was added so data could speak, not just sit on dashboards.

This shift reduced risk.

Instead of betting on one product, we enabled hundreds of use cases.

Why One Revenue Stream Is Never Enough

Another hard truth I shared with the audience.

Pure SaaS subscriptions rarely pay the bills in emerging markets.

We survived by building multiple streams.

Enterprise licensing.
Project-based solutions.
Training and certification with universities.

The platform stayed at the core. Everything else wrapped around it.

That balance kept the company alive.

Partners Build What You Cannot

No startup wins alone.

We built a partner ecosystem covering hardware, software, AI, and system integration. Today, that network spans multiple countries.

Each partner brings strength we do not have.

That is how scale really happens.

Marketing Without Big Budgets

We never had large marketing budgets.

So we wrote.
We shared.
We taught.

Blogs.
Social media.
Free e-books.

Inbound marketing works when your story is honest and your knowledge is real.

People do not buy immediately.
But they remember.

The Lesson I Hope You Carry Forward

I ended the lecture with a simple reminder.

Whatever path you take, it is building something inside you. Even when it feels random.

Do not fall in love with your product. Fall in love with solving problems.
Do not trust praise until someone pays.
Do not depend on one revenue stream.
Do not fear pivoting. Fear standing still.

And most of all, do not believe it is too late.

I started my startup at 56.

If I could begin then, what is stopping you now?

I would love to hear your thoughts.
What dots in your life are starting to connect? Share them in the comments.

The Story Behind Favoriot – Part 19: How the Law of Attraction Shapes Favoriot’s Future

The Imagination That Built Favoriot

Imagination is often dismissed as a whimsical exercise, yet it’s the spark that ignites progress. The world we live in today was once imagined by someone who dared to think beyond what was possible. Reflecting on Favoriot’s journey, I realize how important it is to dream about the future we want to create.

I believe in the Law of Attraction—the idea that what we think and visualize with intent can manifest into reality. When we first started Favoriot, we imagined a future where our platform would power smart cities, empower students, and become a global name in IoT. Some might have called it wishful thinking. But imagination, when combined with action and persistence, can shape reality.

Let me take you on a journey through an imagined future where Favoriot’s influence has transcended borders, industries, and expectations. This is not just a daydream. It’s a vision we are working tirelessly to turn into reality.

A Vision of Favoriot’s Future

I close my eyes and transport myself into the future. I enter a massive IoT trade exhibition akin to CES or the World Smart City Expo. The atmosphere is electric with innovation. Companies from around the world have gathered to showcase their latest technologies. As I navigate the exhibition hall, one thing becomes apparent: the Favoriot logo is everywhere.

Booth after booth, exhibitors proudly display their demos powered by the Favoriot IoT platform. Startups with groundbreaking hardware solutions, companies showcasing futuristic smart city concepts, and AI-driven IoT applications are all seamlessly connected through Favoriot.

But why? Why did they choose Favoriot? It’s not just a platform. It has become the trusted backbone for innovation, synonymous with reliability and scalability. I feel an overwhelming sense of pride in seeing this unfold in real time. This is the world we imagined when we first built Favoriot: a world where our platform is the silent enabler of extraordinary solutions.

The Power of Favoriot in Education

My next stop in this imagined world is a university. Favoriot has become a standard name here—not just a tool but a core part of the curriculum.

In lecture halls, professors discuss real-world IoT case studies, and students dive deep into hands-on learning, exploring the potential of IoT using the Favoriot platform. I peek into a lab where students are working on their final-year projects. A team is developing a smart agriculture solution, leveraging Favoriot to monitor soil conditions and automate irrigation. Another group is focused on smart health, creating wearable devices for chronic disease management and using Favoriot’s analytics features to visualize patient data.

It’s exhilarating to see how a tool we created has become the foundation for nurturing the next generation of IoT innovators. Universities nationwide and internationally now teach IoT through Favoriot. Their labs are equipped with pre-configured dashboards, APIs, and datasets, making it easy for students to start building. What was once a platform we envisioned for businesses has become an educational cornerstone. Students graduate not only with degrees but as skilled Favoriot-certified IoT professionals.

This didn’t happen by accident. It was imagined, desired, and, through our efforts, made a reality.

Transforming Cities with IoT

As I step into a local council’s command centre, I see a vibrant dashboard powered by Favoriot. The screen displays real-time data from various IoT solutions deployed throughout the city: smart streetlights, waste management sensors, flood detection systems, and air quality monitors.

This isn’t just a collection of disconnected systems—it’s an integrated platform that combines everything under one roof.

The mayor stands beside me, explaining how this has revolutionized the council’s operations.

“Favoriot has helped us move from reactive to proactive,” she says. “We no longer wait for complaints; we solve problems before they arise.”

I imagined this when we spoke about smart cities years ago—a city where data drives decision-making, not just to improve efficiency but to genuinely enhance the quality of life for its citizens.

Favoriot isn’t just another vendor in this ecosystem—it’s the platform that local councils trust to aggregate and analyze IoT data, bridging the gap between diverse solutions and actionable insights.

Again, this was once a dream, an idea that many doubted. But here it is, functioning as imagined, because we believed in its possibility.

The Future of IoT Businesses

IoT product companies no longer struggle to create end-to-end solutions. Instead, they focus on what they do best—building world-class hardware or cutting-edge AI applications. Favoriot fills the gap by providing a robust platform to manage data collection and analysis.

Imagine a company specializing in healthcare sensors. Instead of spending years developing its own platform, it uses Favoriot to connect its devices. This shortens its time-to-market, and its customers benefit from a complete solution that’s both scalable and user-friendly.

The same goes for system integrators who rely on Favoriot to simplify IoT deployments for their clients. Some have taken this even further by offering managed IoT services. With Favoriot, they provide their clients with dashboards, analytics, and customized solutions without the technical headache of building everything from scratch.

It’s a win-win: the integrators expand their business offerings, and Favoriot becomes the go-to platform for IoT scalability.

Expanding Globally Through the Law of Attraction

The most exciting part of this imagined future is Favoriot’s global footprint. We have partnered with system integrators and distributors across continents, allowing us to enter new markets quickly.

In Indonesia, a partner uses Favoriot to enable advanced agriculture systems. In Europe, we’re powering smart transportation initiatives. In Africa, Favoriot is the backbone of rural healthcare IoT solutions.

These partnerships aren’t just transactional; they’re built on a shared vision of what IoT can achieve. By empowering local players in each market, Favoriot has become a global name synonymous with IoT excellence.

How did we reach this level? By first believing in it. The Law of Attraction teaches that whatever we focus on grows. We visualized this expansion, worked towards it, and attracted the right people and opportunities to make it happen.

A Dream Becoming Reality

I close my eyes and imagine standing on a stage at a significant IoT event. The lights dim, and a video showcases real-world success stories of Favoriot-powered solutions. The impact is tangible, from smart cities to healthcare and agriculture to education.

As I speak, I’m reminded of how far we’ve come—as a company and as a community of dreamers and doers. Favoriot’s success wasn’t just about technology but about believing in the power of imagination.

We imagined a world where IoT could truly transform lives when we started. Today, in this envisioned future, that world has come alive.

So, is it wrong to imagine? Absolutely not.

Imagination is where dreams take shape, and the seeds of innovation are planted. As I look at Favoriot’s journey—from a small startup to a global IoT leader—I know that it all started with a simple yet powerful idea: to imagine the impossible and make it real.

Will this vision come true? I believe it will. Because imagination, when paired with hard work, resilience, and the right team, can achieve wonders.

So, let’s keep imagining, dreaming, and building the future—one step at a time.