Tag: Startup

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.

AI Is Everywhere Today, But the Real Power Still Comes From Somewhere Else

There are moments when I sit back after a lecture, pack my bag, and feel a strange mix of pride and worry.

Pride because I have seen how far technology has come.

Worry because I know how easily we forget the foundations.

That Friday lecture on the relevance of IoT and the rise of AI stayed with me long after I left the room. Not because the topic was new. I have lived with IoT for more than a decade. It stayed with me because of the silence that follows whenever I ask a simple question.

Where does your data actually come from?

Everyone lights up when we talk about AI. Eyes widen. Phones come out. Someone mentions ChatGPT. Someone else talks about image generation, voice cloning, videos that look real enough to fool our parents and sometimes ourselves.

Then I bring up sensors.

And the room goes quiet.

I Have Seen This Story Before

I thought to myself, This feels familiar.

Back in 2014, when we published the national IoT roadmap, the words “Internet of Things” sounded foreign to many. We talked about low-powered networks, sensors, connected devices, and data that flows quietly in the background. At that time, most people were still trying to understand what IoT even meant.

Later came the Fourth Industrial Revolution hype. AI, blockchain, cloud, analytics. Big words. Big slides. Big expectations.

Then COVID arrived and forced everyone online. Suddenly, digitising forms was no longer optional. Meetings went virtual. Systems moved to the cloud. People realised something uncomfortable.

We were talking about advanced technologies, but many organisations were still doing basics by hand.

We wanted intelligence without instrumentation.

The Quiet Truth About AI

Here is the uncomfortable truth that does not trend well on social media.

AI without data is just hope.

AI without sensor data is mostly guessing.

Most of the “intelligent” things people want today depend on time-based data from the physical world. Energy usage. Temperature. Vibration. Traffic flow. Air quality. Machine health. Human movement.

All of these begin with IoT.

When someone says they want predictive insights, I gently ask, How long have you been collecting data?

When they say they want anomaly detection, I ask, Do you know what normal looks like for your system?

These are not trick questions. They are reminders.

AI does not magically appear. It grows from data that has been quietly collected, cleaned, and understood over time.

Dashboards Make Us Feel Safe

I have seen countless dashboards.

Beautiful charts. Moving lines. Big screens in control rooms. Red, amber, green indicators blinking politely.

And yet, I always ask myself, What decision changed because of this screen?

Dashboards tell us what has already happened. That is useful, but limited. It is like driving while looking only in the rearview mirror.

What people really want is to know why something is happening. Or what might happen next. Or what they should do about it.

That is where analytics, machine learning, and edge intelligence come in.

But none of that works if the data is poor, sparse, or misunderstood.

The Rise of Edge Thinking

One part of the lecture that excited me was the discussion of edge intelligence.

I remember thinking, This is where things finally feel grounded.

Not every decision needs to travel to the cloud and back. Cameras detecting unusual behaviour. Machines sense abnormal vibration. Safety systems reacting in milliseconds.

These decisions must happen close to where the data is created.

That requires discipline in how we design systems. What runs on the device. What runs centrally. What gets escalated to humans.

Technology is not just about speed. It is about trust.

Why IoT Feels Invisible Now

IoT has become so normal that people barely talk about it anymore. It works quietly. Sensors sit on walls, poles, machines, and vehicles. Data flows without fanfare.

AI, on the other hand, talks loudly. It writes. It draws. It speaks. It performs.

So attention shifts.

But I keep reminding myself, and my students, that the loudest technology is not always the most important one.

AI sits atop IoT, not beside it.

Universities Are Catching Up, and That Gives Me Hope

One of the most encouraging things I see today is how universities are changing.

Students are no longer just learning theory. They are building devices. Choosing protocols. Sending data into platforms. Visualising it. Asking questions. Experimenting with machine learning.

When students understand the full journey of data, from sensor to insight, something clicks.

They stop chasing shiny features.

They start thinking like builders.

A Subtle Lesson From the Field

Over the years, working closely with real deployments, I have learned something simple.

Systems fail not because of a lack of intelligence, but because of a lack of patience.

AI needs time. IoT needs consistency. Data needs care.

Platforms that respect this reality are the ones that last. I have always believed that an IoT platform should quietly support learning, experimentation, and growth without demanding attention. It should help teams move from visibility to understanding, and later to confidence.

That philosophy has shaped how we build things at Favoriot. Not chasing headlines, but supporting people who want to do the hard work properly.

Advice I Keep Repeating to Myself

As I reflect on that lecture, I find myself repeating a few reminders.

Do not rush AI before you understand your data.

Do not replace thinking with automation too early.

Do not trust dashboards that cannot explain themselves.

Do not ignore sensors just because they are quiet.

Most importantly, do not forget that technology exists to help humans make better decisions, not to impress them.

Progress is not about who adopts AI first.

It is about who builds understanding that lasts.

If this reflection resonates with you, share your thoughts. I would love to hear how you are balancing IoT and AI in your own work, and what lessons you are learning along the way.

When the Dashboard Goes Quiet, That’s When IoT Gets Real

There is a moment in every IoT journey that nobody prepares you for.

It does not happen during Demo Day.
It does not happen when the dashboard looks clean and colourful.
It does not happen when everyone claps after a presentation.

It happens much later.

Usually at night.
Usually, when you are already tired.
Usually, when someone sends you a short message that feels far heavier than it looks.

“Why is there no data?”

I have seen this moment too many times.

With students working on their final-year projects.
With startup founders handling their first paying customer.
With engineers running systems inside real buildings.
With councils operating services that citizens quietly rely on every day.

And every single time, something changes inside the person responsible.

I remember thinking, this is the exact point where IoT stops being exciting and starts being serious.

This piece comes from years of deployments, troubleshooting sessions, and long conversations after systems went silent. Not theory. Not slides. Just reality.

The Comforting Lie After Deployment

There is a lie many of us tell ourselves.

“The device is configured.”
“The data is visible.”
“The dashboard is live.”
“So… we’re done.”

No, we are not.

IoT is not a setup task. It is a living system. It depends on networks, power, firmware, environments, and people. The moment you walk away thinking the job is finished is the moment problems start lining up quietly.

I caught myself smiling too early more than once.

Dashboards give confidence. Continuity demands discipline.

One shows you data.
The other earns trust.

Start Calm, Not Defensive

When data disappears, panic is natural.

The first instinct is often to blame the IoT platform.

But here is a simple rule that has saved me countless hours.

If the platform were really down, everything would stop.

All devices.
All data streams.
All dashboards.

Platforms do fail, but when they do, they fail loudly.

So if only one device goes quiet, or just a few sensors disappear, the problem is almost always somewhere else.

I tell myself this every time. Breathe first. Then diagnose.

Troubleshooting is not about pointing fingers. It is about narrowing the truth.

Connectivity Breaks More Systems Than Code

Most IoT failures are not complicated.

They are forgotten changes.

One common story involves Wi Fi.

Sensors work perfectly for months.
Data flows.
Everyone forgets they exist.

Then suddenly, silence.

What happened?

Someone changed the network name.
Or updated the password.
Or replaced an access point.

No announcement. No warning.

The IT team did their job. The sensors were simply not in their mind.

Machines never forget. People do.

The same thing happens with cellular networks. Coverage shifts. Base stations go down. Buildings block signals. Sometimes there is simply no other tower to talk to.

Connectivity is fragile. Always question it early.

Power Is Never a Small Detail

If there is one lesson I wish every IoT builder would take seriously, it is this.

Power decides everything.

Battery-powered devices do not fail dramatically. They fade away quietly.

Solar-powered systems look perfect on paper until cloudy days stretch longer than expected.

I have seen devices placed outdoors with confidence in solar charging, only to stop transmitting because the battery never recovered.

I remember asking myself, “Why didn’t we check the battery level?”

Every remote device must report its own energy health.

Battery level matters.
Charging status matters.
Energy trends matter.

If you do not watch power, it will surprise you at the worst time.

Hardware Lives in the Real World

We love talking about cloud systems and apps.

But IoT lives outside.

Rain falls.
Heat builds up.
Humidity creeps in.
Lightning strikes.

Boards short circuit. Connectors loosen. Devices age.

Sometimes the device is simply broken.

No amount of dashboards can fix damaged hardware.

Software forgives. Physics never does.

This is why placement, casing, grounding, and environmental awareness matter far more than people think.

Firmware Can Help or Hurt You

Firmware sits quietly in the background until it does not.

Change it carelessly, and devices disappear.
Never change it, and vulnerabilities grow.

Remote systems need over-the-air updates, but that alone is not enough.

You need to know which device runs which version.
You need a way to recover when updates fail.
You need discipline.

Without that, scaling feels stressful instead of rewarding.

You Must See Both Sides Clearly

Serious IoT work demands a wider view.

You cannot focus only on software.
You cannot focus only on hardware.

You need to understand how the app, device, network, and power behave.

And more importantly, how they fail together.

That is why platforms matter. Not because of charts, but because they help you see the whole chain when things stop working.

A good platform does not just show data. It helps you ask the right questions when data disappears.

The Shift Nobody Warns You About

There is a quiet transition every IoT builder goes through.

At first, dashboards excite you.
Later, inconsistency frustrates you.
Eventually, responsibility humbles you.

The moment someone depends on your system, everything changes.

You stop chasing features.
You start chasing stability.
You stop admiring charts.
You start valuing calm silence.

I once realised that boring systems are often the best ones.

Because boring usually means reliable.

Why This Matters Now

As more devices enter buildings, cities, farms, factories, and public services, silence becomes dangerous.

No data is not just a technical trouble.
It is broken trust.

People stop believing.
Teams lose confidence.
Organisations lose sleep.

Trust takes years to build and seconds to lose.

That is why learning IoT must go beyond dashboards. We need to talk openly about failure, continuity, and responsibility.

A Quiet Invitation

If you are a student, do not rush past problems. Sit with them. They are shaping how dependable you will become.

If you are a developer, stop asking only what features to add. Start asking what can quietly fail.

If you are an organisation, invest in people and systems that understand the whole picture, not just the surface.

And if you have already felt that heavy moment when the dashboard went quiet, you are not alone.

That moment means you care.

Share your story.

When was the first time your system stopped sending data?
What did that moment teach you?

Write it in the comments.

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.

Owning the Kitchen: Why We Built the Favoriot Platform Developer Plan for People Who Build for Others

There are moments in this journey where I stop, lean back in my chair, and ask myself a very simple question.

Who am I really building this for?

Not the slides.
Not the feature list.
Not the pricing page.

The real humans.

The ones wiring sensors late at night.
The ones deploying devices in places nobody wants to visit twice.
The ones whose customers call at 7 a.m. asking, “Why is the dashboard blank?”

This blog is about those people.

This blog is about why I insisted we needed something called the Favoriot Developer Plan.

And why, for some builders, it changes everything.

Not Everyone Is Just “Using” an IoT Platform

Early on, I realised something uncomfortable.

Many people assumed Favoriot was just another place to view charts.

Log in.
See a graph.
Log out.

But that was never the real story.

I thought to myself, if that’s all we become, we’ve failed the serious builders.

Because some users are not there to monitor one device.

They are there to build services.
They are there to serve clients.
They are there to run a business on top of the platform.

System integrators.
Solution providers.
Engineers who sign contracts, not tutorials.

And these people don’t need toys.

They need a kitchen.

When One Dashboard Is Not Enough

One of my favourite real-world examples comes from a team offering indoor air quality monitoring.

Simple problem on the surface.

Measure CO₂.
Measure temperature.
Measure humidity.
Show the data.

But reality is never that clean.

Each customer wanted their own view.
Each building had different thresholds.
Each management team wanted different access.

So the question became obvious.

How do you serve many customers without creating chaos?

This is where multi-tenancy stopped being a buzzword and became a survival tool.

With the Developer Plan, each customer lives in their own space.

Their own dashboards.
Their own logins.
Their own sense of ownership.

No accidental peeking.
No data leaking.
No shared confusion.

Just clean separation, built for trust.

Analytics Is Not Just Pretty Charts

Let me be honest.

Most people stop at charts.

Real-time lines moving left to right.
Historical graphs with sliders.

That’s descriptive analytics.

Useful. Necessary. But incomplete.

I kept asking myself, what happens after people stare at the dashboard?

This is where things get interesting.

Diagnostic: Understanding the “Why”

At some point, users ask deeper questions.

Why did the spike happen at 3 p.m.?
Why does Monday look different from Friday?
Why did last week feel off?

Diagnostic analytics gives context.

Averages.
Minimums.
Maximums.
Patterns across time windows.

Suddenly, the dashboard stops being a screen and starts becoming a story.

Predictive: Seeing What Comes Next

Now we cross a line.

Instead of reacting, we begin anticipating.

Using machine learning models trained on sensor data, the system can estimate what might happen next.

An hour from now.
Later tonight.
Tomorrow morning.

This is the moment many users go quiet and just stare.

Because the platform is no longer waiting for events.

It’s whispering what might be coming.

Prescriptive: Acting When It Matters

This is where responsibility enters the room.

If the system knows something is heading toward risk, what should it do?

Do nothing?
Notify someone?
Trigger an action?

With prescriptive logic combined with our rule engine, the platform can respond.

Send a Telegram alert.
Email management.
Notify an engineer on duty.

And yes, in some cases, trigger actuation directly.

But I’ll say this clearly.

Some decisions still belong to humans.

Technology should support judgment, not replace it blindly.

Teaching Machines to Understand Risk

One feature I care deeply about is state classification.

Instead of raw numbers, we classify conditions.

Low risk.
Medium risk.
High risk.

This is not about making data fancy.

It’s about making data usable.

Because when someone is responsible for people’s safety, they don’t want to interpret charts at 2 a.m.

They want clarity.

When Devices Are Far Away, and Silence Is Expensive

There’s a painful truth in IoT.

Devices don’t live in offices.

They live on rooftops.
In factories.
In rural areas.
Across states.

Bringing them back just to update firmware is not a plan. It’s a liability.

That’s why over-the-air firmware updates matter so much in the Developer Plan.

You push updates remotely.
You fix bugs without travel.
You sleep a little better.

I’ve seen teams save weeks of work because of this.

The Quiet Hero: Edge Gateway

This is one of those features that few people talk about, but everyone feels.

Devices speak different languages.
Different payloads.
Different structures.

Instead of forcing developers to rewrite firmware again and again, the edge gateway steps in.

It maps data formats.
It normalises inputs.
It makes integration smoother.

Less friction.
Less rework.
More momentum.

Scaling Without Counting Every Call

One subtle pain point system integrators face is limits.

Counting API calls.
Worrying about overages.
Splitting usage by customer.

So we raised the daily API quota.

From fifty thousand to five hundred thousand calls per day.

That change alone unlocked new confidence.

Now builders can focus on serving customers, not watching counters.

The Restaurant Analogy That Still Makes Sense to Me

I still like using food analogies because they are honest.

A free plan is walking into a restaurant to see the menu.
A lite plan is tasting something simple.
A beginner plan is enjoying a full meal.

But the Developer Plan?

That’s owning the kitchen.

You decide the menu.
You cook for different tastes.
You serve customers your way.

And with ownership comes responsibility, pride, and freedom.

Why This Matters to Me

I didn’t build this plan to show off features.

I built it because I’ve been that engineer.
I’ve been that system designer.
I’ve been the one answering tough calls.

I wanted builders to feel supported, not boxed in.

If you are building for others, managing clients, and turning ideas into services, this plan was made with you in mind.

And if you’re still unsure, that’s okay.

Explore.
Ask questions.
Build slowly.

The kitchen will be there when you’re ready.

I’d love to hear from you.
What are you building, and what’s holding you back right now?

Why We Believe Universities Need a Favoriot Platform Ecosystem, Not Just IoT Accounts

I shared this idea in a recent product presentation, but the more I reflect on it, the more I feel this deserves to be written down properly. Slowly. Honestly. With feeling.

Because this is not just about plans and pricing.
This is about how we teach, how we learn, and how knowledge grows over time.

I remember pausing for a moment before the session began.
“Do people really see this problem yet?” I asked myself.

Most do not. And that is exactly why I want to tell this story.

The quiet problem nobody talks about

For years, I have watched how IoT is taught in universities.

Students are told, “Go subscribe.”
Lecturers say, “Use whatever tools you can find.”
Labs run on goodwill, workarounds, and personal accounts.

On the surface, it looks fine.

Free plans here.
A few paid plans there.
Some students pay out of pocket.
Some lecturers try to stretch limited lab budgets.

But beneath that surface, something feels broken.

I thought to myself, this is not how serious engineering should feel.

IoT is not a hobby once it enters a lab.
It is not a toy when it becomes a Final Year Project.
It is not casual when research data needs months, sometimes years, to mature.

Yet we treat the tooling like disposable apps.

Individual accounts versus institutional thinking

Most users experience Favoriot through individual plans. Free. Lite. Beginner. Developer.

That makes sense at the start.

You are curious.
You want to test.
You want to learn.

But universities are not individuals.

They are systems.

And systems need structure.

What usually happens today is this:

A student creates an account.
They collect data for a semester.
They graduate.
The account disappears.
The data disappears.
The knowledge disappears.

And every time this happens, I feel a quiet sense of loss.

Because data is not just numbers.
Data is effort.
Data is learning.
Data is time that never comes back.

The moment the question became clear

During the session, I asked a simple question.

What if universities could manage IoT accounts the way they manage labs?

What if, instead of hundreds of disconnected student subscriptions, there was one administrator, one place of control, one long-term memory?

That question changed everything.

I remember thinking, this is the missing layer.

What an IoT Ecosystem Plan really means

The Favoriot IoT Ecosystem Plan is not a fancy label.

It is a mindset shift.

Instead of students owning accounts, the institution owns the ecosystem.

One administrator manages a pool of plans.
Beginner. Lite. Developer.
Whatever fits the teaching or research need.

Accounts can be allocated.
Accounts can be rotated.
Accounts can be reused.

No chaos.
No loss.
No, starting from zero every semester.

A lab that finally makes sense

Imagine a lab with thirty Beginner plans.

The admin assigns ten accounts for this semester’s lab class.
Students log in.
They build.
They experiment.
They learn.

Next semester, the same accounts are reused by a new cohort.

I smiled when I explained this part.
Because this is how labs should work.

Not emotional budgeting.
Not last-minute subscriptions.
Not students asking, “Sir, do I really need to pay for this?”

Final Year Projects without financial anxiety

Final Year Projects are intense.

Students are already under pressure.
Deadlines.
Expectations.
Demonstrations.

Now add one more burden: the cost of tools.

I paused again when I talked about this.
“Why are we doing this to them?” I wondered.

Under the ecosystem plan, the department allocates accounts to FYP students.

No personal subscriptions.
No awkward reimbursements.
No half-built systems because the plan expired.

Just focus.
Just building.
Just learning.

Research data that does not vanish

This part matters deeply to me.

Research does not run on semesters.

Some datasets need months.
Some need a full year.
Some become valuable only after long observation.

In individual accounts, when a researcher leaves, the data often goes with them.

With an ecosystem plan, the data stays.

The account belongs to the institution.
The history remains intact.
The next researcher continues the story.

I remember thinking, this is how real research continuity should feel.

One dashboard. One view. One sense of control

Administrators often feel blind.

Who is using what?
Who is stuck?
Which lab is active?
Which accounts are idle?

An integrated dashboard changes that.

You can see progress.
You can spot gaps.
You can improve training.

This is not about surveillance.
This is about care.

Care for students.
Care for lecturers.
Care for outcomes.

Not one-size-fits-all, and that is the point

Some universities need thirty Beginner plans.
Some need seventy.
Some mix Beginner with Developer plans.

That is why ecosystem plans are quoted, not clicked.

Because education does not fit into neat boxes.

I told myself, flexibility is respect.

Respect for different teaching styles.
Respect for different research scales.
Respect for different budgets.

Why I feel strongly about this

I have spent decades in education, industry, and startups.

I have seen what happens when systems are built for convenience instead of continuity.

And I have also seen what happens when institutions think long-term.

This ecosystem idea is not about selling more plans.
It is about lifting the quality of learning.

It is about treating IoT education as a serious craft.

A quiet invitation

If you are a lecturer, ask yourself this:

Are your students building knowledge, or just finishing assignments?

If you are a researcher, ask this:

Will your data still matter when you move on?

If you are an administrator, ask this:

Is your IoT lab a collection of accounts, or a living system?

I know my answer.

I believe universities deserve an IoT ecosystem that grows with them, remembers with them, and supports the next generation better than we were supported.

If this idea resonates with you, I would love to hear your thoughts.

Drop a comment.
Challenge it.
Improve it.

That is how ecosystems begin.

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.

We Gave Our Favoriot IoT Platform Away for Free—Here’s What Actually Happened Next

A quiet, honest story about how Favoriot found its way

I remember the early days of Favoriot very clearly.
It started with a simple belief. If we make it free and easy, people will come. They will build. They will stay.

So we did exactly that.

We built the platform.
We opened the doors.
We told the world, “Come in. Try it. It’s free.”

And people did come. Students. Lecturers. Curious engineers. Friends I met during talks at universities. I would personally invite them. Sometimes I would even hand out complimentary access codes for a full year of the Beginner Plan.

I thought to myself, this is how adoption works.

But something felt off.

When subscribers were not really users

On paper, the numbers looked comforting.
Subscribers were growing. Accounts were created. Dashboards were viewed.

But deep down, I knew something was missing.

Why are so many accounts quiet?
Why do I see logins, but no devices connected?
Why do dashboards stay empty?

That was my first hard lesson.

A subscriber is not always a user.
And a user is not always a builder.

Many people came just to look around. They clicked. They browsed. Then they left. Some even won vouchers but never built a single IoT project.

It hurt a little. Not because of revenue. But because I wanted Favoriot to be used. I wanted it to matter.

The wrong assumption about behaviour

I used to think users would log in every day, tweak dashboards, run experiments.

Reality taught me otherwise.

A typical IoT builder behaves differently.

Once the device connects and the data flows, they step back. They look at the dashboard occasionally. They only return when something breaks or when the project evolves.

Students behave differently, too.

They come intensely during one semester. Final year project season. Late nights. Panic. Excitement. Then, silence.

And to make it harder, many of them already knew other platforms. Some popular. Some free. Some are recommended by seniors.

Favoriot was often an unfamiliar name.

So ,how do you enter the education space when choice is already wide open?

Teaching before selling

I stopped pushing plans and started focusing on learning.

We introduced public IoT training. Beginner. Advanced. Mastering IoT.
Lecturers started attending. Some became trainers themselves. They went back to their universities and taught students using what they learned.

That felt good.

Then we went a step further.

Professional certificates.
Either embedded into the curriculum or offered as short intensive training. Students could finish the course and receive a certificate, or sit for an exam and earn a more formal credential.

Interest grew. Enquiries came in.

But adoption was still slow.

Universities move carefully. Curriculum changes go through committees, boards, and senate meetings. Nothing moves overnight.

I had to learn patience.

Labs instead of just logins

That’s when we bundled everything.

Not just software.
Not just subscriptions.

We created labs.

An IoT Lab with devices, Beginner subscriptions, training, and ready-to-use kits like indoor air quality monitoring.

An AIoT Lab with more advanced tools. Edge devices. Developer Plan access. Machine learning features. Analytics. A space for research, experimentation, and deeper thinking.

Suddenly, Favoriot was no longer just a platform.
It became an environment.

That changed the conversation.

Why Favoriot stayed a platform, not an app

People sometimes ask me, why not make Favoriot simpler? Why not hide everything?

Because IoT is not simple.

If everything is hidden, nothing is learned.

Favoriot is a Platform-as-a-Service by choice. Builders can see the flow. Devices. Protocols. Data ingestion. Visualisation. Rules. Actions.

When something fails, they learn how to troubleshoot.

When they graduate, they carry understanding, not just button-clicking habits.

That’s the skill that survives in the real world.

The restaurant analogy that finally made sense

One day, while explaining our plans, I caught myself using a food analogy. And suddenly, everything clicked.

The Free Plan is peeking into a restaurant.
You look at the menu. You walk around. Then you leave.

The Lite Plan is tasting the food.
You sit down. You try a dish. You smile.

The Beginner Plan is a full meal.
You are satisfied. You build. You complete your project.

The Developer Plan owns the kitchen.
You cook. You create menus. You serve your own customers.

The Enterprise Plan owns the whole restaurant.
You decide everything. Security. Scale. Who gets served and how.

When I explained it this way, people finally nodded.

Overseas users and a quiet mystery

Here’s something that still amazes me.

Favoriot has users from more than 130 countries.
Yet most revenue comes from Malaysia.

How did they even find us?

Blogs.
E-books.
Social media posts.
YouTube. TikTok. Facebook groups.

They came. They explored. Most stayed free.

And that taught me another lesson.

Free users overseas were often explorers. Platform shoppers. Comparing interfaces. Looking around.

Not every visitor is ready to commit.

And that’s okay.

Personas matter more than pricing

Over the years, I stopped blaming pricing.

Instead, I studied personas.

Browsers.
Tasters.
Builders.
Integrators.
Operators.

Each one needs a different message.

Each one enters the journey at a different door.

And that was the missing piece all along.

Partners instead of long walks alone

I also realised something else.

We cannot do everything ourselves.

We do not have endless arms and legs to reach every market.

So we shifted.

System integrators.
Hardware partners.
Domain experts.
Universities.

They already speak the language of their customers. We just give them the kitchen.

That felt right.

AI as my late-night thinking partner

I will admit this honestly.

AI changed how I think.

When I was in corporate life, clarity came from meetings, workshops, and committees.

Today, clarity comes at night. Quietly. One question at a time.

I talk.
I reflect.
I get challenged.

Not every suggestion is usable. But every session sharpens my thinking.

Sometimes, you just need a friend who listens without ego.

Community as the long game

Lately, I spend more time on LinkedIn.

I see students from India proudly showing their projects. Some use other platforms. Some barely send data to the cloud.

I comment. I encourage. I invite.

“Try Favoriot.”
“Show us your project.”
“We will feature your story.”

Because visibility matters.

When builders are seen, they stay longer.

And when they grow, they remember.

This journey is still unfolding

Go-to-market favoriot

Favoriot did not arrive here overnight.
It took years of confusion, wrong assumptions, quiet learning, and small corrections.

But today, the path feels clearer.

Free curiosity has a place.
So does tasting.
So does building.
So does owning the kitchen.

If you are just browsing, welcome.
If you are ready to build, stay.
If you want to serve others, let’s talk.

And if you are a student building your first IoT project somewhere in the world, remember this.

The platform you choose today might become the one you trust tomorrow.

I would love to hear your thoughts.
Where are you in this journey?
Peeking, tasting, cooking, or running the whole place?

Leave a comment. Let’s talk.