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.