Tag: AI

Social Media, Business, and the Invisible War Every Founder Must Learn to Fight

Long before I became a founder, I was already experimenting with social media, not because it was fashionable, not because someone told me personal branding would become important, and not because I had a grand strategy written neatly inside a notebook, but because I could sense that these platforms were quietly changing the way people discovered ideas, trusted experts, followed companies, and made decisions.

It started with Twitter, then Facebook came along, followed by YouTube, LinkedIn, Instagram, and later TikTok and Threads, and with every new platform I joined, I found myself learning the same painful but useful lesson: every platform has its own behaviour, its own audience, its own rhythm, and its own strange way of rewarding or punishing your content.

There were no formal classes for me, no coach sitting beside me, no step-by-step manual that said, “Mazlan, this is exactly how you should build your voice online.” I learned the old-fashioned way by reading, testing, failing, adjusting, and trying again, which sounds noble now, but at that time, it was mostly trial and error with a lot of silent head-scratching in between.

When FAVORIOT started to grow, social media was no longer just a personal space where I shared thoughts, opinions, and reflections. It became part of the business itself, and suddenly I was not only speaking as Mazlan Abbas, the person, but also carrying the voice of FAVORIOT, the company, the brand, the team, and the mission we were trying to build.

That was when things became complicated.

I thought to myself, “So now I have to be myself, represent the company, educate the market, promote the product, build trust, and still sound human at the same time?”

Yes, apparently.

And I had to do all of that while running a startup.

When Social Media Starts Feeling Like a Battlefield

At one point, managing social media felt like being a soldier defending too many frontlines at the same time, because LinkedIn wanted professional insights, Facebook preferred a more personal tone, X rewarded sharp and quick comments, TikTok demanded visual storytelling, Threads wanted casual conversations, Instagram needed strong visuals, and YouTube required patience, planning, and a completely different level of commitment.

Every platform seemed to ask for something different, yet all of them demanded the same thing from me: time, attention, consistency, and energy.

The difficult part was not just posting. Anyone can post. The real challenge was knowing what to say, how to say it, where to say it, and which version of myself should be speaking.

For my personal account, people followed me because they wanted my thoughts, my stories, my experiences, and my reflections. They wanted to see the human side of the founder, not a walking advertisement. For the FAVORIOT account, the expectations were different because the company needed to sound clear, professional, relevant, and trustworthy to customers, partners, developers, investors, universities, and the wider IoT community.

That was where the first real problem appeared: mixed messaging.

The Fine Line Between Personal Voice and Company Voice

The line between a founder and the company can become blurry, especially in a startup where the founder’s face, voice, reputation, and personality are often tied closely to the brand, and while this can be powerful, it can also create confusion if we are not careful.

Whenever I posted too much business content on my personal account, engagement usually dropped because people did not follow me just to receive product updates. They followed me because they wanted perspective, stories, lessons, observations, and sometimes a little honesty about what it really feels like to build something from the ground up.

At the same time, if the company account became too personal, it risked weakening the professional image of the brand, because a company page must serve a different purpose. It must help customers understand what the company does, why it matters, how it solves problems, and why people should trust it.

This was not just a technical content issue. It was an identity issue.

Before pressing publish, I often had to ask myself, “Am I speaking as Mazlan, or am I speaking as FAVORIOT?”

That small question became very important, because personal branding and company branding may support each other, but they should not become the same thing. A personal account earns attention through authenticity, while a company account earns trust through clarity.

“Your personal account earns attention through authenticity. Your company account earns trust through clarity.”

It took me years to truly understand that, and even now, I still remind myself of it whenever I prepare content for different platforms.

The Hardest Battle Is Still Time

If anyone asks me what the biggest challenge is in managing social media as a founder, my answer is very simple: time.

Many people assume content creation means typing a few lines, adding a nice image, and clicking publish, but anyone who has done it seriously knows that one good post can involve research, choosing the right angle, writing the hook, shaping the message, checking the tone, preparing visuals, proofreading, deciding where to post, adjusting the format for each platform, and then monitoring the response after it goes live.

Now multiply that by several platforms.

Then multiply it again by two accounts, one personal and one company.

Then add meetings, proposals, customer follow-ups, speaking engagements, product discussions, investor conversations, staff matters, and the never-ending demands of running a startup.

That is when social media stops looking like a simple marketing activity and starts feeling like another full-time job quietly hiding inside your actual full-time job.

There were moments when I honestly felt like shutting everything down and focusing only on the “real work,” but each time that thought appeared, another thought answered it almost immediately.

“But this is part of the real work now.”

That is the reality for founders today, because social media is no longer optional if you want people to discover you, understand you, evaluate your credibility, and eventually trust you enough to have a serious conversation.

A startup can have a good product, a committed team, and a powerful vision, but if nobody sees it, hears about it, or understands it, the market may assume that nothing much is happening.

And that is dangerous.

Doing Everything Alone Can Drain You Quietly

For a long time, I handled most of the social media work by myself, which meant writing, editing, posting, choosing angles, creating variations, checking responses, replying to comments, and thinking about how to balance the personal voice with the company voice.

From the outside, people only see the final post, but they do not see the hesitation behind it, the drafts that never get published, the captions that are rewritten five times, the posts that are deleted because they do not feel right, or the late-night moment when you stare at the screen and wonder whether the message is useful or just noise.

Founders know this feeling very well.

We are not only building products. We are also building trust, visibility, confidence, and a story that the market can understand.

Many times, we do this with limited people, limited budget, limited time, and limited emotional energy, yet social media continues to demand freshness, consistency, and relevance as if we have a large content department hiding somewhere inside the company.

I thought to myself, “If people knew how much effort goes into one simple post, maybe they would forgive me for occasionally disappearing.”

But the market rarely forgives silence for too long.

If you disappear, people forget.

If you only appear when you want to sell, people resist.

If you post without direction, people get confused.

That is why founders need not only content, but also a system.

Then AI Changed the Way I Work

When AI tools like ChatGPT arrived, my content process changed in a major way, not because AI replaced my thinking or my voice, but because it helped me organise what I already had inside years of writing, speaking, presenting, and explaining.

Before AI, I wrote almost everything from scratch, and that meant every post felt like a new battle with a blank page. Now, I can start from existing material: old blog posts, keynote notes, training slides, customer questions, proposal ideas, or reflections from past experiences.

Over the years, I had written many articles on IoT World and my personal blog, and those articles were filled with experience, analysis, stories, opinions, and lessons that were still relevant. What I did not fully realise before was that all of that content was not old material. It was a content bank waiting to be reused.

A single blog article can now become several Threads posts, a polished LinkedIn article, a casual Facebook update, a short video script, a newsletter idea, or even a talking point for a presentation. The main idea remains the same, but the structure, tone, and length can be adjusted for each platform.

That saved me a lot of time.

More importantly, it reduced the pressure of always creating from zero.

I thought to myself, “Why should I keep starting from an empty page when I already have years of thoughts sitting quietly in my blog?”

That was a turning point.

AI gave me a better rhythm, but it did not remove my responsibility. I still had to decide what mattered, what should be published, what should be edited, what should be removed, and whether the final content sounded like me.

AI can help shape the clay, but the clay must still come from real experience.

“AI should not replace your voice. It should help your voice travel further.”

That is how I see it, because the danger is not in using AI, but in allowing AI to make us sound like everyone else.

Your Old Content May Be More Valuable Than You Think

Many founders underestimate the value of what they already have, because they assume content must always be new, fresh, and created from scratch, when in reality, some of the best content comes from old ideas explained in a clearer and more current way.

Old blog articles can become new social media posts.

Past presentation slides can become short educational content.

Customer questions can become articles.

Training notes can become carousels.

Proposal explanations can become LinkedIn posts.

Mistakes can become lessons.

Founder reflections can become trust-building stories.

Even a simple WhatsApp explanation to a customer can become the seed of a good post, because if one person asked that question, many others may be thinking about the same thing silently.

The key is to stop looking at content as a one-time activity.

Content should be treated like an asset.

You create it once, then reshape it, reuse it, update it, and distribute it in different ways depending on the platform and audience.

This is where AI becomes useful, because it can help turn raw material into different formats quickly, but the source must still be yours. Your voice, your judgement, your stories, and your understanding of the audience cannot be outsourced completely.

AI can help you move faster, but it should not make you disappear from your own content.

Lessons I Learned From Managing Personal and Business Accounts

After many years of managing both personal and company social media accounts, I have learned that clarity is more important than volume.

The first lesson is to separate the purpose of each account. Your personal account should carry your stories, reflections, opinions, values, and human experiences, while your company account should focus on customer problems, product value, use cases, industry education, credibility, and business outcomes.

The second lesson is to build a content bank before you need it. Do not wait until you are tired, busy, or under pressure before thinking about what to post, because that is when content becomes stressful. Save ideas continuously, collect useful questions, keep links to your old articles, and record your best explanations when they appear naturally.

The third lesson is to use AI as an assistant, not as a replacement. Let it help with structure, tone, rewriting, repurposing, and idea expansion, but never surrender your judgement, because AI may produce words, but only you know whether those words carry the right meaning for your audience.

The fourth lesson is to master one or two platforms first instead of trying to be everywhere at the same time. Many founders try to appear on every platform and end up weak on all of them, when they should first understand where their audience spends time and what kind of content works best there.

The fifth lesson is to respect the character of each platform. LinkedIn is suitable for professional insights and deeper reflections, Facebook allows a more personal touch, Threads feels more conversational, TikTok needs visual storytelling, and YouTube rewards those who can explain ideas with patience and consistency.

The sixth lesson is to measure what matters. Likes and views are pleasant, but meaningful comments, direct messages, serious enquiries, partnership discussions, speaking invitations, and sales leads are much better signals that your content is creating real value.

The seventh lesson is to accept that consistency matters more than perfection. A steady flow of useful and honest content is more powerful than one perfect post every few months, because people trust those who show up repeatedly with something worth saying.

Social Media Is a Marathon, Not a Firework Show

Social media is not a one-week campaign, a single viral post, or a magic trick that suddenly turns a quiet startup into a famous brand overnight. It is a long game of showing up, learning from your audience, improving your message, and staying visible without becoming a slave to the algorithm.

Some posts will perform well.

Some will disappear quietly.

Some will attract customers.

Some will attract critics.

Some will open doors you never expected.

Some will teach you what your audience truly cares about.

That is part of the process.

The founders who survive social media are not always the loudest or the most polished. Many times, they are the ones who know how to pace themselves, reuse their content wisely, protect their energy, stay clear about their message, and keep showing up even when the response is not immediate.

After all these years, I am still learning.

I am still experimenting.

I am still adjusting.

But now, with AI beside me, I no longer see social media as a monster waiting to eat my time. I see it as a set of channels that can carry my thoughts, my work, and FAVORIOT’s story to the people who need to hear it.

Not perfectly.

But consistently.

And for a founder, consistency is already a very big win.

So let me ask you this.

Are you managing your personal and business social media accounts on your own, or do you already have a team helping you? What has been your biggest challenge so far?

Share your experience in the comments.

Source based on the uploaded text.

I Used AI to Write My Latest eBook. Here’s What Actually Happened.

Let Me Be Honest With You

The eBook you are looking at right now, Mastering IoT and AIoT with Favoriot, was built with AI. Not just assisted by AI. Built by it. And I think that is worth talking about honestly, because the story of how this book came together tells you more about where we are with AI than any think piece I could write.

Here is the confession: most of the infographics inside were generated through ChatGPT. The eBook itself was assembled using Claude Cowork. I pointed it at my folder of infographics, and it categorised them, selected the best visual style, and structured everything into a coherent ladder from awareness to mastery. And the post you are reading right now? Claude is pushing it automatically to this blog.

I did not type all of this. AI did a significant part of the heavy lifting.

So Why Am I Telling You This?

Because I think the dishonest version of this story, the “I wrote a book” version with no footnotes, does everyone a disservice. We are at a moment in technology where the tools are genuinely extraordinary, and pretending otherwise is a form of intellectual cowardice.

But here is the thing I want you to sit with: the book is real. The frameworks inside it are real. The five rungs, Awareness, Foundations, Methodology, Production, and Mastery, those came from twenty-plus years of watching IoT projects succeed and fail. They came from UTM, CELCOM, MIMOS, from REDtone IoT, from every Favoriot deployment where a client came to us six months too late because they had skipped Rung 2.

The AI did not invent the Build-Readiness Ladder. I did. The AI helped me package it.

And I think that distinction matters enormously, not just for me, but for anyone trying to figure out how to use these tools without losing themselves in the process.

Every Buzzword Wave Brings the Same Temptation

I have been in IoT long enough to remember when “digitisation” was the buzzword that made executives nod without understanding. Then it was “big data.” Then “Industry 4.0.” Now it is AI everywhere. Each wave brings the same temptation: to let the tool become the story instead of the outcome.

What I tried to do with this eBook, and what I try to do with every piece of content I create, is stay anchored to the practitioner’s reality. Not theory. Not a showcase of what the technology can do in a lab. What actually ships. What actually fails. What the team on Rung 3 needs to hear at 11pm when their deployment is fighting them.

That is what I hope the five rungs give you. A ladder you can put your weight on.

Here Is Exactly How the AI Toolchain Worked

I want to be specific because I think the specifics are useful.

The infographics came first, from ChatGPT. I gave it the concepts, the frameworks, the key messages, and it generated visuals that I reviewed and curated. Some were brilliant on the first attempt. Some took five iterations. A few I threw out entirely because they were technically wrong, and that is the part that requires a human who actually knows IoT. The tool has no idea whether MQTT is correctly positioned in an architecture diagram. I do.

Claude Cowork then looked at the full collection, forty-three diagrams, and did something I genuinely did not expect it to do well: it read the logical progression across them. It understood that the Awareness diagrams should open the book, that the Production use cases belong after the methodology chapter, that the Data Storytelling infographic is the bridge between Rung 4 and Rung 5. It organised the ladder better than my first draft did.

Is that intelligence? I do not know. But it was useful, and I am not going to pretend it was not.

What AI Cannot Do

If you are an IoT practitioner reading this, the lesson is not “use AI to write your book.” The lesson is that your expertise, your hard-won, field-tested, scar-tissue knowledge, is the thing AI cannot generate. It can package. It can structure. It can format and distribute. But the rung-by-rung logic inside this eBook? That came from doing this work for two decades.

That is what I want to give you. Not a showcase. A ladder.

Now It Is Your Turn

Download the eBook. Start at the rung that makes you uncomfortable, that is always the right one. And if you want to talk through where you are standing, find me on LinkedIn or drop me a message through Favoriot.

The tools changed. The climb has not.

What rung are you on right now, and what is keeping you there?

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.

The Day I Realised I Was Becoming a Human FAQ

There was a time when I actually felt proud every time someone asked me about Favoriot.

Each question felt like a small victory.

It meant people were noticing.
It meant the story was spreading.
It meant our work was reaching somewhere beyond our small team.

Someone would message me.

“What exactly is Favoriot?”
“Is it just a dashboard?”
“Can it connect to this device?”
“How is it different from AWS IoT or ThingsBoard?”
“Do you support AI?”
“Can students use it?”
“Is it for smart cities, or factories, or farms?”

And every time, I replied.

Patiently.

Sometimes through WhatsApp.
Sometimes through LinkedIn messages.
Sometimes through emails that arrived late at night.

Okay, Mazlan… this is good, I told myself.
It means people are interested.

So I kept answering.

Again.

And again.

And again.

Until one day, after probably the hundredth explanation, I suddenly paused.

I stared at my laptop.

Then I asked myself a question that hit me harder than I expected.

Wait… am I building a technology platform… or am I becoming a human FAQ?

That was the moment something clicked.

A small but powerful realisation.

This was not really about repeating answers.

It was about something deeper.

Energy.

Focus.

And scale.

Because if the story of Favoriot only lives inside my head, then every explanation will depend on me personally.

And that is not scalable.

That night, I realised something important.

When people keep asking the same question, it is not a problem.

It is a signal.

A signal that your story is not documented clearly enough.

A signal that your knowledge is trapped inside conversations.

A signal that your platform needs a voice that can speak even when you are asleep.

That was my first aha moment.

The Emotional Side of Repeating Yourself

Let me be honest.

There were moments when I felt tired.

Not angry.

Not irritated.

Just mentally drained.

Imagine explaining the same thing dozens of times.

Sometimes, even after giving a talk or presentation.

For example, after speaking at events like The Star Cybersecurity Summit, where I was invited to share thoughts about IoT systems, AI, and the future of connected technologies, people would still approach me afterwards and ask the exact same question.

“So… what exactly does Favoriot do?”

Part of me almost laughed.

Did I not just explain that on stage for half an hour?

Then another voice in my head replied.

Relax Mazlan. Every audience is new.

Every listener hears things differently.

Every person arrives with a different level of understanding.

Some are engineers.

Some are students.

Some are policymakers.

Some are just curious.

And none of them is wrong for asking.

That was my second realisation.

Repetition is not the enemy.

Confusion is.

If people keep asking the same question, it simply means the explanation has not reached them in a form they can digest.

And that responsibility sits on my shoulders.

The Turning Point

One evening, while replying to yet another email asking the familiar question, I suddenly stopped typing.

I leaned back in my chair.

Why am I answering this privately again?

Then another thought appeared.

Why not answer it publicly once… and let it help hundreds of people instead of one?

That thought changed everything.

Instead of seeing repeated questions as interruptions, I began seeing them as content ideas.

Every repeated question was actually a signal about what people wanted to understand.

If five people ask the same thing, it deserves an article.

If ten people misunderstand a feature, it deserves a tutorial.

If customers keep comparing Favoriot with other platforms, it deserves a structured explanation.

That was the moment I started writing more seriously on IoT World.

Not random thoughts.

Not marketing slogans.

But clear explanations.

What exactly is the Favoriot Insight Framework?

How Favoriot moves from raw data to meaningful decisions.

Why IoT is not just about dashboards.

How universities can build AIoT labs.

Why local councils struggle with smart city projects.

How system integrators can deploy IoT faster.

Each question became an article.

Each doubt became a story.

Each confusion became clarity.

And slowly, something magical happened.

Instead of repeating myself endlessly, I started sending links.

“You might want to read this article.”
“This explains the architecture clearly.”
“This post shows the use case.”

The conversation immediately became deeper.

People no longer start from zero.

They started with understanding.

Building Something Bigger Than Myself

But something else happened, too.

After publishing several articles, people began asking another question.

“Is there one place where we can read everything about Favoriot?”

I smiled when I heard that.

Alright, Mazlan… now the next step is obvious.

That was when the idea of a Favoriot Resources Page was born.

Not a marketing page.

Not a product brochure.

But a knowledge hub.

A place where people can explore the ecosystem properly.

A place where they can learn at their own pace.

On that page, anyone can now explore:

What Favoriot really is
Tutorials and technical guides
Real IoT project challenges
Case studies and architecture explanations
The Favoriot Insight Framework
AI and IoT integration concepts
Videos and learning materials

I wanted it to feel like a digital campus.

Because Favoriot is not just software.

It is an ecosystem.

And ecosystems require structure.

They require stories.

They require documentation.

Without those elements, people only see fragments.

With them, people see the full picture.

The Hidden Lesson for Founders

Many startups face this same challenge.

We assume people understand our product.

We assume our website is clear.

We assume our explanation is good enough.

Most of the time, it is not.

People are busy.

They skim.

They scan.

They make assumptions.

And sometimes those assumptions are completely wrong.

So when people keep asking the same question, the worst reaction is frustration.

The better reaction is curiosity.

Ask yourself:

Why is this still confusing?

Which part of my explanation is missing?

How can I make this easier to understand?

Repeated questions are feedback.

Free feedback.

Valuable feedback.

And if you listen carefully, they tell you exactly what your audience needs.

When the Story Finally Clicked

After writing consistently and building the Resource page, I noticed something interesting.

My explanations became sharper.

Writing forces you to think clearly.

When you write publicly, your ideas become structured.

And suddenly the narrative becomes easier to communicate.

People begin to see the bigger picture.

They understand that Favoriot is not just a tool.

It is a framework.

It is an ecosystem.

It is a learning platform.

It is an AIoT foundation.

Without structure, that sounds confusing.

With structure, it becomes powerful.

The Resource page helped me connect the dots.

From devices to cloud ingestion.

From data streams to analytics.

From rule engines to AI insights.

From dashboards to decision intelligence.

That clarity changed everything.

The Unexpected Reward

Today, people still ask questions.

Of course they do.

And I welcome them.

But the feeling is different now.

Instead of feeling drained, I feel grateful.

Because each question tells me that someone is curious.

Someone is exploring.

Someone wants to understand.

And now I have something meaningful to share.

Not just an answer.

A pathway.

When someone tells me,

“I read your Resource page, and now I understand what Favoriot is.”

That feels incredibly satisfying.

More satisfying than closing a sale.

Because understanding builds trust.

Trust builds relationships.

And relationships build ecosystems.

The Aha Moment

Looking back, I now see that the repeated questions were never the problem.

They were actually guiding me.

They were telling me exactly what needed to be documented.

Exactly what was needed was clarity.

Exactly what was needed was storytelling.

And once I finally organised all that knowledge into structured content, something powerful happened.

The pressure disappeared.

The message became scalable.

And the story of Favoriot could travel further than my own voice.

That was my real aha moment.

When people stop depending on your explanation and start learning from your ideas, you know something meaningful has been built.

Favoriot is not just about connecting devices.

It is about connecting understanding.

And that journey started with a simple realisation.

Sometimes, the most annoying repeated questions are actually the best teachers.

Now I am curious.

Have you ever experienced the same situation in your own journey?

People asking the same question again and again?

What did you do about it?

Did it frustrate you, or did it push you to build something better?

FAVORIOT Resources

From Classrooms to Critical Operations: The Truth About Favoriot’s Enterprise Role

They Thought Favoriot Was Just for Students.

I Let That Misunderstanding Linger for Too Long.

I need to admit something first.

This one is on me.

For years, people have come up to me and asked a question that always makes me pause.

“Dr Mazlan, is Favoriot only an education platform?”

Every time I hear that, I smile politely. I explain. I clarify. I move on.

But deep inside, I talk to myself.

How did we let this idea stick for so long?
Why didn’t we tell the story better?

Let me do this properly here. Slowly. Honestly. From the heart.

Because Favoriot was never born as an academic toy. It was never designed to live only inside labs, classrooms, or final-year projects. Favoriot was built as an enterprise IoT platform for real deployments, real operations, real risks, and real consequences.

Education came later. And it came for a reason.

Favoriot Was Built for the Real World First

When we started Favoriot, the vision was very clear.

Factories. Warehouses. Farms. Buildings. Cities.
Sensors are sending data every second.
Dashboards that people depend on, not admire.
Alerts that wake someone up at 3 a.m. because something is wrong.

That was the intention.

An enterprise IoT platform is not glamorous. It is not flashy. It does not impress with demos alone. It needs to survive power outages, unstable networks, noisy data, and human mistakes.

That is the world Favoriot was designed for.

Air quality monitoring, indoor and outdoor.
Gas detection in agriculture and manufacturing.
Cold chain and warehouse monitoring.
Energy usage. Environmental sensing. Operational visibility.

These are not student exercises. These are systems people rely on to protect assets, livelihoods, and, at times, lives.

And yes, many of these implementations cannot be publicly shared. Clients trust us with their data and their operations. Confidentiality is part of doing real work.

Ironically, that silence made people assume nothing was happening.

Maybe that’s where the misunderstanding started.

The Real Problem Was Never the Platform

Here is the uncomfortable truth.

The biggest challenge in IoT is not platforms.
It is not sensors.
It is not cloud infrastructure.

It is people.

Or more specifically, the lack of people who truly know how to build an IoT solution end-to-end.

Back in 2017, we offered a free plan. We thought adoption would be instant.

It wasn’t.

People signed up.
Then they stopped.
Nothing moved.

And I remember thinking, “Why is no one using it?“

The answer hurt a little.

They didn’t know how.

They knew dashboards from presentations.
They knew buzzwords from conferences.
They knew how to connect one sensor, sometimes.

But building a full solution?
Designing data flows?
Handling failures?
Understanding why data behaves badly in the real world?

That knowledge gap was huge.

From 2017 to 2022, I saw it everywhere. Universities. Startups. Even some companies. Everyone wanted IoT. Very few knew how to build it properly.

Why We Walked into Education

So we made a decision.

Not a pivot. Not a retreat. A foundation.

If people cannot build IoT solutions, no platform will ever matter.

I remember asking myself:
Do we complain about the talent gap, or do we help close it?

That is when we started working closely with educators. Training lecturers. Creating step-by-step tutorials. Supporting students not to pass subjects, but to understand systems.

That is why Favoriot content online often looks educational.

Not because we are an education-only platform.
But because education was the missing piece in the ecosystem.

We were not selling theory. We were teaching how to connect sensors, send data, manage devices, handle failures, and make sense of messy reality.

Education was not the destination. It was the on-ramp.

Two Worlds. One Platform.

Here is what many people missed.

While all this educational work was happening in public, Favoriot was quietly working with industry in parallel.

Two tracks. Same platform.

On one side, students and lecturers are learning how to build.
On the other, enterprises deploying systems that run daily operations.

The platform did not change.
The expectations did.

Students learn to make things work.
Enterprises demand that things not break.

That dual role was never a conflict. It was a strength.

Education feeds industry.
Industry validates education.

Yet we did not tell that story clearly enough. And for that, I take responsibility.

The Irony of Global Adoption

Here is another irony that few people realise.

Favoriot users come from all over the world. When someone subscribes, they build whatever they want.

We do not always know what devices they connect.
We do not always know what systems they deploy.
We only see data flowing.

Some of the most interesting use cases are completely invisible to us.

And that is exactly how a real platform works.

No hand-holding. No spotlight. Just infrastructure doing its job.

But again, silence creates assumptions.

If people don’t see it, they think it doesn’t exist.

This Is Not Just About Favoriot

This reflection is not only about correcting a misunderstanding.

It is about how we, as a country and as a community, think about capability.

We love importing solutions.
We love buying finished systems.
We rarely invest in learning how they are built.

Then we wonder why we depend on outsiders for everything.

IoT is not magic. It is engineering. It is discipline. It is patience. It is experience.

Platforms like Favoriot matter only when people know how to use them properly.

That is why education and enterprise must never be separated.

What I Wish People Would See

I wish people would stop asking whether Favoriot is for education or industry.

It has always been both.

Education builds builders.
Industry needs builders.

One without the other collapses.

Sometimes I ask myself:
If we had focused only on selling enterprise solutions, would the ecosystem be stronger today?

Honestly? No.

Without talent, platforms die quietly.

A Personal Reflection

I have spent my life in technology. Telecom. IoT. Smart systems. Startups.

The pattern is always the same.

People rush to buy tools.
Very few invest in learning how to use them well.

Favoriot’s story is a reminder to me, too.

Technology without understanding is decoration.
Understanding without real deployment is a fantasy.

We need both.

My Message to Educators

Do not treat IoT platforms as demo tools.

Treat them as environments where students learn responsibility.

Teach failure.
Teach troubleshooting.
Teach why things break.

That is how builders are formed.

My Message to Industry

Do not dismiss platforms you see in universities.

Those environments are where your future engineers are learning.

Support them. Challenge them. Hire them.

You will thank yourself later.

My Message to Policymakers and Leaders

If you want digital capability, stop funding only deployments.

Fund learning.
Fund training.
Fund local platforms and ecosystems.

Ownership starts with understanding.

And Finally, My Message to You

If you are reading this and you once thought Favoriot was “just for education”, I hope this piece helped.

If you already knew the bigger picture, help me tell the story better.

Because platforms do not build ecosystems.
People do.

And ecosystems take time, patience, and honesty.

I’m still learning that myself.

What about you?

Have you seen similar misunderstandings in your work or industry?
Drop your thoughts in the comments. I read them all.

The Moment the Smart City Dashboards Stopped Impressing Me

There was a time when I was impressed by command centres.

Rows of screens.
Maps glowing in neon colours.
Charts are moving in real time.
Operators are pointing at dashboards like air traffic controllers.

It looked powerful.
It looked serious.
It looked… convincing.

But one day, standing quietly at the back of the room, I caught myself thinking something uncomfortable.

If one screen goes dark, who notices?
If the data contradicts another system, who decides?
If something breaks at 2 a.m., who actually understands what is happening?

That was the moment the screens stopped impressing me.

Because cities are not run by visuals.
Cities are run by clarity.

And clarity does not come from dashboards alone.

How Cities Slowly Accumulate Silos Without Realising It

Most local councils chose not to fragment.

Fragmentation happened to them.

Projects arrived one by one.
Budgets were approved year by year.
Each initiative solved a real problem at the time.

Flood monitoring came first.
Then air quality.
Then lakes.
Then traffic.
Then parking.

Each project was justified.
Each vendor delivered.
Each system worked.

Individually.

What nobody planned for was the moment when all these systems would need to speak to each other.

So the command centre slowly became a collection of disconnected truths.

Each dashboard told its own story.
None of them told the whole truth.

When a Dashboard Is Mistaken for a Platform

I often hear this sentence.

“Yes, we already have a smart city platform.”

Then I look closer.

What I see is usually a visual layer.
A presentation surface.
A beautifully designed window.

But behind it, there is no device management.
No rule engine.
No action triggers.
No real-time orchestration.

Just data being shown.

And showing data is not the same as running a city.

A true platform does not just display.
It listens.
It reacts.
It remembers.
It connects.

Two Types of Data That Rarely Shake Hands

Cities live in two data worlds.

The first world is structured, administrative, and familiar.

Assets.
Licences.
Collections.
Population data.
Facilities.

This data is critical. It reveals the city’s shape. It is refreshed periodically and often lives inside systems branded as urban observatories.

The second world is restless.

Sensor data.
Live streams.
Alarms.
Failures.
Spikes.
Drops.

This is IoT data.
It does not wait politely.
It arrives when it wants.
It demands attention.

The mistake happens when we treat both worlds as if they behave the same way.

They do not.

GIS and Digital Twins Without Real-Time Truth

Many councils have strong GIS platforms.

Layers upon layers of insight.
Maps that tell stories about people, land, and risk.

Some go even further with digital twins.
Virtual representations of buildings, roads, and infrastructure.

I admire these efforts.

But without live sensor input, these systems are frozen in time.

They show structure.
Not behaviour.

A city is not just where things are.
It is how things change.

Without IoT data, even the most beautiful digital twin is only a photograph, not a mirror.

Why an Integrated IoT Platform Is Not Optional Anymore

At some point, cities reach a tipping point.

They stop asking for new dashboards.
They start asking better questions.

Why did flooding worsen after that traffic upgrade?
Why does air quality dip only in specific zones?
Why do alarms trigger too late?

These questions cannot be answered inside silos.

They require correlation.

This is where an integrated IoT platform matters.

Not to replace everything.
But to connect everything.

A layer where data from rivers, rain, air, traffic, parking, and buildings can coexist.
A place where patterns emerge.
A place where decisions are supported, not guessed.

This is the role of IoT middleware.
This is where platforms like FAVORIOT were designed to sit.

The Fantasy of One Platform to Rule Them All

Every city dreams of simplicity.
Every vendor dreams of being central.

The idea of one master platform controlling everything is seductive.

But reality is less romantic.

Platforms are built with different goals.
Vendors protect their niches.
Legacy systems do not disappear quietly.

Trying to force everything into one system usually creates resistance, delays, and disappointment.

Cities do not need domination.
They need coordination.

The Quiet Risk Nobody Likes to Talk About

There is a dangerous sentence I hear too often.

“We don’t mind. Let the vendor manage everything.”

It sounds efficient.
It sounds hands-off.

Until the day the council asks for raw data.
Or integration rights.
Or historical access.

And discovers they cannot.

No API.
No export.
No control.

That is vendor lock-in.
And by then, it is too late to complain.

A smart city without data ownership is not smart.
It is dependent.

Procurement Is the Real Smart City Strategy

Smart cities are not won in control rooms.

They are won in procurement documents.

When councils specify openness.
When they demand interoperability.
When they insist on owning their data.

That is when cities protect their future.

Technology can always be upgraded.
Contracts are harder to undo.

Integration Is an Act of Maturity

I no longer believe in replacing everything.

I believe in respecting what already works.
Connecting what matters.
Opening what was once closed.

Legacy platforms should remain.
Specialised systems should continue.
But data must flow.

Sometimes that means managing two or three core platforms instead of one.

That is not failure.
That is realism.

Why I Keep Writing About This

I am not chasing trends.
I am chasing calm.

Calm operators.
Calm decision-makers.
Calm cities that respond instead of react.

When systems are integrated, nights are quieter.
When data is shared, trust grows.
When platforms cooperate, leaders sleep better.

If you are building a smart city, pause before asking for another screen.

Ask instead:
Can this system talk?
Can it share?
Can it last?

If this reflection sounds familiar, I would love to hear from you.

What have you seen in your city?
Where did silos slow you down?
What worked when integration finally happened?

Drop your thoughts in the comments.
Let us learn from each other and build cities that truly understand themselves.

Why Universities Need a Real IoT Lab, Not Just Another Embedded Lab

I still remember a meeting with a group of lecturers, where I asked a simple question.

“Why do we really need an IoT Lab in universities?”

I paused for a moment.
Because deep down, I already knew the answer.

Most universities already have something they proudly call an IoT lab. Rows of ESP32 boards. Arduino kits. LEDs are blinking happily. LCD screens displaying temperature values. Students smile because something lights up.

And yet, something feels incomplete.

This is not IoT. This is just the beginning.

This blog is not meant to criticise universities. I have spent years inside them. I was once a lecturer designing syllabuses, labs, and assessments. This comes from care. From concern. From watching students graduate with confidence in embedded programming but struggle the moment systems become real, connected, and dependent upon.

This reflection is based on a recent lecture I delivered on the need to establish a proper IoT Lab in universities, one that reflects how systems are actually built, deployed, and trusted today.

Embedded Systems Taught Us How to Build Devices

Let me be very clear.

Embedded systems are important. They are foundational.

Students need to learn how to program microcontrollers. They need to understand sensors, actuators, interrupts, memory, and power consumption. All of that matters.

An embedded system is usually a standalone device. It senses something. It controls something. It logs data into local storage.

There is nothing wrong with that.

In fact, embedded systems are still used today in places with no connectivity. Remote areas. Harsh environments. Offline conditions.

But here is the problem.

Once the data is captured, someone has to physically go to the site, connect a laptop, download the data, return with it, and process it manually.

I have seen this happen too many times.

Two technicians. One vehicle. Hours of work. Just to retrieve data that could have been transmitted automatically.

I always ask myself… why are we still doing this in 2026?

Connectivity Changes Everything

The moment a device is connected to the internet, everything changes.

Data no longer waits for humans to come and collect it.
It flows.
It moves.
It becomes alive.

This is the moment embedded systems evolve into the Internet of Things.

Now we can monitor systems remotely.
Now we can detect failures early.
Now we can see battery levels dropping before devices die silently.
Now we can act before complaints arrive.

And yet, most university labs stop just before this moment.

Students are taught how to blink LEDs, but not how to send data reliably.
They learn how to display values, but not how to secure data in transit.
They build devices, but not systems.

And systems are what the real world depends on.

A Real IoT Lab Must Teach Technology Layers

IoT is not a single skill. It is a stack.

In my lecture, I stressed that a proper IoT Lab must expose students to multiple technology layers, not in theory, but through hands-on work.

Layer 1: Hardware and Firmware

This is where universities are already strong.

Sensors. Controllers. Actuators. Firmware logic. Power management.

Students should continue learning this well.

But they must also understand that this is just one layer.

Layer 2: Connectivity and Protocols

This is where gaps start to appear.

Students must learn how data travels.

Wi-Fi. Cellular. LPWAN.
Bluetooth. ZigBee. RFID.
MQTT. CoAP. REST. HTTP.
LoRa. NB-IoT. Sigfox.

Not as a list to memorise.
But as choices with consequences.

Which protocol suits low power?
Which network works for long range?
What happens when connectivity drops?

Without this understanding, troubleshooting becomes guesswork.

Layer 3: Platform and Middleware

This is the heart of IoT.

Devices do not talk directly to dashboards. They talk to platforms.

An IoT platform manages devices.
Authenticates them.
Stores data.
Provides APIs.
Handles scale.

This is where students should learn about device identities, data ingestion, databases, and analytics pipelines.

This is also where they start to understand why platforms like FAVORIOT exist in the first place.

Not to replace learning.
But to enable it.

Layer 4: Analytics and Visualisation

Dashboards are not the end goal.

They are the beginning of understanding.

Students should learn how data evolves from descriptive charts to deeper insights.
They should see patterns.
Spot anomalies.
Ask better questions.

This prepares them for real projects, not demos.

Security Must Exist Across All Layers

Security cannot be an afterthought.

Devices must be authenticated.
Data must be encrypted.
Platforms must be protected.
Applications must be hardened.

Most labs barely touch this.

And yet, this is where real systems fail.

When Systems Break, Knowledge Is Tested

I often tell students this.

The real test of IoT knowledge is not when everything works.

It is when something breaks.

Data stops arriving.
Dashboards go blank.
Alerts do not trigger.

At that moment, students panic if they only know how to code LEDs.

But students who understand layers start asking better questions.

Is it the device?
Is it the network?
Is it the platform?
Is it the visualisation?

This is the mindset a real IoT Lab must build.

Research, AI, and the Future of IoT Labs

Universities are not just about projects. They are about research.

To do meaningful research, students need data. Lots of it. Clean data. Continuous data.

IoT Labs enable this.

Once data flows reliably, students can apply machine learning.
They can explore pattern recognition.
They can experiment with predictive models.

Today, this also means understanding edge AI.

Inference running on devices.
Decisions made locally.
Latency reduced.
Systems are becoming smarter as they operate.

This is where IoT Labs naturally evolve into AIoT Labs.

And this is where universities must go.

This Is a Call to Universities, Lecturers, and Policymakers

If we want graduates who can build real systems, not just academic projects, we must change how we teach IoT.

IoT Labs must move beyond embedded programming.
They must teach architecture, trade-offs, and responsibility.
They must reflect how systems are deployed outside campus walls.

I believe universities can do this.
I believe lecturers want this.
I believe students deserve this.

But it requires intention.

It requires investment.
It requires collaboration with the industry.
It requires courage to redesign labs that have been unchanged for years.

If you are a lecturer, start asking what your lab is missing.
If you are a dean, ask whether your graduates can troubleshoot real systems.
If you are a policymaker, ask whether our talent pipeline matches national ambitions.

And if you are a student reading this, ask yourself one question.

Am I learning how to build a device… or how to build a system people can trust?

I would love to hear your thoughts, experiences, and struggles in building or teaching IoT.
Drop a comment. Let’s talk.

Smart Cities in Malaysia – Between Beautiful Documents and Real Implementation

There is a kind of silence I remember very clearly.

Not the silence of an empty room.
But the silence appears when too many slides are shown, too many big words are used, and too few honest questions are asked.

I was sitting in yet another Smart City presentation. Everyone was talking about master plans, KPIs, ISO standards, indicators, and rankings. The slides looked polished. The diagrams were neat. The language sounded confident.

Yet inside, a quiet question kept repeating.

Who will take care of this after the launch?
Who will wake up when the system fails?
Who will face the public when citizens are angry?

Those questions rarely appear on slides.

And that, for me, is where the real Smart City problem in Malaysia begins.

Why We Talk About Smart Cities at All

Smart Cities are not about technology.

They are about people.

They are about parents stuck in traffic every morning.
Children breathe unhealthy air.
Small business owners suffer when flash floods arrive without warning.

I often say this, and I truly believe it.

The final goal of a Smart City is very simple.

People can live healthier lives.
People can live happier lives.
Cities can run without constant chaos.

That’s it.

Not rankings.
Not awards.
Not plaques on office walls.

Yet somewhere along the way, we lost that simplicity.

When Everyone Wants to Be “Smart”

Today, almost everyone wants the Smart City label. Some go further and call themselves “AI Cities”.

I usually smile when I hear that.

Which AI?
Where is the intelligence?
Or is it just a new signboard?

Many systems branded as AI are simply basic automation. This is not a technology problem. It is a misunderstanding.

What troubles me more is this.

Some cities work quietly, building systems that actually function, yet receive no recognition because they never submitted an application. Others receive recognition early simply because they know how to fill out forms.

That’s when we learn a hard truth.

Recognition does not always reflect maturity.

From 30,000 Feet to 3 Feet

To be fair, Malaysia does have a solid Smart City framework.

On paper, it makes sense.

At 30,000 feet, there is the national master plan.
At 3,000 feet, there are state-level blueprints.
At ground level, around 3 feet, there should be detailed action plans for local councils.

Everything looks structured.

But in reality, many councils are stuck somewhere in between.

Some are still writing plans.
Some are experimenting with pilot projects.
Very few are running systems consistently, day after day.

Not because they don’t care.
Not because they are lazy.

But because something fundamental is missing.

Delivery structure.

Command Centres That Feel Empty

I have visited many command centres.

The name sounds powerful. Command centre. It feels important.

But once inside, the scene is often the same.

CCTV screens.
Live video feeds.
A few officers are watching.

That’s all.

I quietly ask myself.

Where is the data integration?
Where is the analysis?
Where are the decisions driven by this data?

A command centre should be the brain of the city.

Not just its eyes.

Imagine traffic data, air quality, noise levels, parking systems, citizen complaints, legacy databases, all connected and analysed together.

First, we know what has happened.
Then, we understand why it happened.
Next, we anticipate what might happen.
Finally, we know what action to take.

This is where technology truly matters. Not to impress, but to guide decisions.

The Challenges We Rarely Admit

Since around 2015, I have seen the same issues repeat.

Budget That Is Never Enough

Local councils are not money-making machines.

They rely on limited revenue sources. Assessment taxes. Parking fees. Licenses.

With limited funds, choices become limited too.

Projects that generate revenue or reduce costs often get priority. Long-term social impact projects struggle to survive.

Risk-heavy concession models usually favour large companies with deep pockets. Smaller local players, often full of ideas and energy, get pushed aside.

Sometimes I ask myself quietly.

Do we really want local ecosystems to grow?
Or are we just choosing the easiest path?

Projects Without Guardians

This one hurts the most.

Many Smart City projects are launched with excitement. Press conferences. Posters. Promotional videos.

A year later, the system is silent.

No maintenance.
No monitoring.
No clear ownership.

The project becomes a white elephant.

Not because the technology failed.
But because no one was assigned to take care of it.

Skills Gap Is Real

Smart Cities demand new skills.

Data management.
IT infrastructure.
Commercial thinking.
Long-term contract handling.

Many council officers come from strong urban planning backgrounds. They are good at what they do.

But we cannot expect them to suddenly manage complex digital systems without proper support.

This is not an individual failure. It is a structural one.

Fragmented Governance

For solution providers, one simple question often becomes complicated.

Who should we speak to?

Without a clear focal point, discussions lose direction. Time is wasted. Trust slowly fades.

One Answer I Strongly Believe In

If there is one thing that matters most, it is not technology.

It is a Delivery Unit.

A dedicated team.
Given authority.
Given responsibility.
Given continuity.

This unit becomes the caretaker of the entire Smart City lifecycle.

From strategy.
To execution.
To daily operations.
For long-term maintenance.

When this unit exists, everything changes.

Communication becomes clear.
Ownership becomes visible.
Projects do not get abandoned.
Citizens start feeling real benefits.

Smart City stops being a document.
It becomes a service.

Why I Still Have Hope

I am not writing this out of frustration.

I am writing because I still believe.

I believe our local councils are capable.
I believe our local talent is strong.
I believe technology is just a tool, not the answer.

What we need is the courage to admit weaknesses and the wisdom to build the right structure.

Smart City is not a race.
It is a responsibility.

If we want public trust, we must start taking care of what we build.

And it begins with one honest question.

Who will make sure this city still works tomorrow morning?

If this piece made you pause and think, I would love to hear your thoughts.
Leave a comment. Let’s talk.

When Data Leaves the Country, Control Leaves With It

A personal reflection on why I insisted on an Enterprise IoT Platform with on-premise deployment

There are moments in a founder’s life when you stop talking about features.

You stop talking about dashboards.
You stop talking about protocols.
You even stop talking about scale.

And you start talking about control.

This was one of those moments.

I remember sitting quietly after one of our internal briefings, staring at the whiteboard filled with arrows, boxes, and deployment diagrams. Everyone had left the room. The air was still.

Why am I pushing so hard for this Enterprise Plan?
Why does this feel heavier than just another pricing tier or feature release?

Then it hit me.

This was not about software.
This was about sovereignty.

And once you see it that way, you can never unsee it.

From owning a kitchen to owning the whole restaurant

For years, I used a simple analogy when explaining IoT platforms.

If you are on a shared cloud platform, you are like a chef renting a kitchen. You can cook. You can serve. But you do not own the space. You follow house rules. You live with limits.

The Enterprise Plan is different.

It is not about owning the kitchen anymore.
It is about owning the whole restaurant.

The building.
The keys.
The doors.
The data flows.
The servers are sitting quietly in your own premises.

When you own the restaurant, no one tells you when to close. No one caps how many customers you can serve. No one decides where your ingredients come from.

That is the mindset behind the Enterprise IoT Platform.

The moment I realised cloud is not always the answer

For a long time, cloud felt like the default answer to everything.

Fast.
Flexible.
Convenient.

I believed in it. I still do, for the right use cases.

But over the years, as I spoke to large organisations, city operators, government agencies, and critical infrastructure owners, a pattern kept repeating itself.

“We don’t want our data outside the country.”
“We need to know exactly where the servers are.”
“We cannot afford external dependencies for this system.”
“This data is too sensitive.”

At first, some people dismissed these concerns as paranoia.

I did not.

Because when you are dealing with traffic lights, water systems, energy grids, and public safety sensors, paranoia is just another word for responsibility.

What happens if the platform is outside the country and something goes wrong?
Who takes control when connectivity is lost?
Who answers when an entire city goes dark?

These are not theoretical questions. These are operational nightmares waiting to happen.

Data sovereignty is not a buzzword when infrastructure is involved

Data sovereignty sounds abstract until you put real consequences next to it.

Imagine a critical infrastructure monitoring system managed by a platform hosted overseas. One day, there is a major failure.

Power outage.
Network disruption.
Access blocked.

The local operators are standing there, staring at blank screens, unable to take control because the system that runs their infrastructure is not physically within reach.

That is unacceptable.

This is why on-premise deployment matters.

Not because it sounds serious.
Not because it looks impressive in a proposal.

But because control must stay with those who are accountable.

This thinking shaped every part of the Enterprise IoT Platform plan.

AI made the stakes even higher

If IoT data is sensitive, AI makes it explosive.

AI models learn from data.
Patterns.
Behaviours.
Weak points.

When AI touches critical infrastructure data, the question is no longer just “where is my data?”

It becomes “who understands my system better than I do?”

That was the turning point for me.

If AI is going to sit on top of IoT data, then the data must never leave the country.

This is not about fear.
This is about governance.

Every country I speak to says the same thing, whether it is Malaysia, Indonesia, the Middle East, or Europe.

“We want AI. But we want our data at home.”

The Enterprise Plan was designed to respect that reality.

Unlimited API is not a luxury; it is a survival

One detail that often gets overlooked is API limits.

People ask me, “Why unlimited API? Isn’t that excessive?”

Let me paint you a picture.

A manufacturing line monitors machines every second.
One sensor. One data point per second.
Multiply that by hundreds of machines.
Multiply again by shifts, days, months.

Suddenly, 500,000 API calls per day is not generous. It is restrictive.

The Developer Plan has limits because it should. It is built for builders, experimentation, and controlled scaling.

But enterprise environments do not experiment. They operate.

If you throttle data in an industrial environment, you are not saving costs. You are introducing blind spots.

Unlimited API is not about indulgence.
It is about continuous visibility.

Two very different enterprise realities

As I refined this plan, two clear deployment models kept emerging.

1. The white-label service provider model

Some organisations do not want to sell hardware.
They want to sell managed IoT services.

They do not want to build a platform from scratch. That path is expensive, slow, and painful.

So they white-label the Enterprise IoT Platform.

Their brand.
Their customers.
Their business logic.

They plug in their agricultural sensors, industrial devices, and vertical solutions, and run everything on their own enterprise platform.

Thousands of customers.
One controlled system.

I have seen how powerful this model can be when done right.

2. The smart city and government deployment model

Then there are cities.

Cities are different.

They already have many solutions. Parking. Flood sensors. Air quality. Lighting. Waste.

The problem is not a lack of data.
The problem is fragmentation.

Every system has its own dashboard. Its own vendor. Its own silo.

Local councils want a single platform, deployed on-premises, where everything comes together.

In some cases, councils cannot do this alone.

That is where state-level deployment makes sense.

One enterprise platform owned by the state.
Local councils connect their data.
Data stays within the country.
Visibility scales across regions.

It is pragmatic. It is cost-aware. It respects sovereignty.

This is bigger than one platform

As I reflect on this journey, I realise something.

The Enterprise IoT Platform is not just a product decision.
It is a philosophical stance.

It says:

You should own your data.
You should control your infrastructure.
You should not outsource accountability.

In a world rushing towards convenience, this is a reminder that responsibility still matters.

A quiet call to builders, cities, and leaders

If you are building systems that people depend on, ask yourself one simple question.

When things go wrong, who truly has control?

If the answer is unclear, it might be time to rethink how your platform is deployed.

I did.
And that rethink led us here.

I would love to hear your thoughts.
Where do you draw the line between convenience and control?
Share your reflections in the comments.

Why We Want Students to Struggle a Little When Learning IoT

I want to be honest with you.

Every time I walk into a university or polytechnic to talk about IoT, I already know the answer before I ask the question.

“What platform are you using for your final year project?”

The answers come fast. Almost automatic.

One particular platform. That has …
A mobile app.
Lots of YouTube tutorials.
GitHub samples.
Forums everywhere.

I nod. I smile.

I’ve heard this story many times.

And then comes the follow-up question.

“Why that platform?”

The answer is almost always the same.

“Because it’s easy.”
“Because there’s a mobile app.”
“Because seniors used it.”
“Because everything is already there.”

At that moment, a quiet thought always crosses my mind.

Easy today, but are you ready for tomorrow?

This blog is not about criticising students. Far from it.

It is about explaining why I believe students need to struggle a little when learning IoT. And why Favoriot was built the way it is.

The Comfort Trap Students Fall Into

I understand why students choose platforms that feel comfortable.

You connect a sensor.
Data appears on your phone.
You show it to your supervisor.
Demo done.

No need to build dashboards.
No need to understand protocols.
No need to worry about servers or data pipelines.

It feels good.

But comfort can be deceptive.

I asked myself, are we training students to build IoT systems, or are we training them to click buttons?

In many universities, IoT projects are still treated as extended embedded-system exercises.

Arduino.
ESP32.
Blink an LED.
Trigger a relay.

Nothing wrong with that.

But IoT is not just about making something move.

IoT is about data travelling.

From sensors.
Through networks.
Into platforms.
Across dashboards.
Into decisions.

If students never see that journey, they never really understand IoT.

The Chicken and Egg Problem Nobody Talks About

Let me share a frustration I rarely say out loud.

Favoriot is still new compared to global platforms.

Students don’t know us because there are fewer tutorials.
There are fewer projects online.
There are fewer YouTube videos.

And because of that, students don’t choose us.

Then I stop and think, how do you ever break this loop?

No users means no content.
No content means no discovery.
No discovery means no users.

Classic chicken and egg.

This is why I spend time going to universities.
Why I accept invitations to serve on industry advisory panels.
Why I keep introducing Favoriot in syllabus discussions.

Not because I want students to use Favoriot blindly.

But because someone has to be the first builder.

“But, Sir, Favoriot Has No Mobile App”

I hear this a lot.

And yes, for a long time, Favoriot did not have its own mobile app.

But here’s something many students don’t know.

There are MQTT mobile clients on Android and iOS.
They already have dashboards.
You configure them.
Connect to Favoriot.
And instantly see live data on your phone.

When I explain this, I see faces change.

“Oh… we didn’t know that.”

That sentence tells me everything.

Sometimes adoption is not about missing features.
It is about missing awareness.

And that is on us.
We need to explain better.
Show better.
Document better.

The Part Students Rarely See: The Full IoT Stack

This is where I get passionate.

IoT is not one skill.
It is many skills stacked together.

When students use platforms that hide everything, they only learn the top layer.

Here’s what real IoT demands.

Hardware
Sensors. Microcontrollers. Power. Battery life.

Connectivity
MQTT. CoAP. REST. WiFi. Cellular. LPWAN.

Platform
Device management. Ingestion. APIs. Storage.

Visualisation
Dashboards. Alerts. Rules.

Analytics
Understanding what happened. Why did it happen? What might happen next? What action to take?

Security
From device firmware to cloud access.

I sometimes ask myself, how can someone troubleshoot what they never learned existed?

Why I Don’t Believe in “No-Code IoT”

This may sound unpopular.

But I don’t believe IoT can be fully no-code.

IoT is physical.
It touches hardware.
It touches networks.
It touches real environments.

You need to understand flows.
You need to debug failures.
You need to trace where the data stops.

If there is no data on the dashboard, is it the platform’s fault?

Or is the sensor dead?
Is the firmware corrupted?
Is the network unstable?
Is the battery empty?

If everything is hidden, you don’t know where to look.

That’s dangerous.

PaaS Is Harder, and That’s the Point

Favoriot is closer to a platform than an app.

Some people say it’s harder.
They are right.

But difficulty is not a flaw.
It is a teacher.

When students use a platform that requires them to configure devices, protocols, dashboards, and rules, they are forced to think.

Why did I choose MQTT here?
Why is my data not arriving?
Why does this alert trigger late?

Those questions build engineers.
Not button-clickers.

Analytics Is Where IoT Becomes Meaningful

I always remind students.

Collecting data is not the goal.
Understanding data is.

IoT analytics moves in stages.

First, you look back.
What happened?

Then you ask why.
What caused it?

Then you look ahead.
What might happen next?

Finally, you decide.
What should I do about it?

This is why we built Favoriot Intelligence inside the platform.

Not as a separate system.
Not as an external tool.

One pipeline.
End-to-end.

Data comes in.
Insights come out.
Actions happen.

This is where IoT starts to feel alive.

AIoT and the Future Students Will Walk Into

Things are shifting fast.

AI is no longer optional.
Edge intelligence is becoming real.

Models trained in the cloud.
Inference pushed to devices.
Decisions made closer to reality.

Students who only learned drag-and-drop dashboards will struggle here.

Students who understand flows, stacks, and constraints will adapt.

That difference matters.

Why I Care So Much About This

People sometimes ask why I spend so much time with universities.

The answer is simple.

I have seen graduates enter the industry confused.
Overwhelmed.
Afraid of real systems.

I don’t want that.

I want students who can walk into a telco, a factory, a startup, or a smart city project and say,

“I don’t know this tool yet, but I understand how IoT works.”

That confidence changes careers.

Practical Tips for Students Learning IoT

Let me leave you with a few honest tips.

Learn beyond your demo
A working demo is not the finish line. Ask what breaks when conditions change.

Trace data end-to-end
Always ask where data starts and where it stops.

Understand at least one protocol deeply
MQTT, CoAP, or REST. Know how it behaves when networks fail.

Build dashboards yourself
Dragging widgets teaches more than screenshots.

Make something fail on purpose
Turn off WiFi. Drain the battery. Observe what happens.

Learn one platform properly
Not ten platforms shallowly.

Document your struggle
Others learn from your mistakes.

A Quiet Invitation

If you are a student reading this and you feel slightly uncomfortable right now, that’s good.

It means you are growing.

If you are a lecturer, consider whether your students are learning embedded systems or IoT.

And if you are one of the early builders willing to share your Favoriot project, you are not just building a system.

You are building a community.

Someone has to be first.

I hope you’ll be one of them.

I would love to hear your thoughts, your struggles, or your stories.
Leave a comment. Let’s talk.