Tag: Favoriot

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

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

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

“What IoT platform are you using?”

The answers came quickly.

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

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

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

That moment stayed with me long after the talk ended

We Are Obsessed With Dashboards, But Forget the Foundation

Let me be honest.

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

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

Nothing wrong with that. Dashboards matter. Visibility matters.

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

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

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

That is the first quiet weakness nobody talks about.

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

Using a foreign platform feels comfortable.

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

But distance has a price.

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

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

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

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

This is where my heart always leans forward.

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

You do not just get software.

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

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

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

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

Let me put this simply.

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

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

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

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

And no, this is not charity.

It is shared growth.

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

Bundling Is About Completing the Story, Not Selling More Stuff

Here is another truth most people avoid.

Almost nobody builds everything themselves.

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

That is normal.

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

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

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

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

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

Ego Is the Silent Killer of IoT Ecosystems

This is the part that makes people uncomfortable.

Ego.

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

I have seen this mindset slow down brilliant teams.

I told myself, collaboration is not surrender.

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

It gives you angles you cannot create on your own.

Universities, Startups, Platforms. We Need Each Other.

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

Separately, we struggle.
Together, we move.

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

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

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

Why This Matters More Than Ever

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

But these words mean nothing if we keep outsourcing belief.

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

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

And when you grow, they grow with you.

A Quiet Invitation

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

Ask yourself:

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

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

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

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

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

Contact Favoriot and let’s build IoT solutions together.

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

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 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.

I Thought Favoriot Users Were Like Any Other SaaS Users. I Was Wrong.

For a long time, I carried a quiet assumption in my head.

I told myself, “A user is a user. SaaS is SaaS.”

I thought Favoriot users would behave like most consumer SaaS users. Log in daily. Click around. Expect things to feel smooth, friendly, almost playful. If something took too long, they would leave. If a screen felt confusing, they would complain. If onboarding was not instant, they would disappear.

That mental model sat comfortably in my head. Too comfortably.

Then one day, a simple question landed in my lap.

A question that forced me to stop using generic labels and actually picture real humans.

I paused.

Who exactly is using Favoriot?

And once I answered that honestly, everything shifted.

What I Actually See When I Think About Favoriot Users

When I close my eyes and picture a Favoriot user now, I don’t see someone lounging on a couch, scrolling through a polished interface with a coffee in hand.

I see something else.

I see sensors scattered on a desk.
Loose jumper wires tangled like spaghetti.
A laptop open with a dashboard on one screen.
Telegram buzzing on the other.
A multimeter nearby.
Sometimes a soldering iron.
Sometimes panic.
Sometimes excitement.

I see people trying to make something real work.

Ah. This is not a consumer SaaS crowd.

This is a builder crowd.

Builders, Not Browsers

Favoriot users are builders.

They don’t log in to be entertained.
They don’t log in to feel productive.
They log in because something must work.

A lecturer wiring ESP32 boards in a lab late in the evening.
A student is testing temperature data at 2 a.m. before demo day.
An engineer is checking why a sensor stopped reporting right after a rainstorm.

Their first question is almost never about aesthetics.

It’s usually raw and practical.

“Can I connect this device?”
“Is the data coming in?”
“Why did it stop at 3:17 p.m.?”
“Did I configure something wrongly or did the network die?”

They are hands-on by instinct.

And once I accepted this, I had to admit something uncomfortable.

I had been projecting the wrong expectations onto them.

Problem First, Not Feature First

Most consumer SaaS users start with features.

They ask things like:

“Does it have dark mode?”
“Can it sync with my calendar?”
“Is there a mobile app?”
“Can I customise the theme?”

Favoriot users start with a problem.

“I need to monitor the water level.”
“I must prove this concept works before funding.”
“My lecturer wants a dashboard by Friday.”
“My boss wants alerts, not charts.”

Features only matter if they help solve that problem quickly.

If a feature does not move them closer to a working outcome, it may as well not exist.

This was a big wake-up call for me.

I realised that talking about features without anchoring them to real use cases was missing the point entirely.

Learning While Doing Is the Default Mode

Another thing I misunderstood.

I used to think users came prepared. That they would read everything first. That they would know what they were doing.

Reality check.

A large portion of Favoriot users are learning while doing.

Students.
Fresh engineers.
Lecturers experimenting with new lab setups.
SMEs touching IoT for the first time.

They are not experts yet. And they know it.

They expect mistakes.
They expect trial and error.
They expect data that looks wrong at first.
They ask questions like:

“Did I wire this wrongly or configure it wrongly?”
“Why is the payload showing weird values?”
“Is this sensor faulty, or am I misunderstanding the units?”

Consumer SaaS users expect things to just work.

Favoriot users expect to work through things.

That difference matters more than most people realise.

A Bit of Friction Is Not the Enemy

Consumer SaaS products live in fear of friction.

One extra click and users leave.
One confusing screen, and churn happens.
One long form and conversion drops.

Favoriot users are different.

They tolerate friction if it leads somewhere meaningful.

They accept setup steps.
They read tutorials.
They debug payload formats.
They learn what MQTT or HTTP means.
They try again after failing.

As long as the payoff is real data and real insight, they stay.

I remember thinking to myself, “They are not lazy users. They are patient users with a purpose.”

That insight changed how I think about onboarding, documentation, and even UI decisions.

Usage Comes in Bursts, Not Habits

Here’s another mistaken assumption I had.

I assumed success meant daily logins.

That is true for many consumer tools.

It is not true for Favoriot.

Favoriot usage is project-based.

Users may log in intensely for two weeks.
Then disappear.
Then return when deployment starts.
Then vanish again.
Then come back when something breaks.

This is not abandonment.
This is reality.

Favoriot is not a habit-forming app.
It is a project enabling platform.

Once I stopped forcing a consumer SaaS lens onto usage patterns, the data suddenly made sense.

Ah. They didn’t leave. They just finished phase one.

Credibility Matters More Than Vibes

This part surprised me the most.

Favoriot users care deeply about credibility.

They ask questions like:

“Is this used by real organisations?”
“Can I show this to my supervisor?”
“Will this scale if my pilot succeeds?”
“Can I put this in my report or proposal?”

Consumer SaaS users care about brand feeling.
Favoriot users care about trust.

They want to know that what they are building on will not collapse when things get serious.

This is why things like:

Clear documentation.
Real case studies.
Honest limitations.
Professional dashboards.

matter more than flashy design.

They are building something that must stand scrutiny.

A Simple Mental Contrast That Helped Me

Once I framed it this way, everything clicked.

Consumer SaaS user:
Browses.
Seeks convenience.
Is the feature curious?
Hates setup.
Form daily habits.
Is emotion-led?

Favoriot user:
Builds.
Seeks control.
Is problem driven.
Accepts setup if useful.
Works in project bursts.
Is outcome-led.

Two very different humans.

Why This Changed How I Talk About Favoriot

I now remind myself constantly:

Stop comparing Favoriot to Notion, Canva, or Spotify.

Favoriot is closer to:

A lab bench.
A toolbox.
A test rig.
A learning environment.

This is why certain decisions suddenly felt obvious.

Why Lite plans for students matter.
Why simple dashboards matter.
Why examples matter more than slogans.
Why tutorials matter more than polish.
Why honesty beats hype.

Favoriot users don’t want magic.

They want clarity.

They want to understand what is happening.
They want to know what to do next.
They want confidence that they are not wasting time.

And when they succeed, something interesting happens.

They stay.
They recommend.
They come back with bigger ideas.

The Real Lesson I Had to Learn

The biggest mistake I made was not technical.

It was mental.

I assumed the wrong persona.
So I used the wrong language.
So I emphasised the wrong things.
So I measured the wrong signals.

Once I corrected that, everything else became easier.

Marketing messages became clearer.
Product decisions felt grounded.
User feedback made sense.

I remember thinking, “This is not about making things simpler for the sake of simplicity. It is about making things understandable for builders.”

That distinction matters.

Where This Leaves Me Now

Today, when I write, design, or explain Favoriot, I imagine a real person.

Someone with wires on the table.
Someone racing against a deadline.
Someone is trying to prove that an idea works.

If my message helps that person move forward, then it is doing its job.

If not, it needs rewriting.

And maybe that is the real takeaway.

Before we talk about growth, conversion, or positioning, we must first answer one honest question.

Who is actually on the other side of the screen?

If you are building, teaching, or learning with Favoriot, I would love to hear your story.

Drop a comment.

How Lecturer Feedback Inspired the Favoriot Lite Plan

Why a University Lecturer’s Feedback Changed Everything and Led to the Favoriot Lite Plan

This story did not start in a boardroom.

It did not start with pricing spreadsheets or growth charts.

It started with a simple, honest conversation with a university lecturer.

A conversation that stayed with me longer than expected.

“Dr. Mazlan, the Beginner plan is good. But for teaching and students, it feels a bit too expensive. And honestly, we do not need all the features. We just need a few dashboards that work well.”

I remember pausing for a moment.

Not because I disagreed.
But because I knew they were right.

That Moment of Realisation

I have spent years working closely with universities. I have seen how students learn best. I have stood in labs where excitement fades the moment tools feel heavy or out of reach.

When that lecturer shared their concern, I did not hear a complaint.

I heard care.

Care for students.
Care for learning.
Care for making sure curiosity does not die because of cost or complexity.

I thought to myself…

If a lecturer is already trying to stretch budgets just to give students real exposure, are we truly helping if we keep things as they are?

That question would not leave me alone.

The Truth About Teaching IoT

Teaching IoT is not about showing everything.

It is about showing enough.

Students do not need ten dashboards.
They need one or two that make sense.

They do not need advanced workflows on day one.
They need to see data move from a device to the cloud and onto a screen they understand.

Most importantly, they need confidence.

And confidence comes from simplicity.

The lecturer was clear.
Less features.
Lower cost.
Focused dashboards.
Real experience.

That feedback mattered.

Why the Lite Plan Had to Be Created

The Favoriot Lite Plan exists because of that conversation.

It exists because education should not feel like a compromise.

The goal was never to strip things down until nothing meaningful remained. The goal was focus.

Lite uses the same core platform that powers real projects on the Favoriot platform.

What we changed was intent.

Lite focuses on a small number of dashboards that matter for teaching and learning. Clean. Clear. Purposeful.

No unnecessary features.
No distractions.
No pressure on budgets.

Just what students and lecturers actually asked for.

Designing Lite With Students in Mind

I kept picturing a classroom.

A lecturer standing in front.
Students are opening their laptops.
Devices blinking on the table.

What do they really need at that moment?

They need to connect.
They need to see data.
They need to understand what just happened.

Lite delivers exactly that.

Students can focus on learning instead of navigating menus. Lecturers can focus on teaching instead of explaining why certain features will not be used this semester.

That was the win.

Why Fewer Dashboards Can Mean Better Learning

This might sound counterintuitive to some.

More features do not always mean more value.

In teaching, fewer dashboards often lead to deeper understanding. When students can concentrate on one or two views, patterns become clearer. Questions become sharper.

Why is the data changing?
What caused that spike?
How does the sensor behave over time?

Those questions matter more than fancy configurations.

Lite gives room for those conversations.

About Cost and Respect

I want to say this clearly.

Lowering the entry cost was not about discounts or promotions. It was about respect.

Respect for students who are still learning.
Respect for lecturers who fight for better tools within tight budgets.
Respect for institutions that want real exposure without overcommitting.

Education should never feel excluded from real platforms.

Lite is our way of saying, you are welcome here.

Not a Step Back, Just a Better First Step

Lite is not a lesser plan.

It is a thoughtful one.

When students finish their projects and want more, moving up feels natural. When lecturers want to expand labs or pilots, the path is clear.

Nothing is lost.
Nothing needs to be rebuilt.

You simply grow from where you started.

What This Means to Me Personally

That lecturer probably does not realise how much their feedback meant.

But it reminded me why Favoriot exists.

Not just to build technology.
But to remove barriers.

I asked myself…

If our platform cannot support learning at its earliest stage, what are we really building?

The Lite Plan is my answer to that question.

An Invitation to Lecturers, Students, and Builders

If you are a lecturer looking for a practical way to teach IoT without overwhelming students, Lite was built with you in mind.

If you are a student who wants hands-on experience without worrying about cost or complexity, this is your starting point.

If you are building something small and want clarity before commitment, Lite is enough.

You can explore the plans here
https://www.favoriot.com/iotplatform/pricing/

I would genuinely love to hear your thoughts.

What do you need in the classroom?
What feels too much today?
What would make learning easier?

Leave a comment. Share your experience. Start a conversation.

Sometimes, the most meaningful changes come from one honest piece of feedback.

When Writing Free eBooks Still Feels Like Shouting Into the Void

I did not expect this feeling to arrive so quietly.

No dramatic moment.
No emotional breakdown.
Just a soft question that kept returning while I stared at my screen.

Should I stop writing eBooks about IoT, startups, and entrepreneurship?

I have written several eBooks over the years. Some came from years of experience building platforms. Some from scars earned while running a startup. Some from observing founders struggle with the same blind spots again and again.

I made them free.
No paywall.
No upsell tricks.
Just knowledge, stories, and lessons shared openly.

Yet after my last three books (Hello IoT, The Favoriot Way: A Life Built on Curiosity and Courage, Favoriot : The Journey of an IoT Startup), something felt off.

Downloads slowed.
Shares dropped.
The quiet became louder.

At first, I blamed myself.

Maybe the topics are stale.
Maybe I am repeating myself.
Maybe people are tired of hearing from me.

Then another thought crept in.

Or maybe the world has changed.

The Moment I Could No Longer Ignore

I noticed something about my own habits before blaming anyone else.

I no longer Google as much.
I open ChatGPT.
I type a question.
I get an answer.

Direct.
Fast.
Clean.

And here is the uncomfortable truth.

I am guilty too.

I ask AI to summarise books.
I ask for key takeaways.
I skim instead of sitting with pages.

Who am I to complain when I do the same thing?

That realisation stung.

Because I used to love reading slowly. Highlighting sentences. Rereading paragraphs. Letting ideas sit for days.

Now, time feels compressed. Attention feels borrowed. Everything competes for mental space.

The Silent Shift No One Talks About

This is not about AI replacing writers.

It is about AI changing readers.

People no longer want to search.
They want answers.

They no longer want ten blog posts.
They want one response.

They no longer want to explore.
They want to arrive.

Why buy a book when a prompt gives you a clean summary?

Why spend hours reading when minutes feel enough?

That question hurts writers, but it is not wrong.

Books were once a journey.
Now they are treated like databases.

Tell me what matters. Skip the rest.

Short Attention Is Not a Moral Failure

I hear people complain about attention spans all the time.

But I do not think it is laziness.
I think it is survival.

We are flooded with inputs. Messages. Alerts. Updates. Noise.

Reading a 150-page eBook feels heavy when your mind is already full.

The new generation did not lose patience.
They adapted to overload.

They want clarity, not volume.
Direction, not depth.

At least not by default.

When Free Still Feels Expensive

Making my eBooks free was supposed to remove friction.

Yet free does not mean easy.

Reading still costs time.
Thinking still costs energy.

AI removed that cost.

One prompt feels cheaper than one chapter.

So why am I surprised?

The Hard Question I Keep Avoiding

I keep asking myself something uncomfortable.

Am I writing for impact, or am I writing out of habit?

In the past, writing eBooks felt like leaving a trail behind. Something lasting. Something searchable. Something meaningful.

Now it feels like throwing paper planes into a sky full of drones.

They fly faster.
They reach further.
They respond instantly.

Paper planes still matter.
But fewer people look up.

Books Versus Conversations

AI feels like a conversation.

Books feel like a lecture.

That difference matters.

People want interaction. They want follow-up questions. They want context tailored to their situation.

A book cannot ask back.

AI can.

And that changes expectations.

What Writing Used to Give Me

I did not write eBooks just for readers.

I wrote to think.

Writing forced clarity.
It slowed my thoughts.
It made experiences visible.

If I stop writing books, what replaces that?

Blogs?
Short posts?
Conversations?
Voice notes?

I do not know yet.

That uncertainty is unsettling.

Maybe Books Are No Longer the First Door

Here is a thought I am still wrestling with.

Books may no longer be entry points.
They may become reference points.

Not where people start, but where they return when they want depth.

AI gives direction.
Books give texture.

AI answers questions.
Books explain why the questions matter.

But fewer people reach that stage.

The Ego Check I Needed

Another truth I had to face.

I assumed free meant valuable.
I assumed experience meant relevance.

Neither guarantees attention.

The world does not owe writers readers.

Attention is earned every day.

Even by those who have written before.

Am I Really Stopping?

When I say I feel like stopping, I am not quitting writing.

I am questioning the format.

Maybe eBooks are not where my thoughts want to live anymore.

Maybe ideas want to breathe in smaller spaces.
Or in stories.
Or in conversations.

Or maybe fewer books, written slower, with deeper intent.

I am not sure yet.

What I Do Know

AI has changed how we read.
AI has changed why we read.
AI has changed when we read.

That shift is real. It is not a phase.

Fighting it feels pointless.

Understanding it feels necessary.

The Choice In Front of Me

I can keep writing eBooks and accept fewer readers.

I can stop writing books and find new ways to share ideas.

Or I can redefine what a book means in a world that no longer reads the same way.

Right now, I am sitting with the discomfort.

No dramatic announcement.
No final decision.

Just honesty.

A Quiet Ending With an Open Question

I still believe ideas matter.
I still believe stories shape thinking.
I still believe writing is worth doing.

But I no longer believe format guarantees relevance.

Maybe the real question is not whether I stop writing eBooks.

Maybe it is whether I am brave enough to write differently.

If you are a writer, a reader, or someone who quietly stopped reading books, I would love to hear your thoughts.

Have you felt this shift too?

Book Review by a Young Founder: How The Favoriot Way Sparked New Fire in Me

I picked up The Favoriot Way: A Life Built on Curiosity and Courage by Mazlan Abbas at a time when I felt stuck between ambition and uncertainty. The title alone sounded like something a seasoned founder might write after years of success. What I didn’t expect was how personal, honest, and relatable this book would feel from the very first page.

Right away, I could sense this wasn’t a typical business book full of polished charts and bright promises about overnight success. It felt like sitting down with someone a few steps ahead of me on a road I’m still trying to map out. I could almost hear his voice explaining how curiosity pushed him forward in ways no strategy ever could.

Curiosity as a Compass

What hit me first was how Mazlan traced his journey back to childhood curiosity, fiddling with broken radios, wanting to know how things worked. It made me reflect on my own early curiosities. For me, it was taking apart gadgets as a kid, even though I rarely put them back together. Reading that made me laugh and nod at the same time.

As a young entrepreneur, it’s easy to look at seasoned founders and assume they had some secret formula from the start. This book reminded me that the real engine behind growth is simple curiosity showing up with questions and staying with them even when answers aren’t obvious.

Real Talk About Real Challenges

The book moves through Mazlan’s life from student days to corporate leadership and into entrepreneurship with Favoriot. But it doesn’t boast or brag. What stood out most were the honest moments where he wasn’t sure what came next. That was refreshing. I often worry that not knowing the next step means I’m failing. Reading about someone I respect being uncertain and still moving forward felt like a permission slip.

There was one part where he talked about choosing entrepreneurship at an age when many people are thinking about stability. That hit me hard. I’ve always wondered if my dreams make sense in the real world. His reflections made me rethink that fear and see it as part of the journey, not a detour.

Lessons That Feel Personal

What I appreciated most about this book is that it doesn’t give you a checklist of things to do. There are no fluff headlines about “10 steps to success.” Instead, Mazlan shares what he learned about being patient, thinking clearly, and trusting that consistent effort compounds over time. As someone building something from scratch, that perspective felt grounding.

I highlighted lines about:

  • Taking time to think clearly
  • Putting curiosity ahead of shortcuts
  • Treating failure not as a dead end but as data

Every time I paused on a passage, I found myself thinking “Yes, that’s exactly how it feels.” It was like someone had put into words things I’d been feeling but couldn’t articulate.

Accessible and Encouraging

The writing style is simple but powerful. Some moments felt like candid conversations instead of formal text. If you’re like me, juggling ideas and doubts, this tone makes the content feel accessible and encouraging rather than intimidating.

I’ve read business books that left me motivated for a day, only to be forgotten. This one stayed with me at the end of each chapter. It made me reflect on why I’m building what I’m building and how I want to show up for it.

Why This Book Matters for Young Founders

As someone forging my own path, I didn’t need another blueprint. What I needed was perspective. Someone to remind me that uncertainty isn’t a flaw, but part of the startup journey. Someone to say that curiosity will keep me going long after hype fades.

The Favoriot Way gave me that.

It’s short, easy to read, and packed with real insights that feel like they came from lived experience. Whether you are just starting a venture or trying to find clarity in your direction, this book gives you something many other business books don’t: emotional resonance with your struggles.

Final Thoughts

Reading this book felt like a conversation with a mentor who doesn’t sugarcoat but still believes in your potential. For young entrepreneurs like me who sometimes doubt whether we’re on the right track, this was precisely the kind of perspective we need.

It doesn’t tell you what your next move should be. It gives you the confidence to make that move yourself.

If you’re chasing ideas, navigating doubt, or building something that matters to you, The Favoriot Way deserves a spot in your reading list.

Rating: 4.5 out of 5 stars

And if you’ve read it too, I’d love to hear which part spoke to you most. Drop a comment and let’s talk about it.

[Book review: A Young Entrepreneur in the Making]

Download eBooks from Mazlan Abbas

  1. Favoriot – The Journey of an IoT Startup
  2. The Favoriot Way – Life of Curiosity and Courage
  3. Hello IoT
  4. Mastering IoT with Favoriot: A Comprehensive Guide for Business and Educational Institutions
  5. Internet of Things (IoT): A Beginner’s Guide
  6. Startup Survival: The Journey of a Tech Entrepreneur
  7. Your IoT Journey
  8. IoT Notes

Favoriot’s Journey: Lessons from Lord of the Rings

The journey of Favoriot, from its earliest days to where it stands today, mirrors The Lord of the Rings Trilogy in a way that feels less like fantasy and more like lived experience.

Not because of epic battles or dramatic villains, but because both stories are really about endurance, pivots, and choosing to continue when the original plan no longer fits the road ahead.

A Journey That Did Not Start With a Grand Map

When Frodo left the Shire, there was no detailed map to Mount Doom. Gandalf did not hand him a ten-year plan. The mission evolved as dangers revealed themselves.

Favoriot began the same way.

The early vision was simple. Build an IoT platform that works. One that local engineers, researchers, and institutions could rely on. What came next was not a straight line. The platform did not arrive fully formed. It grew through experiments, false starts, and product decisions that looked right at the time but later needed rethinking.

Like Middle-earth, the terrain kept changing.

Products as Paths, Not Destinations

In The Lord of the Rings, the Fellowship does not walk a single road. They split. They detour. Some paths fail. Others reveal their purpose much later.

Favoriot’s products followed the same rhythm.

Early versions focused heavily on basic device connectivity and dashboards. That was the Shire phase. Simple. Familiar. Necessary.

As real customers arrived, the needs shifted. Monitoring alone was not enough. Scale introduced complexity. Rules became more complicated to manage. Alerts became noisy. What worked for a pilot did not hold up in production.

That forced pivots.

  • From simple dashboards to structured data models
  • From manual rules to more intelligent behaviour detection
  • From pure IoT to AI-assisted decision support
  • From cloud-only thinking to edge-aware architectures

Each pivot felt like leaving a known path and stepping into uncertainty. Some features were retired quietly. Others were reshaped instead of discarded. Just as characters outgrow their early roles, products evolve because the journey demands it.

The Cost of Carrying Too Much

Frodo’s burden was not the distance. It was the Ring.

For Favoriot, the “Ring” often took the form of technical debt, early assumptions, and customer expectations set too soon. Decisions made for speed later demanded patience to untangle. Features built for one market created friction in another. Supporting early users while reworking the core tested both systems and people.

Letting go was hard.

Just as Frodo struggled to release the Ring, teams struggle to let go of products they worked hard to build. Yet progress required accepting that not everything belongs in the final version.

Splitting the Fellowship to Survive

The Fellowship did not stay together because it looked nice. It split because survival required it.

Favoriot’s journey did the same. Engineering focused on stability, while product teams listened closely to users. Business teams dealt with timing, cash flow, and long sales cycles. Partnerships opened doors while internal teams strengthened the foundation.

At times, it felt fragmented. In reality, it was a focus.

Each group carried a different part of the burden. No single team saw the whole picture at all times. Trust became the glue.

Long Stretches Without Applause

Middle-earth did not pause to celebrate milestones. Neither did the market.

There were long periods where progress was invisible from the outside. No launches. No announcements. Just refactoring, rewriting, rebuilding. Customers rarely see this phase, yet it defines whether a platform survives.

Favoriot lived in this space for years.

Quiet work. Fewer shortcuts. Many trade-offs. The kind of progress that feels slow until one day it becomes evident that the platform is stronger, calmer, and more reliable than before.

When the Mission Changes the People

By the end of the trilogy, Frodo was not chasing adventure. He was carrying wisdom earned through pain and persistence.

Favoriot’s journey shaped its people the same way.

Engineers learned restraint, not just speed. Product teams learned when to say no. Leaders learned that timing matters as much as vision. The company knew that building trust outlasts chasing trends.

The platform today is not just more capable; it is also more capable. It is more deliberate.

Not Glory, But Completion

Destroying the Ring was not a victory parade. It was relief. Completion.

Favoriot’s goal has never been to build everything or to shout the loudest. It has been to finish what was started. A platform that can grow with its users. A system that learns instead of overwhelming. A foundation that can support the next chapter without collapsing under its own weight.

That goal shaped every pivot.

The Quiet Parallel

Frodo was not the strongest.
Favoriot did not have the most significant budget.
Neither took the shortest route.

Yet both stories prove the same point.

Lasting impact rarely comes from perfect plans. It comes from adjusting without losing purpose, letting go without giving up, and continuing to walk when turning back feels easier.

That is the shared truth between Middle-earth and Favoriot’s journey.
A long road.
Many pivots.
One mission that refused to be abandoned.