There’s a quiet, almost uncomfortable truth that not many people talk about. At some point in your life, you will get something you once deeply desired… and feel almost nothing or worse, you might even feel like it wasn’t worth it.

I’ve been thinking about this a lot lately, i remember when owning certain things felt like crossing into another level of life entirely. An iPhone wasn’t just a phone, it was status, access, identity. A PlayStation wasn’t just a gaming console, it was escape, excitement, something you imagined yourself enjoying endlessly. A laptop meant independence, capability, maybe even success.

Back then, those things felt distant, almost unreachable. Not necessarily because they didn’t exist, but because they lived in a world that felt separate from mine, a world where money flowed more freely, where choices weren’t limited by practicality and where “wanting” didn’t have to be filtered through “is it necessary?”

Growing up, especially in an environment where practicality is survival, you’re taught to justify everything.

“Does it make calls?” Then a basic phone is enough.

“Can you read and write?” Then a simple device works.

Desire gets reduced to function and slowly, you learn to shrink your wants.

So naturally, when you finally step into a place where those things are accessible, where you can afford them without struggle it should feel like victory, right?

But it doesn’t always, because something changes along the way. The same things that once carried emotional weight now feel… ordinary, replaceable even unnecessary. You buy them, use them and then one day you catch yourself thinking: “Did I really need this?”

And that’s where the confusion begins because now, your desires have evolved.

You’re no longer thinking about phones or gadgets, your mind shifts to bigger things; cars you once only saw in movies, houses that feel like statements, travel that represents freedom.

But there’s a new layer now, not just desire but doubt. A quiet question starts to follow every new ambition:

“What if I get there… and it feels the same?”

What if the Lamborghini becomes the new iPhone?

What if the dream house becomes just another space you exist in?

What if the excitement fades again?

This isn’t fear of failure, it’s something more subtle: fear of emptiness after success and it’s valid.

What you’re experiencing isn’t greed or ingratitude, it’s awareness. You’re starting to realize that the feeling you were chasing was never really inside the object itself, it was in the gap.

The space between where you were and where you wanted to be. The anticipation, the imagination, the sense that life would be different, but once you arrive, the gap disappears and with it, the intensity of the feeling.

So what now?

Do you stop wanting things altogether? Not exactly but you recalibrate.

You begin to understand that external upgrades don’t guarantee internal fulfillment. That owning more doesn’t automatically mean experiencing more and that desire, by its nature, is temporary — it moves.

This is where many people either get trapped in endless chasing… or they start asking better questions.

Not “What do I want next?” but “What actually gives me lasting satisfaction?”

Because there’s a difference between things that excite you… and things that sustain you.

One fades quickly the other compounds over time.

Experiences, growth, relationships, mastery, freedom — these tend to hold their value longer than possessions not because they’re inherently “better” but because they engage more than just your sense of ownership, they involve you and maybe that’s the shift. Maybe the goal isn’t to stop achieving or stop acquiring but to stop expecting those things to carry emotional weight they were never designed to hold.

You can still buy the phone, still drive the car and still live in the house but you stop attaching your sense of meaning to them.

So when you think about those bigger dreams now, the cars, the houses, the travel, the question doesn’t have to be “What if it becomes boring?” because it might. The better question is:

“Who will I be by the time I get there?”

Because that’s the part that doesn’t fade and that’s the part that actually makes the journey worth it.

These statements sound final, almost like a verdict, they shut the door on possibility and quietly suggest that human behavior is fixed, predictable and permanent but what if that’s not entirely true? What if what we often call “human nature” is, in many cases, something far more flexible something learned, practiced, and reinforced over time? 🤔

This perspective doesn’t just challenge a common phrase, it changes how we see ourselves and what we believe we’re capable of becoming.

The Comfort of Calling It “Nature”

Labeling behavior as “natural” is convenient. It helps us make quick sense of people, if someone is consistently kind, we say it’s in their nature, if someone is often impatient or harsh, we say the same thing just with a different tone.

But there’s something deeper happening here, when we call something “nature”, we remove responsibility from the equation, it becomes less about choice and more about identity, less about change and more about acceptance. In some cases, that can be compassionate, in others, it can be limiting.

Because if something is truly “in your nature”, then what room is left for growth?

The Quiet Power of Repetition

Consider this instead; what if many of the traits we describe as “natural” are actually the result of repetition?

Think about how habits are formed, at first, an action requires effort, you have to think about it, you have to choose it, but over time, with enough repetition, it becomes automatic. It feels effortless, eventually, it feels like you.

This is how someone becomes “naturally” patient not because they were born that way, but because they’ve practiced patience enough times that it no longer feels like effort.

The same applies in the opposite direction, a person who reacts with anger, avoidance or defensiveness may not have been born that way either. Those responses may have been learned, adaptations shaped by environment, experience or survival.

What we repeatedly do, we become fluent in and what we become fluent in, others begin to call our nature.

Environment Shapes More Than We Admit

No one develops in isolation. Family dynamics, culture, stress, expectations and early experiences all play a role in shaping behavior.

A child raised in a calm, supportive environment may grow into someone who appears naturally secure and open, another raised in unpredictability may become guarded, hyper-aware or reactive. Over time, these patterns solidify.

But here’s the key insight: these behaviors were not randomly assigned, they were learned responses and learned responses can be unlearned.

When Habit Starts to Feel Like Identity

The longer we repeat a behavior, the more it fuses with our sense of self.

“I’m just not a patient person.”

“I’m bad with people.”

“I’ve always been like this.”

These statements feel true, not because they’re fixed realities, but because they’ve been reinforced over time. The brain prefers efficiency, it builds shortcuts, it turns repeated actions into default settings. At some point, we stop questioning them.

Identity built on repetition is not the same as identity carved in stone.

The Possibility of Change

If behavior were purely “nature”, change would be nearly impossible but we see evidence of transformation everywhere.

People learn to manage anger.

They become more disciplined.

They unlearn fear-based reactions.

They develop empathy, confidence and resilience over time.

None of this happens overnight and none of it happens without effort but it happens, which suggests something important:

what we often call “nature” may simply be well-practiced behavior and practice can be redirected.

A More Honest Way to See Ourselves

Instead of saying, “It’s in my nature”, we might ask:

- What patterns have I repeated long enough that they now feel automatic?

- Where did these patterns come from?

- Are they serving me or limiting me?

- What would happen if I practiced something different?

This shift in thinking doesn’t deny that people have tendencies or predispositions but it refuses to treat them as permanent boundaries. It introduces space, space for awareness, for choice and ultimately for change.

Finally

“It’s in their nature” may sound like an explanation, but often, it’s just a conclusion we’ve stopped questioning.

Human behavior is not only shaped by what we are born with, but also by what we practice, tolerate, repeat and reinforce over time. What feels instinctive today may have once been a learned response yesterday.

And if it was learned, it can be reshaped, not easily, not instantly but deliberately.

So the next time you’re tempted to explain something away as “just human nature”, pause for a moment.

It might not be nature at all, it might just be habit wearing a very convincing disguise.

They were tools you picked up, used to call someone or fire off a quick text and then shoved back into your pocket. They stayed there until you actually needed them again. They didn’t nag, they didn't itch but somewhere along the line, the relationship flipped.

Now, for most of us, the first thing we touch in the morning isn’t a glass of water, a loved one’s hand or even our own thoughts, it’s that glowing rectangle on the nightstand. Before we’ve even rubbed the sleep out of our eyes, we’re scrolling.

Emails, headlines, social medias, the curated lives of people we haven't seen in ten years.

Just like that, the noise of the entire world rushes into our heads before we’ve even had a second to decide what we think about the day.

The weirdest part? none of us really signed up for this. There wasn't some big town hall meeting where we all agreed to give these devices the steering wheel of our lives. It happened in total silence, one "essential" update at a time, one "convenient" app at a time, one dopamine-hitting notification at a time.

And look, I’m not being a hater, I love my phone. It’s a miracle that I have a map, a library, and a movie theater in my pocket. It makes life incredibly easy, but that convenience isn't free.

The "price" is those tiny, empty moments that used to make up a day. Waiting for the bus, sitting in a taxi, or eating a shawarma alone, those gaps used to be filled with daydreaming or just... nothing. Now, "nothing" feels uncomfortable, boredom feels like an emergency that we have to "fix" with a swipe.

We’ve all felt it, we notice the hours vanishing into an infinite feed that by design never actually ends. We tell ourselves we’ll put it away, but these apps are built by people who know exactly how to pull our psychological levers.

The phone didn't barge into our lives like an enemy, it walked in as a helpful assistant and slowly, quietly, moved into the master bedroom.

The point isn't that smartphones are "bad." They’re incredible, but a tool is only useful if you’re the one swinging the hammer.

The real question we should probably ask ourselves today, maybe right after you finish reading this, is a simple one:

Are you still using the phone? or is the phone finally starting to use you?

Let me know your answer in the comment 👇

Red candles, Green candles, Wicks stretching up and down like signals i was supposed to understand. Numbers changing every second. People online talked about support, resistance, breakouts, confirmations, they spoke with certainty, like the market was something you could read if you just knew the language. I didn’t know the language, but i was there anyway.

My finger hovered over the screen longer than it should have because this wasn’t practice, this wasn’t a simulation, this was real money, my money and i was about to make a decision i couldn’t fully justify.

I wish i could say i had a system, a strategy, a clear reason behind that first trade.

Sadly, i didn’t.😞

I was stepping into something i didn’t fully understand, knowing very well that understanding wouldn’t come before action, it would come after.

There’s a certain confidence people project when they talk about trading. Online, everyone seems composed, screenshots of profits, clean charts with perfect entries circled in hindsight, explanations that make every move look obvious after it has already happened.

But when you’re the one staring at a live chart, nothing feels obvious.

You question everything.

Is this the right entry? Am i too early? Am i too late? What if it drops the second i buy? What if i miss the move if i don’t?

No one talks enough about that part. The uncertainty, the hesitation, the quiet realization that you are making decisions without complete certainty.

And maybe that’s the truth no one wants to admit.

Most people don’t know what they’re doing when they start.

They just start.

The strange thing about trading isn’t just the market, its what it reveals about you.

You notice how quickly fear appears, how a small loss feels bigger than it is, how you’re tempted to exit too early just to feel safe, how you hesitate when you should act and act when you should wait.

You begin to realize that the biggest opponent isn’t the market.

It’s your own psychology.

No YouTube video can prepare you for that feeling, no thread or guide can simulate the emotional weight of watching your position move against you or the brief relief when it moves in your favor or the temptation to believe you’ve figured it out after one lucky win Every trade becomes a mirror.

It reflects your patience, your discipline, your impulsiveness, your fear. And sometimes, your lack of control.

There were moments i questioned why I even started, moments where doing nothing would have been easier. Safer.

Because when you don’t act, you can’t be wrong, but you also can’t learn.

There’s a difference between intellectual understanding and experiential understanding. You can read about risk management, you can study patterns, you can watch charts for hours but until you’re involved—until something is at stake, it remains theoretical.

I’ve realized something uncomfortable but freeing, clarity doesn’t come before action, it comes from action.

It comes from placing trades and watching what happens, from being wrong, from observing your own reactions, from slowly recognizing patterns—not just in the market, but in yourself.

You start noticing your tendencies, where you hesitate, where you rush, here emotion overrides logic.

You begin adjusting.

Not because you became an expert overnight but because experience is slowly replacing ignorance.

Not completely.

Just enough to keep going.

I still open the app sometimes and feel unsure.

The charts don’t magically make sense just because time has passed. There’s still uncertainty. Still hesitation. Still moments where I question my decisions.

But something has changed.

I’m no longer waiting to feel ready.

Because readiness was never the requirement.

Action was.

You don’t learn trading by waiting on the sidelines, you don’t build confidence by avoiding uncertainty, you don’t develop understanding by protecting yourself from mistakes.

You learn by participating.

By showing up.

By being willing to be wrong.

There’s a version of me that wanted certainty before starting.

A version that wanted guarantees. Proof. Confidence.

That version would still be waiting.

Still watching.

Still wondering.

Instead, i chose movement over certainty.

Not because i knew what i was doing, but because i didn’t.

And I understood that the only way to change that was to begin.

I don’t know what I’m doing, not completely, but I’m watching, learning, adjusting, continuing and for now, that’s enough.

When Effort Feels Like Pride

Have you ever poured months of your life into a project, only to wonder if it would ever work, only to look back and feel a quiet, almost absurd sense of pride? That was me with my Gantt Calendar project. Weeks turned into months as i struggled to pull it off. There were nights i stared at the code, frustrated that timelines wouldn’t align, or start and end dates wouldn’t display correctly, every bug felt like a personal failure, every error message a reminder that maybe i wasn’t up to the task.

Before i dive into my story, let’s talk about the term that perfectly describes this feeling: the IKEA Effect. Named after the Swedish furniture company known for its flat-pack furniture, the IKEA Effect was coined by behavioral psychologists Michael Norton, Daniel Mochon, and Dan Ariely. They discovered that people consistently value items they assemble themselves more than identical pre-built items. The paradox is simple yet profound: effort inflates value, even when the final product is imperfect. Think of the satisfaction you feel after cooking a complicated meal from scratch, even if it’s not restaurant-perfect and you’ll understand the essence of this cognitive bias.

In my case, the Gantt Calendar project became my “IKEA moment.” Every late night, every bug i fixed, every feature i finally got working; it all added up and when i could finally see the timeline come alive, functional and dynamic, it felt irreplaceable. This wasn’t just another open-source project; it was a monument to my persistence, a reflection of my problem-solving and in a way, a part of me.

Months of struggle had created something i couldn’t help but value deeply. The Gantt Calendar isn’t flawless, there are still features i’d like to refine but it has become one of my proudest open-source creations. Every time someone uses it, or stars it on GitHub, i don’t just see a tool. i see months of my life, sweat and problem-solving poured into something tangible. This is the IKEA Effect: when we create, we don’t just see objects; we see reflections of ourselves.

Building Projects, Building Identity

In professional life, the IKEA Effect often acts as both a blessing and a curse. On one hand, it drives engagement. Employees who help design systems, build processes or create content tend to invest themselves more deeply. That sense of ownership increases motivation, satisfaction and commitment.

But there is a subtle danger. Projects we’ve labored over feel indispensable, even when evidence suggests they are failing. I once worked with a startup where the founder refused to pivot, insisting their product had “potential” despite months of negative feedback. Why? Because they had built it themselves. Every late night, every personal sacrifice, every brainstorming session had become a proof of identity. Walking away felt like betraying not the project, but themselves.

The IKEA Effect often intersects with the sunk cost fallacy. We convince ourselves that effort validates value, rather than allowing the project’s actual quality to speak for itself. This raises a critical question: do we defend our work because it is truly good, or simply because we built it?

Love, Effort and Emotional Attachment

If the IKEA Effect influences work so profoundly, it can be even more insidious in relationships. Emotional labor: the time, patience and effort invested in maintaining a friendship or romance can cloud judgment. The longer we fight for a connection, the more attached we become, regardless of compatibility, health or fulfillment. Effort masquerades as proof of love; struggle is mistaken for depth.

I’ve watched friends stay in toxic relationships simply because they had “invested too much.” Every compromise, every reconciliation, every sacrifice became justification to stay. They told themselves, “I’ve worked too hard to give up now,” forgetting that attachment to effort is not the same as attachment to value. The IKEA Effect can trap the heart as effectively as it traps projects or careers.

Reflect: are you holding onto someone because of who they are or because of the energy you’ve put into them? How often do we confuse perseverance with meaning, struggle with significance or effort with love?

Why Effort Feels Meaningful

Why does this bias exist? Humans are meaning-seeking beings, we crave authorship, competence and agency. Completing a task or building something ourselves signals that we possess these qualities. The attachment created is a form of self-validation and it is deeply satisfying.

Yet the danger lies in mistaking attachment for value. Effort feels meaningful, but meaning is not automatically inherent in the things we labor over. James Clear, in Atomic Habits, writes about how systems; small, repeated actions shape results more than sheer effort or willpower. The IKEA Effect reminds us that emotional investment can distort perception: just because something took effort does not mean it has inherent worth.

Ask yourself: if someone else had created this, would i feel the same attachment? If not, your pride may be a product of effort, not intrinsic value.

Awareness Over Attachment

The IKEA Effect shows us something deeply human: we are drawn to what we shape. Labor creates pride, identity and connection but it does not guarantee value. In work, projects and relationships, attachment to effort can mislead, keeping us tied to things that no longer serve us.

The key is awareness. Pause and reflect: does it matter because of what it is, or because of what i put into it? Understanding the difference is the first step toward freedom, freedom to let go when necessary and freedom to invest where it truly matters.

Effort is beautiful, but it is not the same as meaning and learning to recognize this distinction is one of the most important lessons the IKEA Effect can teach us.

Reflective Questions

• How often do you defend something because of the effort you’ve invested rather than its actual worth?

• When did you last let go of a project, habit or relationship you were “proud” of building and what did you learn?

• How might your life improve if you prioritized inherent value over effort based attachment?

I remember a conversation where I was completely sure I was right. Not just “I think I’m right.”

I mean deeply convinced I had my points ready, my reasoning lined up. In my head, if the other person just listened properly, they would understand me. Simple right ?

Wrong, the conversation didn’t go how I expected.

Instead of feeling heard, both of us walked away frustrated and later, when I replayed the conversations in my head, something uncomfortable hit me, I had spent the entire time trying to be understood but almost no time trying to understand them.

It reminded me of something Stephen Covey wrote in The 7 Habits of Highly Effective People. He calls it Habit 5: “Seek first to understand, then to be understood.” He explains that most people listen with the intent to reply, not to truly hear. When I read that line, I realized he wasn’t just giving advice for managers or leaders, it was a life skill for every human relationship.

There’s a quiet power in that approach. When you focus on understanding others first, conversations stop being battles and start becoming bridges. You start seeing motivations, fears and perspectives you might have ignored before and often, once people feel heard, they naturally start to listen to you in return.

This doesn’t mean ignoring yourself or your needs. Covey’s first habit, Be Proactive reminds us that our values and principles guide our actions. You can still be honest and assertive; you’re just choosing the timing and approach more wisely.

I’ve started noticing it in everyday life. Friends who practice this habit seem to have fewer misunderstandings. Families who focus on understanding each other often have stronger bonds. Even in work or school, taking the time to listen deeply creates trust faster than any argument ever could.

Over time, I’ve started thinking maybe the real goal isn’t choosing between being understood and understanding others, maybe it’s learning when to do each one. Speak up when necessary, but step back and truly listen first. That combined empathy paired with clarity feels like a modern practical application of Covey’s lessons.

Because the best conversations I’ve seen and the most meaningful relationships aren’t built on who talks louder or who proves a point. They’re built on two people trying, even imperfectly, to see each other clearly.

And maybe that’s what most of us are really looking for anyway: to be understood, yes, but also to truly understand.

Share

Viktor Frankl once suggested that meaning is not something we impose on life, but something life asks of us especially in moments we did not choose. When outcomes fail to honor our intentions, the question shifts from “Why did this happen?” to “How will I respond to what has happened?”

A close friend once placed a thought in my head over text. We were exchanging messages, thinking aloud about life, when she asked, “What do you think about intentions, actions, and outcomes?”

I responded easily. All three work together, I said. If the intention is right and the action aligns, the outcome should follow.

She replied without hesitation: “That’s boring. What if the outcome doesn’t always conform to the intention?”

That question stayed with me.

We like to believe life is orderly. That good intentions, when paired with the right actions, naturally produce good outcomes. It gives us a sense of control, a moral balance sheet we can trust. But everyday life quietly contradicts this belief.

A person offers help and is met with resistance.
Someone speaks honestly and is misunderstood.
Another acts without much thought and stumbles into success.

In each case, the outcome tells a story that does not neatly match the intention behind it.

Intentions live inward. They are invisible, known only to the person who holds them. Actions are visible, but incomplete, they are shaped by timing, emotion, context and the limits of perception. Outcomes exist entirely outside us. They are not obligated to reflect what we meant or what we hoped would happen. They respond to reality as it is, not as we imagined it.

Sometimes outcomes even reverse the meaning of an intention. A decision made with care may lead to harm and suddenly the intention is judged harshly. Another decision made casually may produce something good, and the intention is retroactively praised. The same internal motive can be interpreted as wisdom or failure depending solely on how things turn out.

This is where discomfort begins.

If outcomes don’t reliably conform to intentions, then what are we really responsible for? If effort and meaning can be undone by timing, chance, or other people’s reactions, where does accountability begin and end?

Life seems to answer quietly: responsibility is not about control.

Maturity is understanding that intentions guide us, actions express us, but outcomes teach us. They reveal gaps between what we meant and what actually happened. They expose assumptions we didn’t know we were carrying. They remind us that we are participants in a system larger than our plans.

The question my friend asked, “What if the outcome doesn’t always conform to the intention?”, isn’t cynical. It’s honest. It strips away the illusion that life owes us symmetry.

We are not defined solely by what we intended, nor entirely by what happened. Growth happens in the space between where we examine our intentions without defending them, refine our actions without shame and accept outcomes without letting them harden us.

Life is not linear. It doesn’t move from intention to action to outcome in a clean progression. It loops, disrupts, contradicts and reinterprets. And perhaps the real wisdom is not insisting that these three always agree, but learning how to stay grounded when they don’t.

Yes, we grew up on Ps1, Game Boy, Sega, FamilyCom/Family Cup; the original cartridge royalty. We blew into cartridges like certified technicians, slapped consoles when screens flickered and mastered Mario clones with pixelated swagger.

But when the PlayStation 2 arrived?

Everything changed.
Life upgraded. Streets crowned a king.

PS2 didn’t just enter our childhood; it took over.

The PS2 Game Shop: Our Real Childhood Headquarters

Before PS2 came along, our gaming lineup was already legendary:

• Game Boy: The ultimate battery guzzler, home of the Contra warriors.

• Sega: Sonic zooming around like he had a full-time job to get to.

• FamilyCom: 999-in-1 cartridges… but somehow only a dozen actually worked.

But the first time you entered a PS2 shop and saw Winning 11 on a “flat screen” TV (the curved type pretending to be flat)?
Your entire soul whispered:

“My child, welcome to greatness.”

The graphics felt like sorcery.
The vibration pad felt like technology we didn’t deserve.
The ambience? Pure, sweaty childhood heaven.

The game shop was chaotic but it was home.

The Great Escape From School: A Masterclass in Mission Impossible

Every Millennial has this story somewhere in their long-term memory.

One student gets sent out of class for not paying school fees.
And suddenly, the rest of us develop “group sympathy”:

“Guy, you dey go game shop? Wait make i carry my bag.”

Next thing, we’re trekking like soldiers, still in full uniform, straight to our Headquarter (Ps2 Center).

While the rest of the school is calculating algebra, we’re calculating through-passes.

Hours pass.
School closes.
People go home.
We’re still there screaming:

“Last match! abeg this one no count!” (It always counted.)

Winning 11 & PES /2013: The GOATs With No Opposition

Game Boy gave us pocket joy. Sega gave us classics. FamilyCom gave us never-ending cartridges.

But PS2 football games? They gave us culture.

Winning 11 blessed us with:

• Robaldo

• Naldorinho

• Bacyambo

Legends who never existed but lived rent-free in our hearts.

Then PES 2013 arrived and turned every boy into a “manager” shouting instructions at digital players.

Lose 6–0 and the entire shop would roast you:

“Guy, uninstall yourself.”
“You no suppose dey near pad again.”

And the controllers?
Ah!!!

• One pad couldn’t sprint

• One pad couldn’t shoot

• One pad drifted like tokunbo steering

Guess which one the newcomer always got? Exactly!, you guessed right 😂

Mortal Kombat: Friendship-Destroying Since Day One

Nobody knew the combos.
Nobody read the move list.
Yet everybody acted like a world champion.

“Uppercut am!”
“Block!”
“Do fatality!!!”
”Down + Down + Up + Up + Back + Back”……..Bro!😂

We mashed buttons with faith and vibes.

Why PS2 Stands Above Game Boy, Sega, FamilyCom & Everything else

We loved the others, they shaped our childhood but PS2?

PS2 was the crown. The leader. The uncontested ruler.

It united neighborhoods.
It built friendships.
It turned ₦30 into pure, unforgettable joy.

PS2 wasn’t just a console.
It was a lifestyle.

Those Were Truly the Good, Old, Lovely Days

Simple times.
Cheap joy.
No distractions.
Just:

₦30 for 10 minutes.
Two controllers.
Five boys shouting behind you.
A fan blowing hot air.
And a PS2 humming like a generator.

If you lived it, you’ll always feel that warm, peaceful nostalgia in your chest. 💛🎮🔥

A classic example is Bill Gates. People call him lucky for having early access to computers in the 1970s; something rare at the time and yes, that access was luck. But the opportunity came from what he did with it: spending thousands of hours programming, experimenting and preparing long before the industry took off. The luck opened a door; his preparation allowed him to walk through it.

On the opposite side is Brian Acton, who was rejected by both Facebook and Twitter in 2009. Most would call that “bad luck.” But those same rejections pushed him to build WhatsApp; a product later acquired for $19 billion. What looked like misfortune became the path to a much larger opportunity.

Stories like these make something clear: luck creates openings but what happens next is shaped by awareness, preparation and action.

This provides a perspective on how luck and opportunity interact, drawn from patterns that often appear in life and work.

How I Understand Luck

Luck isn’t one thing. It shows up in different forms.

There is the kind of luck nobody controls; the country you were born in, the family you come from, the era you grow up in, or random events that land in your life without warning. Bill Gates is a famous example: one of the few teenagers in that era with access to a computer. That access was luck but it only defined his starting point, not the outcome.

Then there is the luck created through consistent action. Many people labeled Gates “lucky,” but they overlook the part where he spent countless hours learning to program before anyone imagined software would matter. This reflects a broader pattern: people who appear lucky are often the ones who show up repeatedly, build skills, stay visible, and try more things than others. Movement creates more openings for luck to attach itself.

There is also the luck that flows through people. Some of the most significant opportunities come through relationships — someone remembering you, recommending you, opening a door or mentioning your name in the right room. People often call this luck, but it’s usually the result of reputation, consistency and how well you treat others.

What Opportunity Means to Me

Opportunity doesn’t always show up clearly in real life, it often enters quietly. Sometimes it comes as a task that stretches you beyond what you’re used to.
Other times, it’s a role you’ve never done before, a conversation that plants a seed, a problem you suddenly realize you can solve or a project that feels slightly bigger than your current capacity.

It rarely looks glamorous at first, in fact, it often looks inconvenient, uncomfortable, or easy to overlook but when you look back, you realize moments like these were turning points — small doors that led to significant shifts.

I’ve come to understand that opportunity is a mix of awareness and courage. Awareness determines what you notice while courage determines what you are willing to take on.

How Luck and Opportunity Interact

From what i’ve seen, luck and opportunity work together in a very specific way. Luck is the thing that opens the door. Opportunity is what sits behind that door. Preparation is the key you use to unlock it and action is what allows you to actually walk through.

When luck shows up and you’re not prepared, the chance usually slips away. When an opportunity arrives but you hesitate or fail to act, it becomes something you look back on with regret. And when you’re prepared but invisible, your readiness doesn’t get the exposure it needs to attract the opportunities you’re capable of handling.

The people we often call “lucky” are usually the ones who prepared long before any opportunity appeared. They quietly built the skills that later became useful. They made themselves visible enough for others to notice their work. They acted quickly when doors opened. They placed themselves in environments where good things could realistically happen.

Luck amplifies opportunity but both are heavily influenced by preparation. The groundwork you lay long before anything happens determines how much you can take advantage of when luck finally knocks.

Why People Believe Everything Is Luck

I used to wonder why so many people blame luck for success or failure. Over time, i’ve noticed a few patterns.

One reason is that we only see the winners not the countless attempts, failures and late nights behind them. This creates a kind of survivorship bias that makes success look like a random accident.

Another reason is self-protection; Blaming luck is safer than admitting you might need to improve or work harder. It shields people from facing uncomfortable truths about effort and responsibility.

There’s also the hidden work factor; People rarely share their struggles, the small experiments or the moments they failed before succeeding. Without that context, it’s easy to attribute someone’s outcome entirely to luck.

And sometimes, calling success “luck” is simply a way to hide fear—the fear of trying, of starting something new or of failing. By labeling it luck, it feels less risky to stand still.

Ways to Increase Your ‘Luck Surface Area’

While blind luck can’t be controlled, there are ways to influence the kind of luck that really matters. One of the most effective strategies is building skills. Competence naturally attracts opportunities and having the right skills ensures readiness when chances arise.

Visibility also plays a key role, people can only notice and recommend what they see, so sharing your work, ideas and projects helps create openings that might not exist otherwise.

Positioning yourself in the right environments is another important factor. Being part of active communities, engaging in meaningful conversations and staying connected to industries where things are happening increases the likelihood that opportunities will cross your path.

Taking more shots and more attempts also matters. Each attempt increases the chances of success and hesitation often blocks opportunities that could have worked out.

Finally, acting quickly can make a significant difference. Opportunities don’t wait and speed combined with decisiveness can turn a chance into a breakthrough while delay can turn it into a missed moment.

How to Recognize Opportunity

Many opportunities come disguised as discomfort. If a situation challenges you, stretches your abilities or feels slightly beyond your current skillset, it may be worth paying attention. Opportunities often align with long-term growth, pushing you toward the version of yourself you want to become.
In this way, discomfort can be a signal that a meaningful opportunity is present.

Timing: The Often Misunderstood Element

Timing is often mistaken for luck but it plays a distinct role in success. A good idea at the wrong time may achieve nothing. Being unprepared when the timing is right can turn a potential opportunity into a missed chance. Conversely, preparation combined with the right timing can lead to a breakthrough. This highlights why consistent preparation is important even during periods when progress isn’t immediately visible.

Personal Growth as an Opportunity Multiplier

Personal growth plays a key role in creating and recognizing opportunities. As skills, knowledge and judgment improve, the ability to make better decisions also increases. Sound decisions often lead to new opportunities and those opportunities build momentum over time. In this way, the qualities and capabilities you develop directly influence the kinds of chances that are likely to come your way.

Conclusion: How to Approach Luck and Opportunity

Luck will always play a role in life but waiting for it is not an effective strategy. Its impact becomes meaningful only when combined with preparation, awareness, and decisive action.

Movement increases the chances of encountering luck. Awareness allows opportunities to be recognized. Discipline ensures that preparation is consistent. Courage enables action when the moment arrives.

While it’s impossible to control every variable, it is possible to influence the person you are becoming. The skills, mindset and habits you develop shape the kinds of opportunities that will come your way. Luck may present itself but preparation opens the door and action is what allows you to step through.

Leave a comment

In a world obsessed with oversharing, constant updates, and visibility, practicing restraint has become increasingly rare. Yet my personal experiences repeatedly show that certain parts of life are far wiser to protect than to broadcast.

Here are 5 lessons drawn from my own experiences about what not to share casually and why keeping them private can make all the difference.

1. Dreams and Goals

What I learned: Not everyone needs to know where you’re headed.

This lesson did not come from theory; it came from repetition. I noticed a pattern over time: the earlier i shared a dream, the heavier it became. Dreams before they take shape are fragile. They rely on internal belief, quiet consistency and a certain innocence that has not yet been tested by the world. When shared too early, they are exposed to opinions that were never asked for and doubts that were never earned.

Often, people do not intend to harm, their responses are framed as concern or realism but realism, when applied to someone else’s unfinished vision can feel like limitation. Slowly, enthusiasm fades, not because the dream is impossible, but because it has been discussed too much and done too little.

Take for example; you excitedly share a new dream of starting a business, switching careers, or building something unconventional. At first, the reaction feels supportive. Then the questions come: “Have you thought this through?”, “That space is crowded.” “Do you know how many people fail?” What begins as curiosity quietly turns into caution. Over time, you find yourself explaining, defending, and justifying the dream more than actually working on it.

Now, assuming you had kept the dream private, you would have protected your momentum. There would have been no need to convince anyone and no energy wasted seeking approval. Progress would have replaced persuasion. James Clear notes in Atomic Habits that talking about goals can create a psychological reward that tricks the brain into feeling accomplished before meaningful effort begins. In this case, silence becomes a form of discipline.

Work quietly. Let results introduce your dream.

2. Finances

What I learned: Money changes how people see you.

This realization did not come from theory, it came from experience. Over time, I noticed that sharing even a small detail about earnings, savings, or investments often changed how people interacted with me. Casual conversations began to carry undertones of comparison, unspoken expectation, or admiration tinged with envy. The shift was subtle but real, altering the dynamics in ways i had not anticipated.

Take, for example, when you mention how much you earn, save, or invest, friends and colleagues start treating you differently, some expect generosity, others silently judge your spending habits, and a few begin comparing themselves to your achievements. What was once neutral or supportive now carries invisible tension, and you notice that conversations subtly change in tone.

Now, assuming you had kept your finances private, you would have preserved authenticity in your relationships. There would be no pressure to explain decisions or meet expectations, and you could focus entirely on personal growth. As Morgan Housel explains in The Psychology of Money, financial decisions are deeply personal and interpreted through the lens of each person’s experiences and emotions. Privacy creates space for genuine connections and peace of mind.

Let your actions and discipline speak louder than your numbers. Guard your financial life with discretion.

3. Personal Struggles

What I learned: Vulnerability without boundaries is exposure.

This insight came from lived experience rather than theory. Over time, i realized that not all listening ears are safe. Sharing personal struggles can be healing, but indiscriminate disclosure often leads to unintended consequences. Stories meant to elicit support sometimes become gossip, subtle judgment, or doubt in professional or social settings. Courage, i learned is meaningful only when paired with discretion.

Take, for example, when you open up about a difficult period, mental health crises, career uncertainty or personal loss to friends or colleagues. At first, empathy is offered and it feels supportive but later, fragments of your story appear in conversations you were never part of. Your competence or reliability might be quietly questioned and the support you expected feels diluted. Vulnerability, when shared without discernment can quickly turn into exposure.

Now, assuming you had confided only in trusted mentors, professionals, or close friends, you would have found support without compromising safety. Brené Brown emphasizes that vulnerability must be paired with boundaries; otherwise, it ceases to be courageous and becomes risky. Reflective sharing allows for dignity, growth, and healing.

Be open where it’s safe, not where it’s convenient. Guard your story as you would your trust.

4. Your Next Big Move

What I learned: Announcing plans invites interference.

This lesson came from repeated experience. Over time, i observed that revealing your next step too early changes the energy around it. Friends, colleagues, and even well-meaning advisors begin to weigh in, often projecting their own fears, doubts, or timelines onto your decisions. The excitement of planning slowly transforms into the burden of explanation and justification.

Take for instance, when you announce plans to resign, relocate, or launch a new venture. At first, reactions seem supportive, but soon, advice floods in, cautionary stories are shared, and doubts are subtly introduced. Some rush you to make a decision, others unintentionally discourage you. What was once a personal journey becomes a collective discussion, diluting focus and clarity.

Now, assuming you had kept your plans private, you would have retained focus, flexibility, and clarity of thought. You could execute without the weight of unsolicited advice or the noise of expectation. As Robert Greene points out in The 48 Laws of Power, concealing intentions until execution preserves strategic advantage and protects autonomy. Silence in planning is not secrecy, it is a form of discipline.

Move in silence. Let your actions make the announcements and define your progress.

5. Your Inner Circle

What I learned: Privacy protects relationships.

This insight came from observing patterns over time. Revealing who is in your inner circle, mentors, advisors, or close confidants alters the dynamics around you. Once others know who influences your decisions, they may attempt to bypass you, sway those people directly or make assumptions about your choices. Relationships that were once natural and fluid can become complicated.

Take, for example, when you frequently mention mentors or close advisors in conversations, hoping to share insight or acknowledge guidance. Over time, those individuals may start receiving unsolicited opinions, requests, or pressures from others, subtly changing their behavior and the advice they give. Your relationships become entangled with external expectations and the trust that once existed is quietly compromised.

Now, assuming you had kept your inner circle private, you would have preserved trust, autonomy and clarity in all relationships. The guidance and influence of these key people would remain pure and undistorted. Often, power lies not in who you know, but in who others don’t know you know. Discretion ensures that those who protect and challenge you continue to do so without interference.

Guard the names of those who guard you. Protect your inner circle, and in doing so, protect yourself.

Final Thoughts

Silence is not secrecy, it is strategy.

Discretion allows dreams to mature, finances to compound, struggles to heal, plans to crystallize, and relationships to remain uncorrupted. In an age that rewards constant disclosure, restraint becomes a quiet advantage.

You do not owe everyone access to your inner world.

Sometimes, the most powerful statement you can make is simply to let your life speak for itself.

My mom called early and asked if I could take her to the market so she could restock her provision store. I agreed. Nothing dramatic. Just another day of errands and responsibility.

When i arrived, her shop was already busy. Customers clustered around her, calling out prices, asking questions, making purchases all at once. Instead of joining the chaos, I decided to sit back in the car and observe, watching how she calmly handled everyone with the patience only market women seem to have mastered.

That was when I noticed him.

One guy stood out. Not because he was loud or rude but because he was too careful. He kept looking over his shoulder, scanning the environment, checking who was watching. Suspicion has a way of announcing itself quietly.

At some point, he turned toward where I was parked. I quickly pretended to be distracted, looking elsewhere. Seconds later, I saw it clearly: his hand slipped into a jar filled with boiled eggs. He picked one. Smoothly. Practiced. Then dropped it into his pocket.

That was it.

Like a soldier responding to instinct; boom!! I jumped out of the car.

I walked straight to my mom, handed her my phone and wallet, and whispered to her in Igbo, quietly but firmly: “E jidere m onye oshi.” which translates to“I’ve caught a thief.”

She looked at me, confused. Like, what are you talking about?

I didn’t wait to explain.

I walked straight up to the guy. By then, I think he already knew the game was up. He smiled nervously and said,
“Senior man, I dai greet ooo.”

Senior man?
Who is your senior man?

I grabbed his wrist, not violently, just enough to let him know this wasn’t a conversation and said,
“Bring it out.”

Slowly, gently, he brought the egg out of his pocket.

At that moment, I saw real fear in his eyes. The kind that says, “Is this how I die today?”
He probably thought I’d raise an alarm. That people would gather. That things could spiral quickly, because we all know how ugly those situations can get.

But that’s not who I am.

I didn’t shout. I didn’t hit him. I just told him to leave.

My mom, however, did what mothers do best, she scolded him, not with anger, but disappointment. And that was when I realized something else: the guy hadn’t even come to buy anything, he came asking for water to drink.

Of course, I said, “Don’t give him water again. Let him just go.”

But my mom being my mom said,
“Give him the water.”

And I had no choice but to give it to him.

Here’s the truth: I felt for the young guy. I really did. Life is hard. Hunger is real. Struggle is loud. But stealing is not an option.

The same strength you use to steal an egg is the strength you can use to beg for food. The same courage it takes to slip your hand into someone else’s jar is the courage it takes to ask for help.

This morning reminded me of how thin the line is between desperation and bad decisions and how important it is to respond with firmness and humanity.

Anyway, I just thought I’d share.

Life lessons don’t always come from big events. Sometimes, they come wrapped in something as small as a boiled egg.

I wore many hats—backend engineer, mobile app developer, teammate, friend, traveler and each role came with lessons worth carrying into the future. As 2026 opens its doors, this is both a recap of a remarkable journey and a declaration of intent for the road ahead.

Building, Shipping, and Growing as an Engineer

2025 was deeply rooted in work. Writing backend logic, optimizing APIs, debugging mobile flows, and shipping features that real people used daily. There’s something grounding about solving problems that don’t exist until you show up to fix them.

Engineering taught me discipline again this year, not the motivational kind, but the quiet consistency of showing up even when the solution isn’t obvious. Some days were smooth deployments; others were long nights chasing bugs that refused to announce themselves.

But growth happened.

Not just in technical depth, but in how I think:

• Designing systems with scalability in mind

• Writing code that future me (and teammates) would thank me for

• Understanding that clarity beats cleverness every single time

Ain’t No Party Like a Lagos Party

Then came Lagos and with it, a reminder that no city does celebration quite like this one.

The End-of-Year (EOY) party was proof that life is not just about commits, pull requests, and sprint deadlines. It’s also about moments unexpected, loud, colorful moments that stay with you long after the music fades.

The energy shifted the moment the party came alive. Shoday took the stage and did what he does best, turning sound into atmosphere. The kind of performance that pulls people out of their seats without asking for permission. Then Yheemo Lee (aka King of night life. YL) showed up, adding even more spice to the night. Familiar faces, popular energy, and that unmistakable Lagos buzz where everyone feels like something memorable is about to happen.

People danced. Phones came out. Laughter grew louder. For a few hours, nobody cared about tomorrow’s tasks or unfinished tickets. Work titles disappeared, replaced by vibes, movement, and shared excitement.

In that space, it became clear: balance matters. You can build serious things and still enjoy loud nights. You can be disciplined and still let loose. Lagos didn’t just host a party, it delivered a reminder that life deserves celebration too.

Bowling Champion Energy 🎳

I didn’t just play bowling, I showed up with intent.

Four straight all-clear hits. One frame after another. No warm-up excuses. No second chances. Just a steady grip, controlled breath, clean release, and the sound every bowler waits for, the pins collapsing in agreement.

With each strike, the noise around me faded. Cheers blended with disbelief. Focus took over. It wasn’t about showing off; it was about trusting muscle memory and staying calm under pressure. The lane demanded patience, not force and it rewarded precision.

Becoming the champion wasn’t just fun; it was symbolic. It reinforced a quiet truth: confidence isn’t always loud. Sometimes, it’s simply committing fully to the moment and trusting your shot, even when people are watching.

That night, bowling wasn’t just a game. It was a reminder that when preparation meets belief, results tend to follow.

Kilishi, Pepper, and Brotherhood

Then there was the kilishi.

Hot. Pepperish. Absolutely unforgiving.

The kind of pepper that doesn’t warn you, it just shows up and makes a statement. Eyes watered. Faces tightened. Pride was challenged. But nobody backed down. We laughed through the heat, wiping tears we pretended were from “too much laughter,” bonding over a shared battle with spice.

That moment did more than entertain us. It reminded me that joy often lives in the simplest places, good food, familiar faces, and the freedom to laugh at discomfort instead of fighting it. There’s something powerful about shared struggle, even when it’s just pepper trying to humble everyone equally.

No fancy setup. No grand plans. Just friends, kilishi, and the kind of laughter that only happens when everyone is equally uncomfortable and equally happy.

Suspect & Mafia (aka Police & Thief): Mind Games Activated

Then came Suspect and Mafia games that look harmless on the surface but have a way of pulling the deepest parts of people to the front.

This wasn’t just play. There was ₦500,000 on the line, and suddenly everyone’s tone changed.

Laughter softened. Eyes sharpened. Trust became currency and betrayal a valid strategy.

These games thrive on strategy, deception, and observation. You quickly learn that confidence can be a disguise, silence can be guilt, and the loudest voice in the room is not always the most truthful. Allies can turn on you without hesitation, not out of malice, but because incentives realign priorities.

What fascinated me most was how easily people could be deceived or how convincingly they could deceive. Someone you trusted five minutes ago could calmly vote you out, look you in the eye, and justify it with logic that almost made sense. In that moment, you realize how fragile assumptions are.

Winning the second round with two teammates wasn’t luck. It was restraint.

Listening more than speaking. Watching body language. Not reacting too fast. Knowing when to blend in and when to step forward. The game rewarded awareness over noise, patience over impulse.

And just like real life, those who survived longest weren’t always the strongest or smartest but the ones who understood people.

Funny how a simple game can mirror reality so closely: incentives change behavior, pressure reveals character, and trust once broken is almost impossible to rebuild.

Boat Cruise, Barbecue Fish, and Letting Go

The boat cruise was the exhale I didn’t know I needed.

One hand held a drink, the other reached for perfectly grilled barbecue fish, peppery, smoky, and worth every bite. The water moved steadily beneath us, doing its own thing, unbothered by deadlines or deliverables. Music floated through the air, not too loud, not too serious, just enough to keep the mood light.

Conversations flowed without agendas. No one was rushing to “be productive.” No one was checking what time it was. Laughter came easily. Stories stretched longer than planned. For once, nobody was trying to optimize anything.

And in that moment, productivity took a back seat and rightly so.

Because rest isn’t a reward for burnout. It’s part of the system. Sometimes, the most valuable thing you can do is stop pushing, lean back, and let life move for you just like the water beneath that boat.

2026: The Year of Intentional Expansion

A new chapter doesn’t begin by accident. It begins with clarity.

Reading for Personal Growth: Consistency Over Restart

This isn’t my first time committing to reading. I’ve started before. What makes this year different is not motivation—it’s intention.

In 2026, reading is not about chasing numbers or stacking completed book lists. It’s about consistency and application. Books have always been powerful, they sharpen perspective, stretch thinking, and compress decades of lived experience into a few hundred pages. But knowledge only compounds when it’s used.

This time, the focus is simple:

• Read steadily, not sporadically

• Pause often to reflect, not rush to finish

• Apply ideas directly to work, relationships, finances, and personal discipline

A chapter that changes how I think is worth more than ten books I barely remember.

Reading becomes real when a lesson influences a decision at work, improves how I communicate with people, or reshapes how I plan my future. That is the standard this year not consumption, but transformation.

Writing to Think Better

Writing forces honesty. It exposes gaps in thinking and strengthens communication. In 2026, I plan to write more publicly and privately, not for perfection, but for clarity and growth.

Learning AI Skills for the Future

AI is no longer “emerging”, it’s here. This year is about practical understanding:

• How AI systems work

• How to build with them

• How to stay relevant in a rapidly shifting tech landscape

Learning is no longer about curiosity alone; it’s about leverage.

Enlarging the Pocket (Finance Matters): Turning Effort into Leverage

Let’s be honest, financial growth matters. Passion is great, purpose is important, but bills do not accept motivation as payment.

2026 is not about reckless chasing or “get-rich-quick” fantasies. It’s about intentional financial expansion—being smarter, more strategic, and more deliberate with money than I’ve ever been before.

This year, enlarging the pocket means:

Increasing Income Streams

Not just working harder, but working wider and smarter.

Turning my technical skills into assets that generate value beyond a single paycheck—side projects, consulting, products, or opportunities that scale with effort rather than time. The goal is to ensure income doesn’t stop when the laptop closes.

Making Smarter Financial Decisions

Money should be managed, not guessed.

This means understanding where it goes, why it goes there, and whether it’s working as hard as I am. Spending becomes intentional. Saving becomes strategic. Investments become informed rather than emotional.

Every financial decision is a vote for the kind of future I want.

Turning Skills into Value and Value into Freedom

Skills are useless if they stay on paper.

In 2026, skills must translate into outcomes, solutions people are willing to pay for. When skills create value, money follows. And when money follows consistently, freedom appears.

Freedom to choose projects.
Freedom to walk away from bad deals.
Freedom to invest time where it truly matters.

Money is not the goal.
Money is the tool.

Freedom is the destination.

Final Thoughts: Carry the Lessons Forward

2025 reminded me that growth doesn’t happen in isolation. It happens in workrooms, bowling alleys, game circles, noisy parties, quiet reflections, and moments of laughter that catch you off guard.

2026 is not a blank page, it’s a continuation. But this time, with sharper focus, clearer goals, and a deeper appreciation for both the grind and the joy.

Here’s to building better, living fuller, and growing deliberately.

Welcome to 2026.

Since then, I’ve refined the approach. I’ve found a cleaner, safer, and more maintainable way to decode API strings into enums without giving up enums entirely, and without risking crashes in production.

The Real Problem With API → Enum Decoding in Flutter

Backend APIs evolve.

Today you might get:

{ “name”: “wallet_funding_fee” }

Tomorrow the backend might add:

{ “name”: “wallet_penalty_fee” }

If your Flutter code uses strict enum decoding, something like:

enum Fees {
  walletFundingFee,
  walletPenaltyFee, // not added yet
}

Then an unexpected API value instantly breaks your app:

• JSON parsing crashes

• Freezed throws errors

• Your users see a blank screen

This is why relying on strict enum matching for backend strings is dangerous.

So in my first article, I recommended avoiding direct enum decoding altogether.

I still stand by the warning, strict enum decoding is a trap.

But now there’s a better way.

The Better Way: Safe Enum Decoding With a Custom JsonConverter

Instead of decoding directly into an enum which forces strict matching
you create a custom JsonConverter that:

1. Checks for a matching enum value

2. Returns null if no match is found

3. Never crashes

4. Still lets you use your enum cleanly everywhere else

5. Works perfectly with Freezed

This gives you the best of both worlds:

• Type safety when values match

• Runtime safety when unknown values appear

• Future-proofing when backend developers add new fields

Here’s how it works.

1. The Enum With Value Mappings

You keep your enum exactly as you like; readable, structured, and tied to string keys:

import ‘package:json_annotation/json_annotation.dart’;

part ‘fees.g.dart’;

@JsonEnum(valueField: ‘value’, fieldRename: FieldRename.kebab)
enum Fees {
  tier1DailyTransactionLimit(’tier1_daily_transaction_limit’),
  tier2DailyTransactionLimit(’tier2_daily_transaction_limit’),
  tier3DailyTransactionLimit(’tier3_daily_transaction_limit’),
  currentDollarRate(’current_dollar_rate’),
  walletFundingFee(’wallet_funding_fee’),
  externalTransferfee(’external_transfer_fee’),
  // ... and the rest

  final String value;
  const Fees(this.value);
}

Nothing special here — just a clean enum mapping each item to an API string.

2. The Safe JsonConverter (The Star of This Article)

This is the improved technique that replaces strict enum decoding.

import ‘package:freezed_annotation/freezed_annotation.dart’;
import ‘../ui/features/admin/domain/enum/fees.dart’;

/// Safely converts between `Fees` enum and JSON string.
class FeesSerializer implements JsonConverter<Fees?, String?> {
  const FeesSerializer();

  /// Converts JSON string to `Fees` enum.
  /// Returns null if the string is null or unknown.
  @override
  Fees? fromJson(String? json) {
    if (json == null) return null;

    final match = Fees.values.where((e) => e.value == json);
    return match.isNotEmpty ? match.first : null;
  }

  /// Converts `Fees` enum to JSON string.
  @override
  String? toJson(Fees? object) => object?.value;
}

Why this works

• null is returned for unknown values (safe)

• No crash

• Works with any backend change

• Can be logged, observed, or ignored depending on your requirements

• Keeps your enum untouched

This alone eliminates 99% of enum-related backend crash scenarios.

3. Using the Converter in a Freezed Model

Now you simply attach the converter to the field:

import ‘package:freezed_annotation/freezed_annotation.dart’;
import ‘../app/serializer/fees_serializer.dart’;
import ‘../../enum/fees.dart’;

part ‘envs.freezed.dart’;
part ‘envs.g.dart’;

@freezed
class Envs with _$Envs {
  factory Envs({
    @FeesSerializer() Fees? name,
    @JsonKey(name: ‘updated_at’) DateTime? updatedAt,
    String? value,
  }) = _Envs;

  factory Envs.fromJson(Map<String, dynamic> json) => _$EnvsFromJson(json);
}

Now when the API sends a new or unknown string:

{ “name”: “unknown_fee_type” }

You simply get:

name = null;

No crash.
No fallback enum you don’t want.
No need to avoid enums.
Just clean, safe decoding.

Why This Approach Is Better Than Avoiding Enums Entirely

In my earlier article, I leaned toward avoiding enums for direct API decoding because of the runtime crash risk.

But with this improved approach:

You can safely use enums without the risk.

This method gives you:

1. Strong typing

2. Zero runtime failures

3. Future-proofing

4. Cleaner code

5. Better Freezed support

6. No need for unsafe “unknown enums” fallbacks

It’s simply a better version of the original idea.

A Quick Before → After Comparison

Before (strict decoding — risky)

• Decodes directly into enum

• Crashes on unknown value

• Backend changes break the app

• Forced to avoid enums entirely

After (safe decoding — recommended)

• Decodes through JsonConverter

• Unknown value becomes null

• No crash

• Backend changes do not break the app

• Enums remain clean, readable, maintainable

Wrapping Up

This article isn’t a reversal of my previous stance, it’s an upgrade.

The danger with strict enum decoding is still real.
But now, we’re using a pattern that gives you the safety you need and the type safety you want.

This approach has been battle tested in production, integrates perfectly with Freezed, and scales well when backend teams update or expand API fields.

If you’ve been avoiding enums for API responses in Flutter, you no longer have to.

If you’re building APIs, mobile apps, or distributed systems, you know that network failures are inevitable. Requests can fail due to:

• Temporary server downtime

• Network timeouts

• Load balancer hiccups

• Temporary service outages

Without a proper retry strategy, these failures can break user experience, overload servers, and create duplicate actions.

This guide will show you how to implement retry logic with exponential backoff, and why it must be combined with idempotency to make your APIs safe and reliable.

What Is Retry Logic?

Retry logic is a strategy where a failed request is automatically retried.

• Basic retry: Repeat the request a fixed number of times.

• Advanced retry: Add delays and exponential backoff to avoid overwhelming the server.

Why it matters:
Without retry logic, temporary errors become permanent failures for your users.

Example in JavaScript:

for (let attempt = 1; attempt <= 3; attempt++) {
  try {
    await sendRequest();
    break; // success
  } catch (error) {
    console.log(`Attempt ${attempt} failed. Retrying...`);
  }
}

Problem: Immediate retries can overload your servers if many clients fail simultaneously.

Share Jay is Coding

What Is Exponential Backoff?

Exponential backoff is a technique where the delay between retries increases exponentially:

• Retry 1 → wait 1 second

• Retry 2 → wait 2 seconds

• Retry 3 → wait 4 seconds

• Retry 4 → wait 8 seconds

Example in JavaScript:

for (let attempt = 1; attempt <= 5; attempt++) {
  try {
    await sendRequest();
    break; // success
  } catch (error) {
    const delay = Math.pow(2, attempt);
    console.log(`Attempt ${attempt} failed. Retrying in ${delay}s...`);
    await new Promise(res => setTimeout(res, delay * 1000));
  }
}

Benefits of Exponential Backoff:

• Reduces server load

• Gives transient errors time to resolve

• Prevents retry storms in distributed systems

Why Idempotency Is Crucial With Retry Logic

Retry logic alone is not enough if the request modifies data (like payments, orders, or messages).

Idempotency ensures that repeated requests:

• Do not create duplicates

• Return the same response every time

• Keep your system predictable and safe

This flow ensures retries are safe and predictable.

Best Practices for Retry Logic & Exponential Backoff

• Retry only transient errors (timeouts, 500-series errors)

• Do not retry client errors (400-series)

• Combine retries with idempotency keys for safe repeated requests

• Cap the maximum number of retries to prevent infinite loops

• Introduce jitter to avoid multiple clients retrying at the same time

Example of jitter:

const jitter = Math.random(); // 0-1 second
await new Promise(res => setTimeout(res, (delay + jitter) * 1000));

• Log retries to monitor performance and diagnose issues

Real World Examples

• Stripe Payments: Uses retries + idempotency to prevent double charges

• AWS SDKs: Automatically retry failed API calls with exponential backoff

• Kafka / RabbitMQ Consumers: Retry message processing safely without creating duplicates

Conclusion: Building Resilient APIs with Retry Logic and Exponential Backoff

Implementing retry logic with exponential backoff is essential for any modern API or distributed system. Combined with idempotency, it ensures that:

• Your systems handle network failures gracefully

• Duplicate operations are prevented automatically

• Servers are protected from overload caused by repeated retries

• Users experience reliable and predictable behavior

By following best practices, retrying only transient errors, introducing jitter, capping retries, and using idempotency keys—you can build fault-tolerant, production-ready systems that scale safely.

Key takeaway: Retry logic + exponential backoff + idempotency is not just a technical detail, it’s a superpower for API reliability. Mastering these patterns will make your services robust, user-friendly, and resilient, even under network stress or temporary failures.

I’ve never really loved heaps, to be honest.
They’ve always felt a bit too abstract like one of those data structures you study, nod at, and move on from.

But the truth? Heaps are kind of a big deal.
So I decided to stop just reading about them and actually build one in Flutter. A simple visual app that turns all that theory into something you can see and interact with.

What started as a weekend “let’s-see-what-happens” project ended up being one of the most fun ways I’ve learned algorithms in a long time.

My goal?
To show how something as “computer-sciencey” as a heap can power real, interactive digital experiences.

What’s a Heap Anyway?

A Heap is a tree-based data structure that lets you quickly find the smallest or largest element in a collection.

Think of it like:

• A Min-Heap = “Get me the smallest thing, fast.”

• A Max-Heap = “Keep the biggest thing on top.”

It’s efficient, predictable, and used everywhere from priority queues to leaderboards, pathfinding algorithms, and task scheduling.

The Core Idea (in Pseudocode)

Here’s how it works conceptually 👇

// Represent the heap as a list
heap = []

parent(i) = (i - 1) / 2
left(i)   = 2 * i + 1
right(i)  = 2 * i + 2

// Insert a value
function insert(value):
    add value to heap
    bubbleUp(lastIndex)

// Extract the smallest value
function extractMin():
    swap root with last item
    remove last item
    bubbleDown(0)
    return removedValue

// Maintain the min-heap property
function bubbleUp(index):
    while index > 0 and heap[index] < heap[parent(index)]:
        swap(heap[index], heap[parent(index)])
        index = parent(index)

function bubbleDown(index):
    while index has smaller child:
        swap with smaller child
        move down

TL;DR:

• Insert = add to end → bubble up

• Extract = remove root → bubble down

  ---

How insertion works

When you insert a new value:

1. Add it to the end of the list.

2. Bubble up (swap it upward) until the heap property is restored.

Example (Min Heap):

Insert 5 → [10, 15, 30, 40, 50, 5]
Bubble up → compare 5 with parent 30 → swap
→ [10, 15, 5, 40, 50, 30]
Bubble up again → compare 5 with parent 10 → swap
→ [5, 15, 10, 40, 50, 30]
Done.

How extraction works

When you extract the top element (min or max):

1. Remove the root.

2. Move the last element to the top.

3. Bubble down (swap downward) until the heap property is restored.

Example (Min Heap):

Heap = [5, 15, 10, 40, 50, 30]
Extract min (5)
Move last element (30) to top → [30, 15, 10, 40, 50]
Bubble down:
- Compare 30 with children (15, 10)
- Swap with smallest (10)
→ [10, 15, 30, 40, 50]
Done.

Building It in Flutter

For the demo, I built a tiny Flutter app, Heap Visualizer.
It’s simple:

• Input field to add numbers

• “Insert” and “Extract Min” buttons

• A visual list that updates as the heap changes

Each operation updates the heap array and re-renders the layout so you can see how elements bubble up or down.

Real-World Use Cases

• Priority queues (task schedulers)

• Leaderboards (max-heap)

• Dijkstra’s algorithm (min-heap)

• Job scheduling systems

• Memory management

The Flutter Implementation

Here’s the simplified code I used inside my Flutter app:

Project Structure

📁 heap_visualizer/
 ┣ 📂 lib/
 ┃ ┣ main.dart
 ┃ ┣ heap.dart          ← heap logic (custom class)
 ┣ 📸 assets/heap_diagram.png
 ┣ 📜 README.md

heap.dart

class Heap {
  final List<int> _heap = [];
  final bool isMinHeap;

  Heap({this.isMinHeap = true});

  void insert(int value) {
    _heap.add(value);
    _bubbleUp(_heap.length - 1);
  }

  int? extract() {
    if (_heap.isEmpty) return null;
    final root = _heap.first;
    _heap[0] = _heap.removeLast();
    if (_heap.isNotEmpty) _bubbleDown(0);
    return root;
  }

  void _bubbleUp(int index) {
    while (index > 0) {
      final parent = (index - 1) ~/ 2;
      if (_compare(_heap[index], _heap[parent])) {
        _swap(index, parent);
        index = parent;
      } else {
        break;
      }
    }
  }

  void _bubbleDown(int index) {
    final size = _heap.length;

    while (true) {
      final left = 2 * index + 1;
      final right = 2 * index + 2;
      var target = index;

      if (left < size && _compare(_heap[left], _heap[target])) target = left;
      if (right < size && _compare(_heap[right], _heap[target])) target = right;

      if (target != index) {
        _swap(index, target);
        index = target;
      } else {
        break;
      }
    }
  }

  bool _compare(int a, int b) => isMinHeap ? a < b : a > b;

  void _swap(int i, int j) {
    final temp = _heap[i];
    _heap[i] = _heap[j];
    _heap[j] = temp;
  }

  List<int> get values => List.unmodifiable(_heap);
}

main.dart

import ‘package:flutter/material.dart’;
import ‘heap.dart’;

void main() => runApp(const HeapApp());

class HeapApp extends StatefulWidget {
  const HeapApp({super.key});

  @override
  State<HeapApp> createState() => _HeapAppState();
}

class _HeapAppState extends State<HeapApp> {
  late Heap heap;
  bool isMinHeap = true;
  final controller = TextEditingController();

  @override
  void initState() {
    super.initState();
    heap = Heap(isMinHeap: true);
  }

  void _toggleHeapMode(bool value) {
    setState(() {
      isMinHeap = value;
      heap = Heap(isMinHeap: isMinHeap);
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: “Heap Visualizer”,
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        appBar: AppBar(
          title: const Text(”Heap Visualizer”),
          centerTitle: true,
          backgroundColor: Colors.blueAccent,
        ),
        body: Padding(
          padding: const EdgeInsets.all(16),
          child: Column(
            children: [
              // Toggle switch for heap type
              Row(
                mainAxisAlignment: MainAxisAlignment.center,
                children: [
                  const Text(”Min Heap”),
                  Switch(
                    value: !isMinHeap,
                    onChanged: (value) => _toggleHeapMode(!value),
                    activeColor: Colors.deepOrange,
                  ),
                  const Text(”Max Heap”),
                ],
              ),

              const SizedBox(height: 16),

              // Input field
              TextField(
                controller: controller,
                keyboardType: TextInputType.number,
                decoration: const InputDecoration(
                  labelText: “Enter a number”,
                  border: OutlineInputBorder(),
                ),
              ),

              const SizedBox(height: 12),

              // Action buttons
              Row(
                mainAxisAlignment: MainAxisAlignment.spaceEvenly,
                children: [
                  ElevatedButton.icon(
                    onPressed: () {
                      final val = int.tryParse(controller.text);
                      if (val != null) {
                        setState(() => heap.insert(val));
                        controller.clear();
                      }
                    },
                    icon: const Icon(Icons.add),
                    label: const Text(”Insert”),
                  ),
                  ElevatedButton.icon(
                    onPressed: () {
                      setState(() => heap.extract());
                    },
                    icon: const Icon(Icons.remove_circle_outline),
                    label: Text(isMinHeap ? “Extract Min” : “Extract Max”),
                  ),
                ],
              ),

              const SizedBox(height: 24),

              // Heap visualization
              Expanded(
                child: heap.values.isEmpty
                    ? const Center(
                        child: Text(
                          “Heap is empty”,
                          style: TextStyle(color: Colors.grey),
                        ),
                      )
                    : ListView.builder(
                        itemCount: heap.values.length,
                        itemBuilder: (context, index) {
                          final value = heap.values[index];
                          return Card(
                            color: Colors.blue.shade50,
                            elevation: 2,
                            margin: const EdgeInsets.symmetric(vertical: 4),
                            child: ListTile(
                              leading: CircleAvatar(
                                backgroundColor: Colors.blueAccent,
                                child: Text(
                                  “${index + 1}”,
                                  style: const TextStyle(color: Colors.white),
                                ),
                              ),
                              title: Center(
                                child: Text(
                                  value.toString(),
                                  style: const TextStyle(
                                    fontSize: 20,
                                    fontWeight: FontWeight.bold,
                                  ),
                                ),
                              ),
                            ),
                          );
                        },
                      ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

Wrapping It Up

Building a heap from scratch reminded me why I love (and sometimes avoid) data structures, they make you slow down and think.
Every insert, every bubble-up, every re-balance is a little reminder that beautiful things in tech often come from simple rules done right.

Using Flutter to visualize it made the process even more fun, suddenly, something abstract had motion, structure, and a UI.
It wasn’t just code anymore; it was a living, learning experiment on my screen.

If you’d like to check out the full code or try the demo yourself, it’s all here
👉 GitHub Repo: https://github.com/JycTheDev/flutter-heap-demo

“So my friend calls and says, ‘Bro, there’s this salon that needs an app… ASAP.’ And that’s how it all started.” 😂

If you’ve ever been the “tech friend,” you already know what ASAP really means.
I asked, “When’s the deadline?”
He said, “End of the week.”

That was Tuesday.

I laughed, stared at my laptop, and said, “Send the brief.”
Four days later, a full salon sales-tracking app was live, built with Flutter, Firebase, and a lot of late-night coffee.

The Challenge

The app was for a beauty salon that wanted to track daily sales by staff members, things like:

• Hair styling 💇🏾‍♀️

• Manicure & pedicure treatments 💅🏽

• Product sales 🧴

• etc

Each staff needed to record their daily services, while the admin could:

• View all entries in real-time (from web or mobile)

• Track total revenue per staff

• Rank staff performance

• Calculate bonuses based on achievements

Basically, the salon wanted a mini business intelligence system but fast.

The Stack That Made It Possible

To pull this off in 4 days, I needed tools that worked as hard as I did:

• Flutter – for cross-platform speed and beautiful UI.

• Firebase Firestore – for real-time syncing of staff entries.

• Firebase Auth – for secure logins (staff vs admin).

• Firebase Hosting – for the web dashboard.

• Riverpod – my go-to for clean state management.

• AutoRoute – to handle navigation without losing my mind.

Firebase basically became my backend, database, and therapist.

The 4-Day Sprint

Day 1 — The Blueprint

I spent the first few hours clarifying the flow with my friend (and indirectly, the client).
Quick wireframes. Data structure plan. Firebase setup.

By evening, I had login and registration screens ready; not pretty, but functional.

Day 2 — Data, Data, Data

I built the Firestore collections for staff, services, and daily entries.
Each record included service type, amount, and timestamp.

By nightfall, staff could log in and record sales.
I slept at 2:00 AM feeling like a mini-hero.

Day 3 — Admin Dashboard & Panic Moments

This was the heavy-lifting day.
I built the admin panel, where salon managers could view:

• Each staff’s daily summary

• Total performance

• Top-ranking staff (bonus-worthy 🎉)

At 11 PM, a Firestore query broke the entire stats screen.
After one hour of debugging, it turned out to be a typo in a field name. (Developers, you feel my pain.)

Day 4 — UI Polish, Testing & Demo

By now, the app actually looked good.
Flutter’s ListView animations and custom widgets gave it that professional touch.

I cleaned up the design, pushed the web dashboard to Firebase Hosting, and packaged the mobile build.
My friend tested it with the client that night and it worked flawlessly.

4 days. One stack. Two tired humans. One happy client.

The Wins

• Built a fully functional multi-user system in 4 days.

• Reused most Firebase logic between mobile and web.

• Learned how to prioritize what truly matters in an MVP.

• Discovered that good UI + real-time feedback = instant client trust.

Lessons I’ll Keep

1. Say yes carefully, but when you do, commit fully.

2. Flutter and Firebase are perfect for rapid prototyping (and real-world apps, too).

3. Sleep is optional. Debugging commas isn’t.

4. Working under pressure makes you creative. (although i still advice you you get in such position..😂😂)

5. Good friends bring good deals but great friends bring good deadlines. 😅

The Aftermath

Would I do it again?
Probably. But this time, I’d ask for a weekend extension and maybe a manicure to celebrate.

Building that salon app reminded me why I love being a developer.
You’re not just writing code, you’re building systems that make real people’s lives easier.

That’s what makes the grind worth it.

Thanks for reading!

If you enjoy real dev stories, Flutter/Firebase insights, and lessons from the trenches, subscribe to get my next post.

I share how I build beautiful, human-centered digital experiences (sometimes under ridiculous deadlines) and write simplified code examples that break down complex concepts in a way even a toddler can understand.

Whether you’re here for inspiration, clean Flutter patterns, or just a laugh at what can go wrong during a 4-day sprint, you’ll feel right at home. 🚀

Subscribe now

We all learned Data Structures and Algorithms (DSA) for interviews.
Then we got jobs, built features, shipped apps and quietly forgot most of it.

But here’s the truth;
You’re still using DSA every single day just not always the right way.

Most developers don’t write “bad code.”
They write code that works now and hurts later.

Let’s expose a few real-world examples from Flutter apps to Node.js backends where your everyday logic hides DSA mistakes you didn’t know you were making.

Flutter: The ListView Trap

You’ve probably written something like this:

// Imagine 10,000 users
List<User> users = [...]; 
List<User> filtered = users.where((u) => u.isActive).toList();

Seems harmless, right?
But every .where() and .toList() call is O(n), meaning it rebuilds a brand new list every time your widget rebuilds.

Now imagine this running inside a reactive widget like StreamBuilder or FutureBuilder that updates frequently.
You’re re-creating thousands of objects per rebuild.

Better way: Use an indexed structure like Map<String, User> or cache your filters.

Map<String, User> userMap = {
  for (var u in users) u.id: u,
};

User? getUser(String id) => userMap[id];

Now you’ve turned a repetitive O(n) search into a clean O(1) lookup and saved your UI rebuilds from unnecessary lag.

The biggest DSA mistake in Flutter isn’t in syntax — it’s in state inefficiency.

Node.js: The Array Search Bottleneck

Typical backend logic:

const users = await db.getUsers();
const user = users.find(u => u.email === email);

It works fine — until you have tens of thousands of users in memory.
.find() does a linear search (O(n)) every single time.

Better way: Build an index using a hash map.

const usersByEmail = Object.fromEntries(users.map(u => [u.email, u]));
const user = usersByEmail[email];

You’ve just turned a linear scan into an instant lookup.
Same output. Huge performance difference.

DSA isn’t about knowing Big O by heart, it’s about recognizing why that one line slows everything down.

Flutter: Sorting Lists That Never Change

You want to show your leaderboard:

List<Player> players = fetchPlayers();
players.sort((a, b) => b.score.compareTo(a.score));

Perfectly fine until you sort every rebuild, even when nothing has changed.
That’s O(n log n) on every frame.

Better way: Sort once, and store in a PriorityQueue (from collection package):

import ‘package:collection/collection.dart’;

final queue = PriorityQueue<Player>((a, b) => b.score.compareTo(a.score));
queue.addAll(players);

final topThree = queue.take(3).toList();

You’re now using a heap under the hood optimized for top-k retrieval instead of full list sorting. Cleaner, smarter, faster.

Node.js: The “Append” Queue Mistake

We’ve all done this in background workers:

const queue = [];
queue.push(”sendEmail”);
queue.push(”generateInvoice”);
const nextTask = queue.shift(); // Process first

Looks okay, but .shift() moves every other item one step forward; O(n) per dequeue.

Better way: Use a proper queue structure (like deque from npm):

import Deque from “double-ended-queue”;

const queue = new Deque();
queue.push(”sendEmail”);
queue.push(”generateInvoice”);

const nextTask = queue.shift(); // O(1)

Simple change. Massive difference in load-heavy systems.

Many “slow queues” aren’t slow because of logic — they’re slow because of the wrong data structure.

The DSA Mindset

The danger with modern frameworks is that everything feels fast at first.
Flutter rebuilds effortlessly. Node.js handles thousands of requests.

But scale exposes DSA blindness:

• That .find() call becomes a CPU hog.

• That repeated .sort() melts milliseconds you can’t afford.

• That rebuild-heavy filter drains frames from your UI.

You’re not writing “bad” code, you’re writing unaware code.

Once you see DSA patterns, you can’t unsee them:

• Use sets and maps for lookups.

• Use queues or heaps for dynamic data.

• Cache intelligently.

• Think time complexity, not just syntax.

My Final Thoughts

Code that works is easy.
Code that scales gracefully takes awareness.

Every loop, every search, every rebuild carries a hidden cost and DSA is your cheat sheet to pay less.

So the next time your app “just works,” ask yourself:
👉 Would it still work this fast with 100x more data?

If not it’s time to bring DSA back to the table.

In this tutorial, you’ll learn how to build your own SDK in JavaScript (using TypeScript), bundle it for npm, test it locally, and publish it publicly.

We’ll create a simple but useful example: an OTP (One-Time Password) generator SDK that you can use in your projects or extend into something bigger.

Why Build Your Own SDK?

Creating your own SDK helps you:

• Reuse logic across multiple projects

• Share utilities or integrations with others

• Learn real-world module bundling and publishing workflows

• Strengthen your open-source portfolio

And if you’re building on platforms like Next.js, or Node.js, you’ll find SDKs invaluable for cleanly organizing and distributing code.

Step 1: Create Your SDK Project Folder

Let’s start by creating the project directory and initializing npm.

mkdir otp-generator
cd otp-generator
npm init -y

This sets up your package.json — the configuration file for every npm project.

Step 2: Install Development Dependencies

You’ll need a few essential tools to write, compile, and test your SDK.

npm install typescript tsup tsx concurrently @types/node --save-dev

What these do:
typescript: Enables modern TypeScript features
tsup: Bundles code into multiple module formats
tsx: Runs TypeScript directly without compiling
concurrently: Runs multiple scripts together
@types/node: Adds Node.js type definitions

Step 3: Set Up Your Folder Structure

Organize your project like this:

Optional, you can choose your own project structure

otp-generator/
├── src/
│   ├── core/
│   │   └── generator.ts
│   └── index.ts
├── test-folder/
│   └── script.ts
├── tsconfig.json
├── tsup.config.ts
├── package.json
└── .npmignore

This structure keeps your source code, tests, and configuration files clearly separated.

Step 4: Write Your Core Function (The Heart of the SDK)

Let’s build our core functionality, a random OTP generator in src/core/generator.ts.

export function generateRandomDigits(length: number = 4): string {
  let result = “”;
  const digits = “0123456789”;

  for (let i = 0; i < length; i++) {
    const randomIndex = Math.floor(Math.random() * digits.length);
    result += digits[randomIndex];
  }

  return result;
}

This function returns a string of random digits (default length 4).
You can easily reuse or extend it for PIN codes, tokens, or verification systems.

Step 5: Export Everything from index.ts

Create src/index.ts to serve as the entry point of your SDK.

export * from “./core/generator”;

This ensures users can simply import your SDK without worrying about file paths.

Step 6: Configure TypeScript

{
  “compilerOptions”: {
    “target”: “ES2022”,
    “module”: “ESNext”,
    “moduleResolution”: “Bundler”,
    “strict”: true,
    “esModuleInterop”: true,
    “skipLibCheck”: true,
    “declaration”: true,
    “declarationMap”: true,
    “isolatedModules”: true,
    “noEmit”: true,
    “forceConsistentCasingInFileNames”: true,
    “outDir”: “dist”
  },
  “include”: [”src”],
  “exclude”: [”dist”, “node_modules”]
}

This ensures your SDK is strict, modern, and generates declaration files (.d.ts) for type safety.

Step 7: Add the tsup Configuration

Tsup bundles your code for multiple environments (Node.js and browsers).
Create tsup.config.ts:

import { defineConfig } from “tsup”;

export default defineConfig({
  entry: [”src/index.ts”],
  format: [”cjs”, “esm”],
  dts: true,
  sourcemap: true,
  clean: true,
  shims: true,
  skipNodeModulesBundle: true,
  target: “es2022”,
  outDir: “dist”,
});

This configuration outputs:

• CommonJS build (index.js)

• ESModule build (index.mjs)

• TypeScript types (index.d.ts)

These three formats make your SDK compatible with both older Node.js projects and modern ES builds.

Step 8: Configure package.json

Update your package.json with build scripts and export settings:

NOTE: otpx-test should be respective to your own choosen

{
  “name”: “otpx-test”,
  “version”: “0.0.1”,
  “description”: “A test SDK for generating OTPs”,
  “author”: {
    “name”: “Jay”,
    “url”: “https://github.com/JaySyntax”
  },
  “license”: “MIT”,
  “keywords”: [”javascript sdk”, “typescript sdk”, “otp generator”, “npm package”],
  “main”: “./dist/index.js”,
  “module”: “./dist/index.mjs”,
  “types”: “./dist/index.d.ts”,
  “exports”: {
    “.”: {
      “types”: “./dist/index.d.ts”,
      “require”: “./dist/index.js”,
      “import”: “./dist/index.mjs”
    },
    “./package.json”: “./package.json”
  },
  “files”: [”dist”],
  “scripts”: {
    “dev”: “concurrently \”npm:build:watch\” \”tsx watch test-folder/script.ts\”“,
    “build”: “tsup”,
    “build:watch”: “tsup --watch”
  },
  “devDependencies”: {
    “@types/node”: “^24.8.1”,
    “concurrently”: “^9.2.1”,
    “tsup”: “^8.5.0”,
    “tsx”: “^4.0.0”,
    “typescript”: “^5.9.3”
  }
}

This ensures your SDK can be imported in both Node.js and browser environments.

Step 9: Add a .npmignore File

Exclude unnecessary files when publishing:

/dist
/node_modules
.env
.DS_Store
tsconfig.json
tsup.config.ts

Step 10: Test Your SDK Locally

Inside test-folder/script.ts, add:

import { generateRandomDigits } from “otpx-test”;

console.log(`The generated OTP code: ${generateRandomDigits()}`);
console.log(`The generated OTP code: ${generateRandomDigits(6)}`);

Then run:

npm run build
npm run dev

Output:

The generated OTP code: 4928
The generated OTP code: 105729

Step 11: Publish Your SDK to npm

Now let’s make your package public.

1. Create an npm account: npmjs.com

2. Login from the terminal:

   npm adduser

3. Verify login:

   npm whoami

4. Publish your SDK:

   npm publish

If everything is configured correctly, you’ll see:

+ otpx-test@0.0.1

Then check your npm package here under “Recently Published” — your package should appear there.

Step 12: Install and Use Your SDK Anywhere

Once published, your SDK is live!
You can install it anywhere with:

npm install otpx-test

Then import it:

import { generateRandomDigits } from “otpx-test”;

console.log(generateRandomDigits(6));

Final Thoughts

You’ve just learned how to build, test, and publish your own JavaScript/Typescript SDK from scratch
You now understand:

• How to structure a TypeScript SDK

• How to bundle for ESM and CommonJS

• How to test locally before publishing

• How to release on npm

Whether you’re developing API integrations or crafting your own developer tools, this workflow provides a reliable foundation to build on.

🔗 Explore the full project on GitHub:
https://github.com/JaySyntax/otp-generator

Introduction

Modern mobile users expect real-time updates, whether they’re tracking a food order, checking a delivery status, or watching a countdown timer.

On iOS, this comes to life through Live Activities beautiful, glanceable widgets that live on the Lock Screen and Dynamic Island.

On Android, the equivalent experience is delivered through Live Updates, ongoing notifications that update dynamically to reflect the latest state.

Most Flutter developers rely on third-party plugins to bridge this functionality.
But in this tutorial, we’ll do it the pure way implementing both Live Activities (iOS) and Live Updates (Android) without any plugins or packages, using only Flutter, Swift, and Kotlin.

By the end, you’ll have:

• A working Flutter app that shows Live Activities on iOS

• A persistent, updating notification on Android

• A unified Flutter API for managing both platforms cleanly

Let’s get started.

Prerequisites

Tools

• Flutter SDK (3.0 or higher)

• Xcode 15+ for iOS

• Android Studio for Android

Knowledge

• Familiarity with platform channels in Flutter

• Basic understanding of Swift and Kotlin

• iOS 16.1+ and Android 8.0+ target environments

Setting Up the Flutter Project

Before we dive into Live Activities and Live Updates, let’s start with a clean Flutter setup.
Our goal here is to prepare a single project that will run natively on both iOS and Android, with the necessary platform configurations for each side.

Create a new Flutter project

Open your terminal and run:

flutter create flutter_live_demo --platforms=android,ios

This creates a new Flutter project named flutter_live_demo with the default counter app structure.

You can open the project in your IDE of choice:

• Android Studio / IntelliJ IDEA

• Visual Studio Code

• Windsurf

• …or any Flutter-friendly editor.

Upon successful project creation and removal of all unwanted comments in the main.dart file, you should have a working clean code as this.

import ‘package:flutter/material.dart’;

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: ‘Flutter Demo’,
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
      ),
      home: const MyHomePage(title: ‘Flutter Demo Home Page’),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(’You have pushed the button this many times:’),
            Text(
              ‘$_counter’,
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: ‘Increment’,
        child: const Icon(Icons.add),
      ),
    );
  }
}

Setting Up Xcode & Adding the Widget Extension (iOS)

Now that our Flutter project is ready, let’s set up the iOS side, where we’ll add a Widget Extension to enable Live Activities.

Open the project in Xcode

In your Flutter project, right-click the ios folder and select:

“Open in Xcode”

This opens the iOS module as a standalone Xcode project (Runner.xcodeproj), allowing you to create native targets and files.

Create a Widget Extension

From the Xcode menu, go to:

File → New → Target → Widget Extension

Then click Next.

Give the widget a name, for example, DeliveryWidget and make sure that all checkboxes under “Bundle Identifier” are unchecked.

Why?
Because we’re building a bare-bones implementation, we don’t need WidgetKit to auto-generate additional files or provisioning for now.

Click Finish, then when Xcode asks:

“Activate DeliveryWidgetExtension scheme?”

Choose Activate.

“New Target” dialog showing “Widget Extension” selected and your chosen name.

Create a Swift file for your Live Activity attributes

Right-click the Runner folder → New File → Swift File
Name it DeliveryAttributes.swift, and make sure the file is added to the DeliveryWidgetExtension target (check the box before hitting Create).

Now add the following code:

import ActivityKit
import Foundation

struct DeliveryAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        var progress: Double
        var minutesToDelivery: Int
    }

    var orderNumber: String
}

This file defines:

• Static attributes → data that doesn’t change (e.g., orderNumber)

• Dynamic state → live data that updates in real time (progress, minutesToDelivery)

Design the Widget (DeliveryWidget.swift)

Xcode automatically created a file named DeliveryWidget.swift when you added the widget target.
Open it and replace its content with the following:

import WidgetKit
import SwiftUI
import ActivityKit

@available(iOSApplicationExtension 16.1, *)
struct DeliveryWidget: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: DeliveryAttributes.self) { context in
            // Lock screen / Dynamic Island (compact)
            VStack {
                Text(”🚴 Delivery on the way!”)
                Text(”Progress: \(Int(context.state.progress))%”)
                Text(”Time left: \(context.state.minutesToDelivery) min”)
            }
            .activityBackgroundTint(Color.cyan)
            .activitySystemActionForegroundColor(.white)
        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.center) {
                    VStack {
                        Text(”🚴 Your order is coming!”)
                        Text(”\(Int(context.state.progress))% complete”)
                    }
                }
                DynamicIslandExpandedRegion(.bottom) {
                    Text(”ETA: \(context.state.minutesToDelivery) min”)
                }
            } compactLeading: {
                Text(”🚴”)
            } compactTrailing: {
                Text(”\(Int(context.state.progress))%”)
            } minimal: {
                Text(”🚴”)
            }
        }
    }
}

This defines how your Live Activity will appear on:

• The Lock Screen

• The Dynamic Island (expanded, compact, and minimal states)

Enable Live Activity capabilities

We need to declare that our app supports Live Activities.

Open your Info.plist file (ios/Runner/Info.plist) and add these keys:

<key>NSSupportsLiveActivities</key>
<true/>
<key>NSSupportsLiveActivitiesFrequentUpdates</key>
<true/>

This tells iOS your app can display and frequently update Live Activities.

Note, ensure your build phase is orderly arrange like this to avoid unforeseen error such as this
Error (Xcode): Cycle inside Runner; building could produce unreliable results. This usually can be resolved by moving the shell script phase ‘Thin Binary’ so that it runs before the build phase that depends on its outputs.

Bridge Flutter to iOS (AppDelegate.swift)

We’ll use a MethodChannel to send messages from Flutter → Swift to start, update, and end a Live Activity.

Open ios/Runner/AppDelegate.swift and replace it with the following:

import Flutter
import UIKit
import ActivityKit

@available(iOS 16.1, *)
@main
@objc class AppDelegate: FlutterAppDelegate {

    var deliveryActivity: Activity<DeliveryAttributes>? = nil

    override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        let controller = window?.rootViewController as! FlutterViewController
        let channel = FlutterMethodChannel(
            name: “com.example.flutter_live_demo”,
            binaryMessenger: controller.binaryMessenger
        )
        
        channel.setMethodCallHandler { [weak self] call, result in
            guard let self = self else { return }

            switch call.method {
            case “startNotifications”:
                if let args = call.arguments as? [String: Any] {
                    self.startLiveActivity(args: args)
                }
                result(nil)
            case “updateNotifications”:
                if let args = call.arguments as? [String: Any] {
                    self.updateLiveActivity(args: args)
                }
                result(nil)
            case “finishDeliveryNotification”, “endNotifications”:
                self.endLiveActivity()
                result(nil)
            default:
                result(FlutterMethodNotImplemented)
            }
        }

        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }

    private func startLiveActivity(args: [String: Any]) {
        guard ActivityAuthorizationInfo().areActivitiesEnabled else { return }

        let orderNumber = “ORDER123” // can be dynamic later
        let attributes = DeliveryAttributes(orderNumber: orderNumber)
        let state = DeliveryAttributes.ContentState(
            progress: args[”progress”] as? Double ?? 0,
            minutesToDelivery: args[”minutesToDelivery”] as? Int ?? 1
        )

        do {
            deliveryActivity = try Activity.request(
                attributes: attributes,
                contentState: state,
                pushType: nil
            )
            print(”✅ Live Activity started: \(deliveryActivity?.id ?? “”)”)
        } catch {
            print(”❌ Failed to start activity: \(error)”)
        }
    }

    private func updateLiveActivity(args: [String: Any]) {
        guard let activity = deliveryActivity else { return }
        let updatedState = DeliveryAttributes.ContentState(
            progress: args[”progress”] as? Double ?? 0,
            minutesToDelivery: args[”minutesToDelivery”] as? Int ?? 0
        )

        Task {
            await activity.update(using: updatedState)
            print(”🔄 Activity updated with progress: \(updatedState.progress)”)
        }
    }

    private func endLiveActivity() {
        guard let activity = deliveryActivity else { return }

        Task {
            await activity.end(
                using: DeliveryAttributes.ContentState(progress: 100, minutesToDelivery: 0),
                dismissalPolicy: .immediate
            )
            print(”🛑 Live Activity ended”)
        }
    }
}

Setting Up Android for Live Updates

The next step is to implement the Android side of our “Live Update” system. Unlike iOS’s ActivityKit, Android doesn’t have a direct Live Activities equivalent but we can replicate the same experience using custom notifications and RemoteViews for dynamic layouts.

Let’s break down the steps 👇

Open the Android module

In Android Studio, open your project’s android/ directory from your Flutter workspace.

Add notification permissions

Open AndroidManifest.xml and add the following permissions outside the <application> tag:

<uses-permission android:name=”android.permission.POST_NOTIFICATIONS” />
<uses-permission android:name=”android.permission.FOREGROUND_SERVICE” />

These allow your app to post and update notifications, and run background updates when needed.

Create the notification layout

Inside res/layout/, create a new file called delivery_layout.xml.

This layout defines the custom view of your notification, similar to what iOS shows in its Live Activity UI.

<?xml version=”1.0” encoding=”utf-8”?>
<LinearLayout
    xmlns:android=”http://schemas.android.com/apk/res/android”
    android:layout_width=”match_parent”
    android:layout_height=”wrap_content”
    android:orientation=”vertical”
    android:padding=”16dp”
    android:background=”@android:color/white”>

    <!-- Top row: “Delivering in X minutes” -->
    <LinearLayout
        android:layout_width=”match_parent”
        android:layout_height=”wrap_content”
        android:orientation=”horizontal”>

        <TextView
            android:id=”@+id/delivery_message”
            android:layout_width=”wrap_content”
            android:layout_height=”wrap_content”
            android:text=”@string/delivering_in”
            android:textSize=”16sp”
            android:textColor=”#000000” />

        <TextView
            android:id=”@+id/minutes_to_delivery”
            android:layout_width=”wrap_content”
            android:layout_height=”wrap_content”
            android:text=”@string/_5_min”
            android:textColor=”#008000”
            android:textSize=”16sp”
            android:layout_marginStart=”4dp” />
    </LinearLayout>

    <!-- Subtitle text -->
    <TextView
        android:id=”@+id/delivery_subtitle”
        android:layout_width=”wrap_content”
        android:layout_height=”wrap_content”
        android:text=”@string/your_delivery_is_on_the_way”
        android:textSize=”14sp”
        android:textColor=”#555555”
        android:layout_marginTop=”8dp” />

    <!-- Progress bar representing delivery progress -->
    <ProgressBar
        android:id=”@+id/progress”
        style=”?android:attr/progressBarStyleHorizontal”
        android:layout_width=”match_parent”
        android:layout_height=”8dp”
        android:layout_marginTop=”12dp”
        android:max=”100”
        android:progress=”30”
        android:progressTint=”#008000”
        android:progressBackgroundTint=”#E0E0E0” />

    <!-- Numeric progress label -->
    <TextView
        android:id=”@+id/progress_text”
        android:layout_width=”match_parent”
        android:layout_height=”wrap_content”
        android:text=”@string/_30”
        android:textSize=”12sp”
        android:textColor=”#444444”
        android:gravity=”end”
        android:layout_marginTop=”4dp” />

</LinearLayout>

Add string resources

In res/values/strings.xml, add:

<?xml version=”1.0” encoding=”utf-8”?>
<resources>
    <string name=”delivering_in”>Delivering in</string>
    <string name=”_5_min”>5 min</string>
    <string name=”your_delivery_is_on_the_way”>Your delivery is on the way</string>
    <string name=”_30”>30%</string>
</resources>

Create DeliveryManager.kt file

This file encapsulates all the logic for showing, updating, and clearing live notifications. Create a new Kotlin file in
android/app/src/main/java/com/example/flutter_live_demo/DeliveryManager.kt

package com.example.flutter_live_demo

import android.app.*
import android.content.*
import android.os.Build
import android.view.View
import android.widget.RemoteViews
import androidx.annotation.RequiresApi

@RequiresApi(Build.VERSION_CODES.O)
class DeliveryManager(private val context: Context)  {

    // Reference to our custom notification layout
    private val remoteViews = RemoteViews(”com.example.flutter_live_demo”, R.layout.delivery_layout)

    // Notification channels for different priorities
    private val channelWithHighPriority = “channelWithHighPriority”
    private val channelWithDefaultPriority = “channelWithDefaultPriority”

    // Static notification ID to update the same one repeatedly
    private val notificationId = 100

    // Define the PendingIntent (tapping the notification reopens the app)
    private val pendingIntent = PendingIntent.getActivity(
        context,
        200,
        Intent(context, MainActivity::class.java).apply {
            flags = Intent.FLAG_ACTIVITY_REORDER_TO_FRONT
        },
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
    )

    private val notificationManager = context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

    init {
        // Create the notification channels on initialization
        createNotificationChannel(channelWithDefaultPriority)
        createNotificationChannel(channelWithHighPriority, importanceHigh = true)
    }

    /** Create a notification channel if it doesn’t already exist */
    private fun createNotificationChannel(channelName: String, importanceHigh: Boolean = false) {
        val importance = if (importanceHigh) NotificationManager.IMPORTANCE_HIGH else NotificationManager.IMPORTANCE_DEFAULT
        val existingChannel = notificationManager.getNotificationChannel(channelName)

        if (existingChannel == null) {
            val channel = NotificationChannel(channelName, “App Delivery Notification”, importance).apply {
                setSound(null, null) // No sound
                vibrationPattern = longArrayOf(0L)
            }
            notificationManager.createNotificationChannel(channel)
        }
    }

    /** Builds the first notification when delivery starts */
    private fun onFirstNotification(minutesToDelivery: Int): Notification {
        val minuteString = if (minutesToDelivery > 1) “minutes” else “minute”
        return Notification.Builder(context, channelWithHighPriority)
            .setSmallIcon(R.drawable.ic_launcher_foreground)
            .setContentTitle(”Live Notification - Delivery out for shipment”)
            .setContentText(”Your delivery comes in $minutesToDelivery $minuteString”)
            .setContentIntent(pendingIntent)
            .setCustomBigContentView(remoteViews)
            .build()
    }

    /** Builds the ongoing progress notification */
    private fun onGoingNotification(minutesToDelivery: Int): Notification {
        val minuteString = if (minutesToDelivery > 1) “minutes” else “minute”
        return Notification.Builder(context, channelWithDefaultPriority)
            .setSmallIcon(R.drawable.ic_launcher_foreground)
            .setOngoing(true)
            .setContentTitle(”Live Notification - Delivery on the way”)
            .setContentText(”Your delivery comes in $minutesToDelivery $minuteString”)
            .setContentIntent(pendingIntent)
            .setCustomBigContentView(remoteViews)
            .build()
    }

    /** Final delivery arrived notification */
    private fun onFinishNotification(): Notification {
        return Notification.Builder(context, channelWithHighPriority)
            .setSmallIcon(R.drawable.ic_launcher_foreground)
            .setContentTitle(”Live Notification - Arrives”)
            .setContentText(”Your delivery arrived”)
            .setAutoCancel(true)
            .setContentIntent(pendingIntent)
            .setCustomBigContentView(remoteViews)
            .build()
    }

    /** Show initial live notification */
    fun showNotification(currentProgress: Int, minutesToDelivery: Int) {
        val notification = onFirstNotification(minutesToDelivery)
        val minuteString = if (minutesToDelivery > 1) “minutes” else “minute”

        // Update remote views with current values
        remoteViews.setTextViewText(R.id.minutes_to_delivery, “$minutesToDelivery $minuteString”)
        remoteViews.setTextViewText(R.id.progress_text, “$currentProgress%”)
        remoteViews.setProgressBar(R.id.progress, 100, currentProgress, false)

        notificationManager.notify(notificationId, notification)
    }

    /** Update progress dynamically */
    fun updateNotification(currentProgress: Int, minutesToDelivery: Int) {
        val notification = onGoingNotification(minutesToDelivery)
        val minuteString = if (minutesToDelivery > 1) “minutes” else “minute”

        remoteViews.setTextViewText(R.id.minutes_to_delivery, “$minutesToDelivery $minuteString”)
        remoteViews.setTextViewText(R.id.progress_text, “$currentProgress%”)
        remoteViews.setProgressBar(R.id.progress, 100, currentProgress, false)

        notificationManager.notify(notificationId, notification)
    }

    /** Show “delivery complete” notification */
    fun finishDeliveryNotification() {
        val notification = onFinishNotification()

        remoteViews.setTextViewText(R.id.delivery_message, “Your delivery arrived”)
        remoteViews.setViewVisibility(R.id.progress, View.GONE)
        remoteViews.setViewVisibility(R.id.progress_text, View.GONE)
        remoteViews.setViewVisibility(R.id.minutes_to_delivery, View.GONE)
        remoteViews.setTextViewText(R.id.delivery_subtitle, “Enjoy your delivery :)”)

        notificationManager.notify(notificationId, notification)
    }

    /** Clean up notification channels and reset views */
    fun endNotification() {
        notificationManager.deleteNotificationChannel(channelWithHighPriority)
        notificationManager.deleteNotificationChannel(channelWithDefaultPriority)

        // Reset layout for next session
        remoteViews.setTextViewText(R.id.delivery_message, “Delivering in”)
        remoteViews.setTextViewText(R.id.delivery_subtitle, “Your delivery is coming”)
        remoteViews.setViewVisibility(R.id.progress, View.VISIBLE)
        remoteViews.setViewVisibility(R.id.progress_text, View.VISIBLE)
        remoteViews.setViewVisibility(R.id.minutes_to_delivery, View.VISIBLE)
    }
}

Update MainActivity.kt

This connects your Flutter MethodChannel to Android’s native notification system.

package com.example.flutter_live_demo

import io.flutter.embedding.android.FlutterActivity

import android.Manifest
import android.os.Build
import android.os.Bundle
import androidx.core.app.ActivityCompat
import io.flutter.plugin.common.MethodChannel
import io.flutter.embedding.engine.FlutterEngine


class MainActivity: FlutterActivity() {

    private val permissions = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
        arrayOf(Manifest.permission.POST_NOTIFICATIONS)
    } else {
        arrayOf()
    }
    private val flutterChannel = “com.example.flutter_live_demo”
    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, flutterChannel).setMethodCallHandler {
                call, result ->
            if (call.method == “startNotifications”) {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                    val args = call.arguments<Map<String, Any>>()
                    val progress = args?.get(”progress”) as? Int
                    val minutes = args?.get(”minutesToDelivery”) as? Int

                    if( progress != null && minutes != null){
                        DeliveryManager(context).showNotification(progress,minutes)
                    }
                }
                result.success(”Notification displayed”)
            }
            else if (call.method == “updateNotifications”) {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                    val args = call.arguments<Map<String, Any>>()
                    val progress = args?.get(”progress”) as? Int
                    val minutes = args?.get(”minutesToDelivery”) as? Int
                    if(progress != null && minutes != null){
                        DeliveryManager(context)
                            .updateNotification(currentProgress =  progress, minutesToDelivery = minutes)
                    }
                }
            }
            else if (call.method == “finishDeliveryNotification”) {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                    DeliveryManager(context)
                        .finishDeliveryNotification()
                }
                result.success(”Notification delivered”)
            }
            else if (call.method == “endNotifications”) {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                    DeliveryManager(context)
                        .endNotification()
                }
                result.success(”Notification cancelled”)
            }
        }
    }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            ActivityCompat.requestPermissions(this, permissions, 200)
        }
    }

    override fun onStop() {
        super.onStop()
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            DeliveryManager(context).endNotification()
        }
    }
}

Putting It All Together in Flutter

Now that we’ve set up the native sides (iOS & Android), let’s integrate everything back into Flutter.

Create a Model – delivery.dart

In your lib/model folder, create a file named delivery.dart:

class Delivery {
  int minutesToDelivery;
  int progress;

  Delivery({
    required this.minutesToDelivery,
    required this.progress,
  });

  Map<String, dynamic> toJson() {
    final Map<String, dynamic> data = <String, dynamic>{};
    data[’minutesToDelivery’] = minutesToDelivery;
    data[’progress’] = progress;
    return data;
  }
}

💡 What this does:
This model represents the data being passed between Flutter and the native layer — the progress and estimated minutes to delivery that will appear in your Live Activity.

Create a Service – delivery_service.dart

Next, let’s create the bridge between Flutter and native using a MethodChannel.

In lib/service/delivery_service.dart:

import ‘package:flutter/services.dart’;
import ‘package:flutter_live_demo/model/delivery.dart’;

class DeliveryService {
  final MethodChannel _method = const MethodChannel(
    “com.example.flutter_live_demo”,
  );

  Future<void> startNotifications({required Delivery data}) async {
    try {
      await _method.invokeMethod(”startNotifications”, data.toJson());
    } on PlatformException catch (e) {
      throw PlatformException(code: e.code);
    }
  }

  Future<void> updateNotifications({required Delivery data}) async {
    try {
      await _method.invokeMethod(”updateNotifications”, data.toJson());
    } on PlatformException catch (e) {
      throw PlatformException(code: e.code);
    }
  }

  Future<void> finishDeliveryNotification() async {
    try {
      await _method.invokeMethod(”finishDeliveryNotification”);
    } on PlatformException catch (e) {
      throw PlatformException(code: e.code);
    }
  }

  Future<void> endNotifications() async {
    try {
      await _method.invokeMethod(”endNotifications”);
    } on PlatformException catch (e) {
      throw PlatformException(code: e.code);
    }
  }
}

💡 What this does:
This service communicates with the Swift AppDelegate/MainActivity file you created earlier.
Each function corresponds to a native method:

• startNotifications → starts the Live Activity

• updateNotifications → updates the Live Activity in real time

• finishDeliveryNotification → marks the delivery complete

• endNotifications → ends and clears the activity

Update main.dart

Finally, open lib/main.dart and replace its contents with the following:

import ‘dart:async’;
import ‘package:flutter/material.dart’;
import ‘package:flutter_live_demo/model/delivery.dart’;
import ‘package:flutter_live_demo/service/delivery_service.dart’;

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: ‘Flutter Live Activity Demo’,
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
      ),
      home: const MyHomePage(title: ‘Delivery Live Activity’),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  Timer? timer;
  final DeliveryService deliveryService = DeliveryService();
  Delivery liveNotificationData = Delivery(minutesToDelivery: 1, progress: 0);

  void startPooling() {
    timer?.cancel();
    int seconds = 0;
    int minutes = liveNotificationData.minutesToDelivery;
    int progress = 0;

    timer = Timer.periodic(const Duration(seconds: 1), (value) async {
      setState(() {
        seconds++;
        if (seconds % 60 == 0) {
          liveNotificationData.minutesToDelivery--;
        }
        progress = ((seconds * 100) / (minutes * 60)).round();
        if (progress > 100) progress = 100;
        liveNotificationData.progress = progress;
      });

      if (liveNotificationData.progress >= 100) {
        await deliveryService.finishDeliveryNotification();
        timer?.cancel();
      } else {
        await deliveryService.updateNotifications(data: liveNotificationData);
      }
    });
  }

  void endPooling() {
    timer?.cancel();
    liveNotificationData = Delivery(minutesToDelivery: 1, progress: 0);
    deliveryService.endNotifications();
    setState(() {});
  }

  @override
  void dispose() {
    endPooling();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    final double progressValue = liveNotificationData.progress / 100;

    return Scaffold(
      appBar: AppBar(centerTitle: true, title: const Text(”Live Notification”)),
      body: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 24.0),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text(
              “Delivery Progress”,
              style: Theme.of(context).textTheme.titleLarge,
            ),
            const SizedBox(height: 16),
            TweenAnimationBuilder<double>(
              tween: Tween(begin: 0, end: progressValue),
              duration: const Duration(milliseconds: 400),
              builder: (context, value, _) => LinearProgressIndicator(
                value: value,
                backgroundColor: Colors.grey.shade300,
                color: Colors.blueAccent,
                minHeight: 12,
                borderRadius: BorderRadius.circular(10),
              ),
            ),
            const SizedBox(height: 12),
            Text(
              “${liveNotificationData.progress.toStringAsFixed(0)}%”,
              style: Theme.of(context)
                  .textTheme
                  .bodyLarge!
                  .copyWith(fontWeight: FontWeight.bold),
            ),
            const SizedBox(height: 24),
            Text(
              “Estimated time remaining: ${liveNotificationData.minutesToDelivery} min”,
              style: Theme.of(context).textTheme.bodyMedium,
            ),
            const SizedBox(height: 40),
            ElevatedButton.icon(
              onPressed: () async {
                setState(() {
                  liveNotificationData = Delivery(
                    minutesToDelivery: 1,
                    progress: 0,
                  );
                });
                await deliveryService
                    .startNotifications(data: liveNotificationData)
                    .then((_) => startPooling());
              },
              icon: const Icon(Icons.play_arrow),
              label: const Text(”Start Notifications”),
            ),
            const SizedBox(height: 16),
            ElevatedButton.icon(
              onPressed: endPooling,
              icon: const Icon(Icons.stop),
              label: const Text(”End Notifications”),
              style: ElevatedButton.styleFrom(
                backgroundColor: Colors.redAccent,
              ),
            ),
          ],
        ),
      ),
    );
  }
}

Conclusion

And there you have it, a fully functional cross-platform Live Activity and Live Update system built with nothing but Flutter, Swift, and Kotlin, completely free of third-party plugins or dependencies.

In this tutorial, we’ve explored how to:

• Set up a unified Flutter project for iOS and Android

• Implement iOS Live Activities using ActivityKit and Swift

• Build Android Live Updates using custom notifications and RemoteViews

• Bridge both platforms with Flutter’s MethodChannel for smooth communication

This approach not only gives you total control over your implementation but also deepens your understanding of how Flutter interacts with native layers, a valuable skill for any serious Flutter developer.

If you’d like to dive deeper or get the full working source code, visit the GitHub repository below:

👉 View Project on GitHub – flutter_live_demo

But here’s the truth nobody puts on the sprint board: software doesn’t fail on the happy path, it fails in the dark corners where errors live.

Think about it, when was the last time a user filed a bug report saying “the checkout worked exactly as intended, great job!”? Never. Users complain when the app breaks, freezes, or tells them:

Something went wrong. Please try again later.

🙄 That message is the software equivalent of a shrug. And it’s why I argue that error handling isn’t an afterthought, it’s part of the feature itself.

Why We Ignore Errors

There are a few reasons why error handling gets kicked down the backlog:

1. Deadlines – “We’ll add proper error states in v2.” (Spoiler: v2 never comes.)

2. Happy path bias – We design for success, not failure.

3. Invisible value – A smooth checkout flow is demo worthy. A retry with exponential backoff? Less sexy.

But here’s the catch: if users can’t recover from an error, the feature is effectively broken.

Error Handling = User Experience

This isn’t just engineering nitpicking, it’s a UX problem. Nielsen Norman Group found that unclear error messages destroy user trust and research from Microsoft shows that reliability is one of the top factors in overall user satisfaction.

Here’s the kicker: users don’t notice great error handling, but they feel its absence immediately.

Imagine two apps:

• App A crashes if your internet drops during checkout.

• App B pauses, saves your cart locally, and retries when you’re back online.

Guess which one earns repeat customers?

A Practical Framework for Better Error Handling

So how do you move beyond console.log("error")? Here are some tactics you can apply today:

1. Retry Strategies

• When something fails, our first instinct is to “try again.” But naive retries can make things worse: imagine 10,000 clients all retrying at the same time after a service hiccup; hello, DDoS against your own servers.

  Best practices for retries:

  • Exponential Backoff with Jitter

    • Instead of retrying at fixed intervals (1s, 1s, 1s), use exponential growth: 1s → 2s → 4s → 8s.

    • Add jitter (randomization) so retries don’t synchronize across clients.

      Example: AWS SDKs build jitter into their retry strategies.

  • Idempotency Keys

    • Ensure retrying the same request doesn’t cause duplicate side effects.

    • Example: When charging a credit card, include a unique idempotency_key. If the server sees the same key twice, it ignores the duplicate.

      Stripe and PayPal rely heavily on this pattern.

  • Retry Limits + Fallbacks

    • Never retry forever. Set a max retry count or timeout window.

      After that, gracefully degrade: save work locally, notify the user, or queue for later processing.

  👉 Note: Retry, but retry smart—otherwise you’ll just turn small hiccups into bigger outages.

2. User-Friendly Messages

• Error messages are the face of your failure handling. They’re not just technical notes; they’re part of your product’s tone of voice.

  What makes a good error message:

  • Clarity: Avoid jargon, nobody outside engineering knows what a NullPointerException is.

  • Actionable Guidance: Tell the user what they can do next. (“Please refresh.” “Try again later.” “Check your internet connection.”)

  • Reassurance: Reduce panic. Show users their work isn’t lost.

  • Tone: Match the product’s personality. A banking app might be formal, while a note-taking app can be friendly.

  Bad vs Good Example:

  • ❌ “500 Internal Server Error.” (technical, cold, useless)

  • ⚠️ “We couldn’t load your notes right now. Please refresh.” (better, but puts the burden on the user)

  • ✅ “We couldn’t load your notes. Don’t worry—we’ve saved your draft locally and will retry in the background.” (empathetic, helpful, reassuring)

  👉 Note: Treat error messages as microcopy. They build (or break) trust.

3. Logging for Humans

Logs are not just for machines, they’re for the humans who’ll be debugging production at 2 AM. Writing useless logs is like leaving breadcrumbs that lead nowhere.

Best practices for human-friendly logging:

• Context Is King

  • Include request IDs, user IDs, timestamps, and environment info.

    Example: ERROR: Payment failed | user=12345 | order=98765 | service=stripe | reason=timeout.

• Use Log Levels Properly

  • DEBUG – noisy details for local dev.

  • INFO – high-level system events (“User signed in”).

  • WARN – recoverable issues (“Retrying payment, attempt 2/3”).

  • ERROR – serious failures requiring attention.

  • FATAL – system is unusable.

• Avoid Log Spam

  • Repeating the same error 10,000 times makes the real issue invisible. Use aggregation and sampling.

• Structure Logs

  • JSON logs > free-text logs, because they’re easier to parse and feed into observability tools (ELK, Datadog, Grafana).

👉 Note: Write logs for your future self. If a log doesn’t help you fix a problem, it doesn’t belong.

4. Circuit Breakers and Fallbacks

Sometimes, the best way to handle errors is to stop trying before you break everything. That’s where circuit breakers come in.

Circuit Breaker Pattern (inspired by electrical systems):

• Closed State (normal): Requests flow normally.

• Open State (failure): After repeated failures, the breaker “opens” and blocks further requests.

• Half-Open State (testing): Occasionally allows a request to see if the service has recovered.

This prevents a failing dependency from dragging down the entire system. Netflix’s Hystrix pioneered this pattern in microservices.

Fallbacks:

• Cached Data: Show the last known state when live data fails (e.g., X (formally Twitter) showing old feeds when the new feeds won’t refresh).

• Limited Mode: Disable advanced features while keeping core functionality alive.

• Queue and Retry Later: Save user actions and process them once the system recovers.

👉 Note: Don’t let one broken service topple your whole app. Fail gracefully, not catastrophically.

Real-Life Example

Netflix famously treats error handling as a first-class feature. Their Chaos Monkey literally kills random services in production to test resilience.

Why? Because they know users don’t care that “Service X was temporarily unavailable.” They care that the show still plays.

That’s resilience and it starts with engineering errors as features, not bugs.

Closing Thought

Next time you’re designing a feature, don’t just ask: “What happens when it works?”

Ask: “What happens when it fails?”

Because from the user’s perspective, if recovery isn’t possible, the feature doesn’t exist.

Error handling is a feature. Build it like one.