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.

The Calm That Comes After You Accept Uncertainty

The Need to Resolve Everything

For years, uncertainty felt like a problem to fix.

An unfinished thought.
An unanswered question.
A situation that had not yet been “figured out.”

I carried it like a weight. If something was unclear, it stayed with me. Followed me into meetings. Lingered after decisions. I believed good leaders reduced uncertainty quickly. Anything left unresolved felt like a personal failure.

That belief created quite a tension.

When Uncertainty Became the Default

Over time, the pattern became obvious. Uncertainty was not an exception. It was the environment.

Markets shift. People change their minds. Priorities move. Even the most carefully planned paths bend once they meet reality. The idea that everything could be settled in advance slowly lost its grip on me.

Once I accepted that uncertainty was permanent, something unexpected happened.

I became calmer.

The Difference Between Control and Awareness

Letting go of certainty did not mean giving up control. It meant redefining it.

Control is not knowing exactly what will happen.
Control is knowing where to pay attention.

I stopped trying to resolve every unknown. Instead, I focused on identifying which uncertainties mattered now and which could wait. Some questions demand immediate action. Others only create noise if answered too early.

Awareness replaced anxiety.

Living With Open Loops

There was a time when open questions bothered me deeply. I wanted closure. Resolution. A sense that nothing important was left hanging.

Eventually, I learned that most meaningful work involves open loops. Partnerships evolve. Products mature. Strategies adjust. Forcing closure too early often created an artificial sense of certainty that later collapsed.

Accepting open loops freed mental space.

I no longer felt the need to tie everything neatly before moving forward.

Decisions Without Emotional Exhaustion

Once uncertainty stopped feeling like an enemy, decisions became less draining.

I no longer replayed them endlessly at night. Not because I was careless, but because I understood their limits. A decision made under uncertainty is not a verdict. It is a step.

Steps can be corrected. Verdicts cannot.

That distinction mattered.

What Calm Really Feels Like

The calm I am describing is not confidence.

It is steadiness.

It comes from knowing that uncertainty will always exist and that this does not make the work reckless or incomplete. It makes it human. It makes it real.

Calm is the absence of urgency where urgency is not required.

How This Changed My Leadership

This shift altered how I showed up with others.

I stopped pretending to have all the answers. I named the unknowns early. I allowed space for learning instead of forcing alignment too quickly. Strangely, this made teams more grounded, not less.

People sense when uncertainty is being hidden. They relax when it is acknowledged.

Accepting Imperfect Progress

Progress stopped looking like clean milestones. It looked more like a direction with correction.

Some weeks moved things forward. Others clarified what not to do. Both counted. Once I accepted this, I became more patient with slow periods and less attached to dramatic movement.

Momentum was no longer measured daily.

When Uncertainty Stops Being Loud

Uncertainty does not disappear. It quiets down.

It becomes background noise rather than a constant alarm. You notice it, but it no longer dictates your emotional state. You work with it, not against it.

That is when calm settles in.

A Different Kind of Confidence

The confidence that follows acceptance is subtle. It is not certainty about outcomes. It is confidence in your ability to respond.

I may not know precisely what will happen next. But I trust my capacity to adjust when it does.

That trust changes everything.

Why This Matters

It is about the internal shift that makes both possible.

The calm that comes after you accept uncertainty is not passive. It is active. It creates space for judgment, learning, and better decisions.

Without it, uncertainty feels like pressure.

With it, uncertainty becomes part of the work.

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.

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

Techtamu Talk | 17 January 2026

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

Before I spoke, I paused for a second.

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

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

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

You Only Understand the Journey When You Look Back

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

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

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

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

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

You just won’t see it yet.

From a Curious Child to a Technology Lifelong Learner

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

It started at home.

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

“So this is how things work.”

Then came science fiction.

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

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

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

“What if we could actually build these things?”

Living in Four Different Worlds

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

Academia.
Corporate.
Government.
Startup.

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

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

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

Each world taught me something different.

But they also gave me baggage.

Experience gives confidence.
It also gives fear.

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

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

That voice gets louder with age.

Silicon Valley Changed Everything

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

That trip changed my identity.

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

I remember thinking:

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

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

I started seeing myself as an entrepreneur.

Not someday.
Not after retirement.
Now.

Starting Late Comes With a Price

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

Just belief and experience.

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

It failed.

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

That was my first real startup lesson.

Good intentions do not build businesses.
Paying customers do.

Learning the Art of the Pivot

In the startup world, pivoting is survival.

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

New problems appeared.

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

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

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

Ending a product.

I shared this honestly during the lecture.

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

A CEO must choose growth over attachment.

When More Products Mean Less Identity

We built other solutions too.

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

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

At some point, I realized something painful.

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

Neither do you.

The Shift That Saved the Company

That realization led to our biggest change.

We stopped building products for users.

We started building a platform for builders.

That platform became Favoriot.

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

This shift reduced risk.

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

Why One Revenue Stream Is Never Enough

Another hard truth I shared with the audience.

Pure SaaS subscriptions rarely pay the bills in emerging markets.

We survived by building multiple streams.

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

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

That balance kept the company alive.

Partners Build What You Cannot

No startup wins alone.

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

Each partner brings strength we do not have.

That is how scale really happens.

Marketing Without Big Budgets

We never had large marketing budgets.

So we wrote.
We shared.
We taught.

Blogs.
Social media.
Free e-books.

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

People do not buy immediately.
But they remember.

The Lesson I Hope You Carry Forward

I ended the lecture with a simple reminder.

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

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

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

I started my startup at 56.

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

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

Why Clear Answers Often Come Late and That’s Acceptable

Clarity as a Prerequisite

Early in my career, I treated clarity as a requirement.

If the answer was not clear, the decision could wait.
If the direction was not obvious, more thinking was needed.
If the picture felt messy, it meant I was not ready.

At the time, this felt responsible. Careful. Sensible.

Only later did I see how often it quietly delayed progress.

When Reality Refuses to Stand Still

Clear answers have a pattern. They usually arrive after the decision, not before it.

This feels backward to many people. We like to believe clarity leads to action. In practice, action often creates the conditions for clarity. Systems evolve. Context shifts. Human behaviour reveals itself only over time.

Waiting does not always sharpen the picture. Sometimes it blurs it.

In fast-moving or people-driven environments, the very thing you are trying to understand changes while you study it.

The Real Discomfort Behind Unclear Answers

When I kept asking, “Can we be sure?”, I eventually realised what I was really asking.

Can we avoid regret?

Unclear answers are uncomfortable because they remove cover. When data does not settle the question, responsibility lands fully on the decision-maker. There is no spreadsheet to hide behind. No expert consensus to borrow.

That weight changes how decisions feel.

Movement Creates Feedback

Over time, a pattern became obvious.

Decisions made while waiting for clarity tend to stall.
Decisions made while accepting uncertainty tend to move.

Movement creates feedback. Feedback creates learning. Learning shapes judgment. Clarity grows from motion, not from endless analysis.

This does not mean rushing. It means recognising when waiting no longer adds value.

Accepting That Decisions Are Time-Bound

Some answers arrived late and contradicted my early expectations. That did not mean the original decision was careless. It meant the environment had changed.

Decisions are made for a moment in time. Expecting them to remain correct forever is unrealistic. What matters is whether they were reasonable given what was known then.

A decision can be appropriate without being permanent.

Defensible, Adjustable, Honest

Once I stopped demanding immediate clarity, I changed how I evaluated choices.

I began asking three questions:

Is this decision defensible with the information we have?
Can it be adjusted without denial or pride?
Are we honest about what we do not know?

These questions mattered more than confidence or certainty.

The Danger of False Clarity

Not all clarity is real.

False clarity often comes dressed in strong opinions, polished slides, or confident language. It settles debates quickly. It also freezes learning too early.

When reality eventually disagrees, the cost of adjustment becomes higher. The earlier rigidity sets in, the harder it is to change course.

True clarity is quieter. It shows up as fewer surprises. Smoother decisions. Better alignment over time.

Patience Without Passivity

Accepting late clarity does not mean doing nothing.

There is a difference between waiting and waiting well. Passive waiting avoids responsibility. Patient waiting stays attentive. It watches signals, prepares options, and remains ready to move.

This distinction matters more than speed.

What Teams Really Need

Working with others reinforced one simple truth.

People do not need certainty as much as they need trust.

When I stopped promising clarity on timelines shaped by people, policy, or adoption, and focused instead on transparency and adjustment, collaboration improved. Expectations became healthier. Pressure eased.

Clarity as a Byproduct

Looking back, many of the decisions that caused the most anxiety eventually made sense. Not because better answers appeared, but because time revealed context.

Some decisions aged well. Others did not. Both were instructive.

Clarity is rarely the starting point.
It is the result.

This essay follows the first for a reason. If the first was about deciding without complete data, this one is about living with unresolved questions afterwards.

In real work, clarity rarely leads.
It follows.

Why Some Partnerships Age Well and Others Don’t

Partnerships do not survive on excitement.

They survive on trust, alignment, and shared expectations.

When conditions change, weak foundations surface quickly. Strong ones adapt quietly.

Some partnerships end not because of failure, but because growth pulls people in different directions.

Learning to let go without resentment is part of maturity.

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?

The Difference Between Being Busy and Building Something That Lasts

I have asked myself this question more times than I care to admit.

Why am I so busy, yet some days it feels like nothing truly moved forward?

There were periods in my life when my calendar was full, my inbox overflowing, my phone buzzing nonstop. Meetings stacked on meetings. Slides prepared. Emails replied. Deadlines chased. I went home tired. Sometimes proud. Sometimes just numb.

And yet, deep down, something felt off.

Busy, yes. But was I building anything that would still matter a year from now? Five years from now?

That question changed how I work, how I decide, and how I say no.

This is not an article against hard work. I believe deeply in effort, discipline, and showing up even when it is uncomfortable. But there is a subtle trap many of us fall into, especially founders, leaders, and builders.

We confuse motion with progress.

Busy Feels Productive. Building Often Feels Slow.

Being busy gives instant feedback.

You reply to an email, it disappears from your inbox. You attend a meeting, you check it off your calendar. You fix a small issue, you feel useful. There is a small hit of satisfaction. Almost addictive.

Building something that lasts is different.

It is quiet. Often lonely. Sometimes boring. There are long stretches where no one claps. No one notices. No one even knows what you are doing.

I remember days when I questioned myself.

Why am I spending hours refining a system that only a handful of users see today?
Why am I writing articles that do not get many likes?
Why am I investing time in documentation, processes, and foundations instead of chasing quick wins?

Busy work would have given me faster validation. Building required patience.

The Illusion of Progress

One of the most dangerous things about being busy is how convincing it feels.

You can spend an entire week reacting.

Responding to messages. Joining calls. Fixing urgent issues. Saying yes because it feels responsible. By Friday, you are exhausted, yet if someone asked, “What changed because of your work this week?” the answer might be unclear.

I have lived that cycle.

It feels responsible. It looks professional. It impresses people around you. But it rarely compounds.

Building something that lasts forces a different question.

If I stop doing this today, will anything break tomorrow?
If I stop doing this for a month, will anything truly be lost?

If the answer is no, then perhaps it was just noise.

Builders Think in Foundations, Not Firefighting

Firefighting makes you look important.

Foundations make you invisible.

When you are constantly solving minor problems manually, people come to depend on you. That feels good for the ego. It feels like you matter. But it also means the system is weak.

I learned this the hard way.

There were moments when everything depended on me. Decisions, approvals, fixes, explanations. If I took a day off, things slowed down. If I went quiet, people panicked.

That is not leadership. That is fragility.

Building something that lasts means working on things that reduce dependency on you.

Clear processes.
Simple architecture.
Repeatable methods.
Documentation that outlives memory.
Teams that can decide without waiting for permission.

Ironically, when you do this well, people may think you are less busy.

That is a good sign.

Busy Work Is Loud. Real Progress Is Often Silent.

Social media does not help.

We see people announcing milestones, launches, and achievements. It creates pressure to always appear active, visible, and moving fast.

But many of the most important decisions I made were invisible.

Choosing not to chase specific markets.
Choosing not to overpromise.
Choosing to say no to partnerships that looked attractive but felt wrong.
Choosing to slow down and fix fundamentals instead of scaling prematurely.

No post went viral for those decisions. No applause followed.

Yet years later, those quiet choices mattered more than many of the loud wins.

I reminded myself often, “Noise fades. Structure stays.”

The Long Game Requires Boredom Tolerance

This may sound strange, but building something that lasts requires the ability to tolerate boredom.

Not excitement. Not adrenaline. Boredom.

Reviewing the same assumptions again and again.
Improving a product by small percentages.
Writing and rewriting until clarity emerges.
Teaching the same concepts repeatedly until others truly get it.

Busy people chase novelty.
Builders chase consistency.

I have rewritten the same ideas across talks, articles, and discussions countless times. Not because I lack new ideas, but because clarity takes repetition.

The world rewards novelty. Reality rewards reliability.

Being Busy Makes You Reactive. Building Makes You Intentional.

When you are busy, your day is shaped by others.

Other people’s requests.
Other people’s timelines.
Other people’s urgency.

When you are building, you reclaim your agency.

You decide what deserves time.
You decide what can wait.
You decide what does not matter, even if it feels urgent.

This is uncomfortable at first.

Saying no feels rude.
Delaying responses feels risky.
Working on things without immediate payoff feels irresponsible.

But over time, you realise something important.

Urgent is not the same as important.
Fast is not the same as far.
Busy is not the same as meaningful.

What Lasts Is Often Unsexy

Let me be honest.

Scalable architecture is not sexy.
Good governance is not trendy.
Testing edge cases is not glamorous.
Writing documentation is not exciting.

But these are the things that survive stress.

When systems scale.
When people leave.
When markets shift.
When crises hit.

Busy work collapses under pressure.
Well built foundations hold.

I have seen projects fail not because the idea was bad, but because the basics were ignored. Everyone was busy. No one was building.

A Simple Test I Use Now

Over time, I developed a simple habit.

At the end of the day, I ask myself one question.

Did I spend today maintaining motion, or strengthening the foundation?

Some days, firefighting is unavoidable. Reality does not disappear because we want to build quietly. But if every day becomes reactive, something is wrong.

Building something that lasts means deliberately carving out time for deep work, even when it feels less urgent than the noise around you.

Patience Is a Strategy, Not a Personality Trait

People often describe patience as a personality trait. I disagree.

Patience is a decision.

It is choosing delayed outcomes over immediate validation.
It is choosing structure over applause.
It is choosing to grow roots before branches.

I was not born patient. I learned patience because the alternative was exhaustion without progress.

I told myself once, “I would rather be underestimated today than irrelevant tomorrow.”

The Quiet Satisfaction of Building

Here is the part people do not talk about enough.

Building something that lasts brings a different kind of satisfaction.

It is quieter.
Deeper.
More personal.

It shows up when someone uses what you built without needing you.
When systems run without drama.
When new people onboard smoothly.
When growth feels earned, not forced.

No fireworks. Just stability.

And in a world obsessed with speed, stability is a rare achievement.

Final Thought

If you are feeling constantly busy but strangely unfulfilled, pause.

Not to quit.
Not to escape.
But to reflect.

Ask yourself whether your effort is compounding or evaporating.

Being busy can fill your days.
Building something that lasts can shape your life.

Both require work.
Only one leaves a legacy.

I would love to hear from you.

Where do you find yourself right now, busy or building?
Share your thoughts in the comments.

The Hidden Weight of Being the One Who Must Decide

There is a weight that comes with being the final decision-maker.

Not the glamorous kind people imagine.
The quiet kind.

Decisions that affect people’s time.
Their income.
Their confidence.

You learn that delay is sometimes a decision. So is saying no. So is choosing not to chase something shiny.

The doodle character stands still here. Hands by the side. No drama. Just responsibility.

This weight never disappears.
You simply learn how to carry it better.

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.