Coder Legion - Recent posts tagged personalgrowth

Building in Public From a Solo Gamedev Perspective (credits to @Karol Modelski for the post idea)

Sat, 17 Oct 2026 18:51:27 +0000

Indie game development often begins with something deeply personal you really want to build. An atmosphere you want to create. A story you cannot stop thinking about. A mechanic you would love to experience as a player. Before anyone sees a screenshot or watches a devlog, there is already a reason you chose to build this particular game.

Then you start sharing it.

At first, building in public feels exciting. You show a mechanic, someone responds, and suddenly the work you have been doing alone becomes a conversation. A little encouragement can mean a great deal when you are learning, solving problems, and trying to turn an idea into something playable.

But that attention can gradually influence more than what you post. It can begin to influence what you build.

A visually impressive feature receives more interest than a system you spent weeks developing. A funny bug attracts more attention than an important milestone. One particular style of content performs well, so you make more of it. That is understandable. When something connects with people, you naturally want to understand why.

The difficulty begins when that response becomes the main reason behind your next decision.

You start choosing tasks partly because they will make a good upload that people will engage with. You spend time polishing something for a video while another feature, essential to the game, waits unfinished. You feel reluctant to share quieter progress because you already expect it to be ignored. Slowly, the audience’s preferences begin taking up space once occupied by your own intentions.

No one has explicitly asked you to change your game. Yet you find yourself changing its direction to keep people interested.

For a solo developer, this can be especially difficult. You are already responsible for learning, implementation, debugging, design, and countless decisions. Sharing development adds another responsibility: presenting that work in a way people want to watch. Eventually, it can feel as though every development session must also produce something worth posting.

Some progress simply does not work that way.

An evening spent fixing an interaction problem may produce no striking footage. Reworking a confusing interface might look like a small change despite requiring considerable thought. Building a reliable foundation can take weeks before there is anything exciting to demonstrate. Those efforts still matter to the person who will eventually play the game, even when they attract little attention online.

The emotional difficulty comes when you begin using that attention to judge yourself.

It hurts to put care into something and receive almost no response. It can hurt even more when people previously engaged with your work, then lose interest as you return to the direction that makes you happy. You may start questioning your ability, your project, or whether the effort has any value at all.

For some developers, that pressure can contribute to exhaustion, low mood, and eventually the decision to stop. An activity that once offered encouragement becomes another place where they feel they are falling short. A passion once holding you together starts breaking you apart!

That possibility deserves an honest conversation. Building in public can bring connection and useful feedback, but it can also become emotionally draining when every post feels like a verdict on your future.

I still choose to share my development. I have not received all the interaction I hoped for, and I will not pretend that never disappoints me. Of course I want people to care. Sharing something personal usually carries the hope that someone else will find meaning in it.

But I also want to recognize my own game when I look at what I am building.

I want to make decisions because they serve the experience I imagined, while remaining open to feedback that can improve it. Players can reveal confusing mechanics, unclear information, or problems I have overlooked. Listening to them is valuable. I can take those observations seriously and still decide which suggestions belong in my project.

The same applies to posting. I want to share when I have something I feel ready to show. A regular schedule may help some developers, but I do not want mine to become an obligation that makes development feel like feeding a content calendar. Sometimes the work needs time, privacy, and room to be unfinished.

If you enjoy what I share, thank you. Your interest means something to me. If it does not appeal to you, I appreciate you taking a look. There is no formula that will make one game meaningful to everyone, and trying to find it could consume the very enthusiasm that made me start.

For me, continuing means accepting that some updates will receive little attention and some people will move on. I can feel disappointed without allowing that disappointment to choose the next feature.

I started with a game I wanted to create. Sharing the journey should leave enough room for me to keep creating it.

Interconnected Growth: A Community Begins with Each of Us

Fri, 16 Oct 2026 19:17:32 +0000

There is a quiet vulnerability in sharing our work. Whether we publish an article, offer an idea, or describe something we have created, we put a small part of ourselves in front of others. Behind that contribution may be hours of effort, years of experience, or the courage to be visible for the first time.

Naturally, we hope someone will respond. A thoughtful comment, a reaction, or a simple acknowledgment can reassure us that our contribution has reached another person.

Within a growing community, however, that hope carries a shared responsibility. If we all publish and then wait for others to begin the conversation, even a website filled with valuable contributions can feel remarkably quiet.

Participation Makes Belonging Possible

A developing platform needs more than a steady flow of new content. It needs people who take an interest in what others bring to it.

It is understandable to focus on our own work. Time is limited, responsibilities compete for our attention, and many of us are trying to build something meaningful alongside other commitments. Still, when we hope for engagement, it is worth considering whether we are making room to offer it ourselves.

Reading another person’s article, acknowledging a useful observation, or asking a sincere question helps establish the culture we would like to experience. These small actions make participation feel worthwhile, particularly for people who are still finding their confidence.

For someone wondering whether their work belongs, a few considerate words may carry more weight than we realize.

Mutual Support Without Keeping Score

Supporting one another should never become an obligation to exchange praise. A reaction does not create a debt, and leaving a comment should not come with an expectation of repayment.

The value lies in sincere attention.

We can recognize effort without agreeing with every conclusion. We can offer a different perspective respectfully, share an experience that adds to the discussion, or explain what we found useful. Meaningful engagement gives someone evidence that their contribution has been considered.

Over time, that attention builds familiarity and trust. People become more comfortable sharing unfinished ideas, asking questions, and offering their own knowledge. The community gains depth because its members feel there is someone on the other side of the conversation.

Our Growth Is Connected

On a website that is still developing its community, each interaction helps shape what the platform becomes.

When we respond thoughtfully to someone’s work, we give them a reason to return and contribute again. Their continued participation may help another person learn, connect, or feel encouraged. What begins as a small gesture can gradually strengthen the experience for everyone.

No individual can create an active community alone, and nobody should feel responsible for responding to everything. But we can each contribute to an environment where attention moves in more than one direction.

Before leaving after our next post, perhaps we can spend a little time with someone else’s. Read beyond the headline. Acknowledge an idea that deserves consideration. Leave the kind of thoughtful response we would appreciate receiving.

Every contribution represents a person hoping to be heard. A growing community becomes stronger when we make space to hear one another.

How I Built a Telegram Habit-Tracker Bot with No Programming Experience

Mon, 21 Sep 2026 12:26:13 +0000

Hi everyone!

This is my first post here. I am writing not for experienced developers, but for those who want to gain their first programming experience using AI models.

Here is how it went for me.

Recently, I had no idea about programming and had never built Telegram bots. Three months ago, as an experiment, I started "vibe coding," and now I have a working Telegram bot with several thousand lines of code, modules for selecting and saving time, passwords, a database, payment processing, 10 languages, and chart generation. You can launch the bot at https://telegram.me/I_promise_myself_bot (click the "Try free & Unlock" button).

I want to share my experience—how I used several different LLMs in a regular free chat, how I bypassed limits, and how I got out of dead ends when the AIs completely stalled, forgot context, and the bot started breaking.

Where It All Started

Like everyone else, I started with ChatGPT, then tried Grok, Mistral, Gemini, Qwen, and DeepSeek bit by bit. I wanted to figure out through trial and error what each could do and for how long. I quickly ran into token limits in free chats. Also, over long distances, they lose context at different times, start mixing up file structures, and produce non-working pieces of code.

As long as there were 200-300 lines of code, working with AIs was manageable, but when the code exceeded 1,000 lines, the problems began. To overcome bottlenecks, I couldn't paste or upload such an amount of code into the window for the AI to see the whole code, find the exact error, or add a new feature.

Another problem was that any AI, as a rule, forgets the conversation after a few hours or starts hallucinating heavily. After that, you have to kill the chat and create a new one, re-supplying the new chat with the general task, snippets of chat history and code, and almost the entire conversation so it understands what I want from it. I regularly read bloggers, and regarding this, I asked Kostya Doronin for advice on how to work with AIs when code accumulates to more than 1,000 lines across multiple files. Surprisingly, he readily suggested several free and paid workarounds, but I managed with free ones only. I fundamentally wanted to figure out if it's possible to make something working with AIs for free.

I had to change my approach a bit. First, I roughly figured out what can be squeezed out of this or that AI, when they start glitching, and how to bypass it. I stopped loading one AI with all tasks at once and started dividing tasks among models.

I settled on these:

1.Claude is the architect. It has the best logic and understanding of the general code and project structure. I used it for brainstorming and design, modularizing, and creating step-by-step instructions for other AIs. Also as a "rescuer" in dead-end situations when another AI started leading me in circles. The only downside is that free tokens run out very quickly, and you have to wait a few hours.
2.Qwen turned out to be the main "workhorse" over long distances. If you give it a detailed plan from Claude, Qwen handles it well and sticks to the plan. Claude has strict limits on free messages, but with Qwen, you could code all day long in the same chat, solving tasks one step at a time. It holds up for about 7 days before hallucinations begin, after which you need to kill the chat and start a new one.
3.Gemini is an additional tool for quickly double-checking individual pieces of code, like a "fresh perspective" on a problem or a new task. But in the free version, it is not particularly good at programming and architecture, and if you work with it for a whole day or two, it also starts hallucinating. Although there were periods when these same models worked for weeks without any hallucinations at all. And sometimes a day was enough for both Qwen and Gemini to start glitching, which I never encountered with Claude. Probably because it ran out quickly! From which I concluded that model owners for some reason release different quality versions of the same model into the wild.

In other words, all these LLMs are a very unreliable thing, and for serious projects, you should only work with people. But as assistants in simple coding tasks, they are very good.

Project Architecture

At the beginning of creating the bot, Claude guided me step-by-step to download and set up all these tools on my computer:

•Language and framework: Python 3.11+, aiogram 3.x.
•Database: Started with simple Google Sheets, but eventually switched to PostgreSQL, hosted on Supabase. Mistake: should have used PostgreSQL from the very beginning.
•Background tasks: APScheduler for push notifications.
•Graphics: matplotlib for reports.
•Payments: Paddle SDK integration.
•Localization: Multilingual system based on JSON (languages). Mistake: did it at the very end, but should have done it at the very beginning because I had to redo a lot of things.
•Security: Isolating tokens in a separate file.

Development Process

For each new bot feature, I tasked Claude with developing as detailed a step-by-step instruction plan for Qwen as possible. I coded in VS Code, but didn't use LLMs inside it directly, only in chats:

1.I initially split the entire project into logical modules: there is one main file up to 2,000 lines, and the rest are 200-700 lines. Everything is separate – handlers, database operations, notifications, buttons, and localization.
2.Working with Qwen: Before any changes, I saved all recent files with working code in a separate folder so I could easily roll back. I gave Qwen a step-by-step plan and changed or added functionality step by step. I inserted it into the project, ran the bot, and checked the operation and logs. If there was a problem, I gave the logs to all three AIs at once to find the issue. If the problem hit a dead end, I started over from the last working code, but mentioned in the task to Claude (if tokens remained) that there were such-and-such problems during the previous change and they needed to be avoided. If Claude was exhausted, I asked Gemini. And so I moved step by step.

How I Got Out of Dead Ends

Somewhere in the middle of the project, the code exceeded a thousand lines, and problems began: the AI forgot the context and broke what was already working when trying to fix a bug.

At that moment, I brought in Claude:

1.I described the essence of the technical problem and the bot's startup logs in VS Code.
2.I provided snippets of chat history where Qwen started going in circles.
3.I attached the problematic code.

Mostly, Claude found the error on the first try and provided a solution. If it didn't know, it asked leading questions and we ran additional checks. Unlike Qwen or Gemini, which immediately "poured out" a bunch of possible causes after which going in infinite circles began. In especially neglected cases, I "pitted models against each other": I drove the problematic piece in circles between Claude, Gemini, and Qwen until one of them found the bug. Their collective intelligence works much more reliably.

Conclusions

After a few months of casual work, I got a working Telegram bot with several thousand lines of code, written from scratch with no experience.

What I realized for myself:

1.On simple tasks, AI replaces a team, but you need to understand the project structure well yourself and at least superficially understand the code. If you have no knowledge, you can learn to think systemically and architecturally on such projects.
2.Use different models. Using a single AI for everything is undesirable. The "architect + coder + fresh perspective" bundle works better.
3.Small steps. Wrote a function – tested it. Broke – rolled back to the last working version.
4.Save chat history. Chat history with AI helps you not to lose the logic of the project yourself after a week or month of work, and to provide context to another AI for problem analysis.

I will be glad to answer questions in the comments!

Two Ways to Write an Article in 2026 (And Why the Best Ones Use Both)

Mon, 17 Aug 2026 13:14:13 +0000

It's almost Midnight. Somewhere, a developer opens a blank tab, types a prompt into an AI, and has a polished 1,200-word article in minutes. Somewhere else, another developer opens the same blank tab, stares at it for forty minutes, deletes three sentences, writes one true one, and finally starts typing for real.

Both of them will hit publish tomorrow. Only one of them will get remembered.

That's the tension I want to talk about, because I think it's the real question hiding under "how do I write a good article" in 2026: not AI or heart — but how you let one serve the other.

Way One: Writing With AI

This is the fast lane, and it's genuinely useful. You bring the idea, the AI helps you:

Breakdown a topic
Draft an outline
Punch up a clunky sentence
Catch the boring paragraph you were too tired to notice
Turn years of scattered learning into one clean explanation

Used well, this isn't cheating. It's what editors have always done for writers — except now everyone has one.

Used badly, though, it produces a very specific kind of article: correct, competent, and completely forgettable. You've read a hundred of them. Perfect grammar. Zero pulse. The kind of post you skim, nod at, and never think about again. The tell is always the same — it sounds like an article about the topic, not like your article about it.

Way Two: Writing With Heart

This is the slow lane. It's you, the actual failure that taught you the lesson, the 2 AM bug that made you want to quit, the moment something finally clicked and you felt like a wizard for ten whole minutes.

Heart-writing isn't about being emotional for its own sake. It's about specificity. It's the difference between:

"Debugging can be frustrating but rewarding."

and:

"I spent three hours debugging our API, convinced the logic was broken. It wasn't. I'd written a nested loop with i and j as counters, and with my eyesight, on a bad-contrast monitor, they were nearly indistinguishable — I kept reading i where I'd written j, and my brain corrected it every single time without telling me. It took a junior dev, glancing over my shoulder for thirty seconds, to spot it. I went home and renamed many variable I owned that night..based on True story😊"

The second one isn't better because it's more honest in some abstract moral sense. It's better because it's true in a way nobody else could have written. That's the whole game. AI can simulate insight. It cannot simulate the specific, embarrassing, real thing that happened to you.

The cost of this path is that it's slower, scarier, and occasionally humbling — because writing with heart means admitting you didn't always know what you were doing.

The Real Answer: They're Not Two Roads. They're Two Hands.

Here's what actually works, and it's the framework underneath most articles you've bookmarked without noticing:

1. Start with the true thing only you have.
Not a topic. A moment. The bug, the mistake, the surprising result, the question a junior dev asked you that you couldn't answer cleanly. This is the part AI cannot do for you, because it doesn't have your Tuesday.

2. Let AI hold the structure while you hold the story.
Once you know what happened, structure is a solved problem — and this is where AI genuinely shines. Ask it to help you outline, to suggest where the piece drags, to find the sentence buried on paragraph nine that should actually be your opening line. Let it be your scaffolding, not your voice.

3. Write the ugly first draft yourself.
Even three rough paragraphs. Even bad ones. This is non-negotiable, and here's why: your voice lives in your word choices under pressure — the slightly weird metaphor, the joke that only makes sense if you know you, the rhythm of how you explain things when you're not trying to sound impressive. AI can polish that voice. It can't originate it from nothing.

4. Use AI as your harshest kind editor, not your ghostwriter.
"Where does this get boring?" "What's the weakest paragraph?" "Is my opening line actually earning the reader's next thirty seconds?" These are incredible questions to ask a model. "Write my article for me" is not — because you'll get back competence with the fingerprints sanded off.

5. Read it out loud before you publish.
This one has nothing to do with AI. It's the oldest trick there is, and it still catches everything: the sentence that's too long, the paragraph that doesn't mean anything, the ending that fizzles instead of lands. If you'd feel embarrassed saying a sentence to a friend, don't publish it.

Why This Actually Matters

Here's the thing nobody tells you about writing on dev.to or Medium in 2026: readers have gotten very good at smelling the difference between a piece written through someone and a piece written by something. Not because AI writing is bad — it isn't — but because readers aren't actually looking for information anymore. They can get information anywhere, instantly, for free. What they're looking for, every time they click on an article instead of asking a chatbot directly, is you. Your particular scar tissue. Your particular way of seeing a problem. The proof that a real person went through something and came back with a flashlight for the rest of us.

That's not a nostalgic argument for doing things the hard way. It's a practical one: the articles that get saved, shared, and remembered are the ones where a real experience got a little help getting dressed for the world — not the ones where an experience was replaced entirely.

So, Start Tonight

Don't open with a prompt. Open with a memory — the bug, the launch that went sideways, the comment on your PR that stung more than it should have, the tiny win nobody else would understand the weight of.

Write that part yourself, badly, honestly.

Then bring in the help.

That's not two ways to write an article in 2026. That's one way, done right — with both hands.

Reinvention Is a Practice: Staying Open to What Comes Next

Thu, 06 Aug 2026 12:17:46 +0000

Lately, I have been thinking about change.

Not the dramatic kind where you wake up one morning, abandon your entire life and announce a new identity to the world. Rather, the gradual process of recognising that a version of you has served its purpose, and that it may be time to become someone slightly different.

When I look back at my life, I can see several versions of myself.

There was the young developer learning how to code, spending long hours trying to understand why things worked the way they did. There was the engineer wrestling with Docker until containers, networks and deployment pipelines finally stopped feeling like dark magic. There was the blockchain developer learning an entirely new ecosystem during the NFT wave. Now there is the engineer and business owner trying to understand what it means to build in the age of AI.

Each version required something different from me.

New skills. New habits. New ways of thinking.

More importantly, each one required me to accept that what had brought me this far might not be enough to carry me forward.

That is perhaps the most uncomfortable part of reinvention.

The Humility of Becoming a Beginner Again

There is a particular kind of discomfort that comes with learning something new.

You go from feeling competent to feeling completely lost. Concepts that other people discuss casually sound foreign. Simple tasks take hours. Progress is difficult to measure, and there are moments when you wonder whether the effort is worth it.

I remember the long hours I spent learning Docker.

At the time, it did not feel like some grand career investment. It mostly felt like confusion, poorly written configuration files and an unreasonable number of browser tabs. There were evenings when I understood less at the end than I thought I had understood at the beginning.

Eventually, things clicked.

That knowledge helped me thrive in later roles. It made me more useful during infrastructure changes and better equipped to understand the systems around the software I was building. It gave me the confidence to move beyond writing code and think more deeply about how software is deployed, operated and maintained.

The effort repaid itself many times over.

That has been true of most valuable things I have learned. The rewards rarely arrive at the same time as the discomfort. At first, you only experience the cost. The late nights, the confusion and the repeated failures are immediate. The benefits reveal themselves later, often in situations you could not have predicted.

Knowledge compounds quietly.

One skill makes the next one easier to learn. A difficult project gives you pattern recognition for the next challenge. A season of confusion becomes the foundation for decisions that later appear instinctive.

From the outside, that can look like talent.

From the inside, it feels more like accumulated struggle.

Learning to Move With the World

Technology has given me little choice but to become comfortable with change.

When blockchain and NFTs became a major frontier, I had to learn how that world worked. It meant understanding new tools, architectures and assumptions about ownership, payments and digital assets.

That wave eventually cooled, as waves tend to do.

But the knowledge did not disappear with the hype. The experience broadened how I understood financial systems and emerging technology. It also taught me something more important: I could enter an unfamiliar space, endure the confusion and eventually become competent within it.

Now we are in the AI era, and I find myself adapting again.

The tools are changing quickly. The way software is written is changing. Work that once took days can sometimes be completed in hours, but that speed introduces new questions around judgment, quality and responsibility.

I could resist it. I could insist that the methods that worked for me before should continue working forever.

But the world is under no obligation to preserve the conditions under which I became successful.

Standing still does not protect you from change. It only removes your ability to influence how change affects you.

I have noticed that some of my older and more successful colleagues are remarkably open to new ideas. They do not respond to every development with insecurity or dismissal. They ask questions. They test things. They are willing to admit that someone younger or less experienced may understand an emerging field better than they do.

That openness seems to be a common thread among many of the successful people I know.

They do not confuse experience with completion.

Being good at something today does not exempt you from learning tomorrow.

Firing Myself From the Work I Know

Running a business has introduced a different kind of reinvention.

As a developer, my instinct is to solve problems by building things. When something needs to be fixed, I want to open my laptop, inspect the code and handle it myself. Coding is familiar. It gives me a sense of control and the satisfaction of knowing that I can personally move something forward.

But a business cannot grow around the founder’s need to remain involved in everything.

Someone once advised me to fire myself every day.

The first time I heard it, it sounded slightly aggressive. Over time, I began to understand the wisdom in it.

The goal is not to make yourself useless. It is to stop being the permanent bottleneck.

Every time I build a system, document a process, delegate responsibility or allow someone else to take ownership, I am firing myself from a role the business should no longer depend on me to perform.

That sounds simple in theory. In practice, it can be deeply uncomfortable.

It is difficult to release work you know you can do well. Delegation requires trust. It requires patience when someone approaches a problem differently from how you would. Sometimes it means accepting that another person may eventually become better at that work than you are.

Holding on to every task also comes at a cost.

The more time I spend coding every feature, reviewing every small decision and solving every immediate problem, the less time I have to think about where the business is going.

My role has to evolve.

I have to think about strategy, partnerships, positioning, sales and the kind of company we are trying to become. These responsibilities do not always offer the immediate satisfaction of shipping a feature, but they are increasingly where I can create the most value.

Growth sometimes requires leaving behind the work that once made you feel valuable.

That is its own form of reinvention.

Letting Go Outside of Work

Change is not only necessary in careers and businesses.

Sometimes the habits that need to be reconsidered are personal.

There was a time when almost every weekend needed to involve going out. There was always somewhere to be, someone to meet or another loud room to enter. It was fun, until parts of it stopped being fun and continued mostly because that was what weekends had come to mean.

Lately, I have been embracing a quieter life.

For now, at least.

I am learning to enjoy my own company without treating solitude as an empty space that needs to be filled. I am becoming more intentional about how I spend my time and which habits genuinely leave me feeling restored.

This has not meant withdrawing from life. In some ways, it has created space for different experiences.

During a recent solo trip to Diani, I decided to try kitesurfing.

There is something humbling about picking up a new sport as an adult. You do not have the luxury of pretending to be naturally competent. The wind does not care about your career, confidence or carefully constructed sense of dignity. You fall, struggle, get up and try again.

I enjoyed it.

Not because I was immediately good at it, but because I was not.

It reminded me of the pleasure of entering an experience without needing to perform expertise. Of allowing curiosity, rather than competence, to lead.

I would like to become better at it over time. Not urgently, and not because every hobby must become a measurable achievement. Simply because there is something meaningful about giving yourself new worlds to grow into.

Discomfort Is Not Always a Warning

We often interpret discomfort as evidence that something is wrong.

Sometimes it is. There are situations, relationships and environments that should be left rather than endured.

But discomfort can also mean that an old identity is being stretched.

Learning exposes what we do not know. Delegation reduces our control. A quieter life feels unfamiliar when we have grown accustomed to noise. Starting a new sport reminds us that adulthood offers few opportunities to be visibly bad at something.

The instinct is often to retreat into what is familiar.

Familiarity, however, can become a very comfortable cage.

Some of the most meaningful changes in my life began with periods I would not have chosen for myself. They required uncertainty, patience and the temporary loss of confidence that comes with moving beyond what you already understand.

Looking back, I do not regret the discomfort.

I regret some of the moments when fear made me delay it.

A Letter to the Version of Me Who Feels Stuck

Perhaps this is partly a letter to myself.

A reminder to return to when motivation is low, the future feels uncertain or the work of becoming someone new feels heavier than remaining where I am.

I want to remember that I have done this before.

I learned to code when I did not know how.

I learned infrastructure when the concepts felt impossibly complicated.

I entered blockchain when the ecosystem was unfamiliar.

I am learning to build differently in the age of AI.

I am learning to lead a business rather than simply work inside one.

I am learning to release habits, roles and versions of myself that no longer serve the person I am trying to become.

None of those transitions has been perfectly planned.

Most began with a mixture of curiosity, necessity and discomfort. The confidence usually arrived after I started, not before.

That may be the lesson worth keeping.

You do not need to feel fully prepared for the next version of your life. You only need enough humility to admit that change is necessary and enough courage to take the next step.

Reinvention does not always require a dramatic announcement.

Sometimes it is learning a new tool after work.

Sometimes it is trusting someone else with a responsibility you once carried alone.

Sometimes it is declining another loud weekend and choosing rest.

Sometimes it is standing on a beach in Diani, attached to a kite, being dragged through the water while discovering that you are still capable of surprising yourself.

The world will continue changing.

So will the work.

So will the people around us.

The question is not whether change will arrive. It is whether we will remain open enough to move with it.

I hope I do.

I hope I remain curious enough to explore new frontiers, disciplined enough to endure the uncomfortable parts and humble enough to become a beginner as many times as life requires.

Because perhaps reinvention is not about becoming an entirely different person.

Perhaps it is about refusing to believe that the person you are today is the only person you are capable of becoming.

Fast learning is overrated.

Tue, 19 May 2026 05:16:41 +0000

Because learning is rarely a linear process

It is more like layering.

The more we revisit a topic, the more it sinks in.

The first time we learn something, it’s just an introduction.
The second time, patterns start becoming visible.
The third or fourth time, clarity begins to emerge.

And after enough repetition, it becomes an understanding.

It is how the brain builds depth.

This is true for almost everything:

technology,
communication,
music,
sports,
or even teaching itself.

Every revision adds another layer of understanding.

That is why good learners are not necessarily the fastest learners.

Often, they are simply the ones who are willing to come back to the same concept again and again without getting bored or embarrassed.

Another Year Older, Another Year of Building, Learning, and Growing

Wed, 13 May 2026 14:44:02 +0000

Today is my birthday.

And honestly, birthdays make me reflect more than celebrate.

Not just about age, but about growth, experiences, failures, lessons, relationships, opportunities, and the journey that brought me here.

If there’s one thing tech has taught me, it’s this:

Growth is rarely loud in the beginning.

Most times, it starts quietly.

One small curiosity.
One late night experiment.
One failed project.
One confusing error.
One moment where you almost give up.
Then slowly… years later… you realize those small moments shaped your entire life.

Looking back, I still remember being that curious student experimenting with computers long before I fully understood programming.

I remember writing HTML code inside notebooks by hand.

I remember being denied access to systems because I was “too experimental.”

I remember learning with limited resources but unlimited curiosity.

I remember the excitement of seeing my first webpage work.

I remember the frustration of debugging for hours.

I remember the moments I questioned myself.

And I also remember the moments where things finally started making sense.

Over the years, the journey evolved from curiosity into purpose.

From simple experiments into real projects.

From learning alone into helping others.

From building for fun into building solutions for people and businesses.

And through all of this, one thing has remained constant:

I’m still learning.

That’s one thing I love about technology.

No matter how much you know, there’s always something new to discover.

Another problem to solve.
Another system to build.
Another lesson to learn.

I also want to appreciate communities like CoderLegion and the developers I’ve interacted with here.

One thing I’ve realized is that growth becomes easier when you’re surrounded by people who are also building, learning, struggling, experimenting, and improving themselves daily.

Tech can sometimes feel isolating, but communities remind us that none of us are growing alone.

To every developer still learning, still struggling, still doubting themselves sometimes:

Keep going.

Your current level is not your final level.

The small things you’re learning today may become the foundation of something much bigger tomorrow.

And to everyone who has supported, encouraged, collaborated, taught, corrected, or inspired me at any stage of my journey:

Thank you.

I genuinely appreciate it.

This new year for me is not just about getting older.

It’s about becoming better.
Building more.
Learning more.
Helping more people.
Taking bigger steps.
Creating more impact.
And continuing the journey with gratitude.

Cheers to another year of growth, consistency, lessons, innovation, and building.

Happy Birthday to me.

Why CoderLegion Turned Into a Community I Didn’t Expect

Mon, 11 May 2026 11:44:21 +0000

When most developers hear about a new tech platform or developer community, the first thought is usually:

“Is this just another place to post articles?”

Honestly, that was one of my first thoughts too.

Over time, I realized CoderLegion was becoming something different.

Not perfect.

Not magical overnight.

But a platform genuinely trying to build a real developer focused community where people can learn, interact, grow, and actually feel seen.

And for me personally, the experience has been surprisingly meaningful.

How I Found CoderLegion

At the time I discovered CoderLegion, I was already deep into development work, learning continuously, building projects, experimenting with technologies, and trying to improve myself technically.

Like many developers, I also enjoyed sharing ideas, reading technical experiences, and seeing how other developers approached problems.

One thing I noticed across many platforms was this:

A lot of places focus heavily on content quantity.

Very few focus on community.

Many platforms become places where people just drop links, chase views, or try to game algorithms without real interaction.

When I started spending time on CoderLegion, one thing immediately stood out:

The platform actually encouraged interaction.

Not just publishing.

Real interaction.

Reading people’s experiences.

Learning from mistakes.

Discussing ideas.

Supporting developers.

And slowly, I became more active.

The Human Side of Developer Communities

One thing many people underestimate is how important community is in tech.

Programming can become isolating.

Sometimes you’re learning alone.

Debugging alone.

Building alone.

Questioning yourself alone.

You may spend hours solving problems nobody around you even understands.

That’s why communities matter.

Not because they magically make you successful.

But because they remind you that other developers are also struggling, learning, experimenting, failing, improving, and growing.

CoderLegion gave me more of that feeling than I expected.

It started feeling less like “posting content” and more like interacting with actual people in tech.

The Difference I Noticed

One thing I appreciated was seeing the platform continuously evolve.

I remember interacting on a few posts and genuinely getting thoughtful responses from both contributors and community members instead of the usual “drop a link and disappear” experience common on many platforms.

Over time, I also noticed visible improvements around discussions, contributor visibility, and engagement across the platform.

One thing that stood out to me personally was eventually being added to the early contributors section. It may seem small, but moments like that make contributors feel seen, especially smaller creators who are still growing.

That kind of encouragement matters more than many people realize.

A lot of platforms only notice creators after they become big.

But I noticed that CoderLegion tried to support early contributors and active community members even while still growing.

That creates motivation.

Of course, the platform is still growing, and because of that, some areas are not yet as polished or mature as larger developer platforms like DEV.to or Hashnode.

Discovery and reach can still improve over time.

But honestly, that growth phase is also part of what currently makes the community feel more personal and approachable.

Not because of fame.

But because people naturally appreciate being valued.

Why Genuine Interaction Matters

One thing I personally respect is the push toward authentic engagement.

Today, AI generated comments are everywhere online.

You can immediately tell when someone didn’t actually read a post.

Generic comments are becoming extremely common across many platforms.

What I appreciated was that genuine interaction still seemed more noticeable than purely automated engagement.

You could often tell when someone actually read your post and responded thoughtfully instead of dropping generic AI-generated comments just to appear active.

Because honestly, meaningful communities are built through genuine interaction.

Not automated responses.

Sometimes a simple thoughtful comment can help another developer more than people realize.

Especially beginners.

A beginner developer reading encouragement from someone experienced can gain confidence from something very small.

That matters.

My Experience as a Contributor

As I became more active, I started interacting more with posts, discussions, and developers on the platform.

Over time, I was added to the early contributors section, which honestly felt encouraging because it showed the platform recognized people trying to contribute positively.

That encouragement matters more than many people think.

Especially for developers who are still building confidence in public writing, community interaction, or sharing their journeys.

Another thing I appreciated was that the platform didn’t only focus on “perfect developers.”

It allowed room for learning journeys.

That’s important.

Because tech is already intimidating enough for beginners.

Communities should help reduce that fear, not increase it.

Sharing My Story Publicly

Many developers think their stories are “too ordinary” to matter.

Meanwhile, those same stories can inspire someone else to start learning.

People often only see the final results.

They see projects.

Skills.

Achievements.

But they don’t see the years behind them.

The confusion.

The failures.

The learning process.

The consistency.

That’s why I appreciated the idea behind the Dev Stories initiative.

It reminds people that growth in tech is a process.

Not magic.

What I’ve Learned Through Communities

One thing I’ve learned from platforms like CoderLegion is this:

Growth in tech is not only technical.

Community also matters.

Communication matters.

Sharing matters.

Helping others matters.

You may know how to build systems, APIs, mobile apps, servers, or automation workflows…

But interacting with people, learning from others, sharing experiences, and contributing to discussions also helps you grow professionally.

Sometimes opportunities even come from simple conversations.

Advice to Developers Joining Communities

If you’re joining developer communities, my advice is simple:

Don’t just consume content silently.

Interact genuinely.

Ask questions.

Share experiences.

Support others.

Leave thoughtful comments after actually reading posts.

And don’t feel pressured to sound perfect.

Authenticity stands out more than trying to sound overly advanced.

Also, don’t underestimate your learning journey.

Even if you still feel like a beginner, there’s someone behind you who can learn from your experience.

What Could Be Better

Like any growing platform, there’s still room for improvement.

Discovery for smaller creators can improve further, and some platform features are still developing compared to larger communities like DEV.to or Hashnode.

I also think continued focus on moderation quality, authentic engagement, and better visibility tools for technical content will help strengthen the community long-term.

But overall, it’s been interesting seeing the platform actively evolve instead of remaining static.

Final Thoughts

For me, CoderLegion became more than just another platform to scroll through.

It became a place where I could interact with developers, share thoughts, learn from others, and contribute to discussions in a more genuine way.

And honestly, communities like that are important in tech.

Because beyond the frameworks, languages, servers, APIs, and projects…

Developers still need spaces where they can learn, grow, share experiences, and simply feel connected to other people going through similar journeys.

And honestly, that’s what made the experience meaningful for me.

From a “Notorious” Student to Building Real Projects, My Journey Into Tech

Sun, 10 May 2026 07:33:19 +0000

A lot of people see developers today and assume they became good overnight.

What many people don’t see are the years of curiosity, failed experiments, sleepless nights, self learning, pressure, consistency, and the small moments that completely changed someone’s life.

For me, my journey into tech started during secondary school (high school), and honestly, I never imagined it would shape my future this much.

How It All Started

I had just entered JSS1 during my second term in school.

One particular day, we had just finished a Biology class and were preparing for the next subject: Computer Science.

At that time, I was honestly one of those nonchalant students when it came to classes. I would attend, but my mind was usually somewhere else.

But one thing about me was that I already loved computers, phones, gadgets, and technology generally, even though I had very limited access to them.

Interestingly, within the school, I became known for being “that student” who somehow knew how to handle computer related problems.

The funny part was that because I was too curious and always trying things around systems, I was considered a bit “notorious” whenever I handled staff computers. Because of that, my access to computers was often restricted.

But despite that, I was still respected.

I became the person people called whenever they felt all hope was lost on a system issue.

90% of the time, I fixed the problem.

The remaining 10%, even if I couldn’t solve it directly, I would still help find a possible solution.

I didn’t realize it then, but problem solving was already becoming part of me.

The Class That Changed Everything

That particular Computer Science class changed my life completely.

Back then, most of the systems still used Microsoft Office 2007, and our teacher was teaching us about how programs were made. Visual Basic (VB) was being introduced.

Then somewhere during the teaching, he slightly diverted from the main topic and started talking about websites.

He mentioned companies like Facebook and Google and explained that websites were built using code.

Then he wrote some lines of code on the board.

At that time, I had no idea it was HTML.

He asked us to open Notepad, type the code exactly as written, save the file with a .html extension, and open it in the browser.

I still remember the feeling.

I was amazed.

Completely amazed.

Seeing plain text suddenly turn into an actual webpage felt almost magical to me.

Immediately, I stopped being nonchalant.

While others focused only on passing the class, I became obsessed with experimenting.

I started changing texts inside the code to see what would happen.

Every little change produced a different result.

That moment triggered something in me.

Even after the teacher returned to the original topic, my mind was no longer there.

I was already recreating and experimenting with what I had just seen.

That was the moment my curiosity became serious interest.

The First Rejection That Motivated Me

After the class, I walked up to my teacher and asked for guidance because I wanted to learn more.

Based on my reputation for being “too experimental” around computers, he initially refused.

Honestly, I understood why.

But I kept asking consistently.

Eventually, he gave me a book:

“HTML for Dummies.”

He told me:

“If you finish this book, I’ll allow you to use the computer lab to practice.”

To him, maybe it was just a test.

To me, it became a mission.

Learning HTML by Writing Code in Notebooks

About one month and some weeks later, I returned.

Not only had I finished the book, but I also came back with three full notebooks containing HTML code I had written completely by hand.

At that point, I still didn’t know CSS yet.

I was simply recreating webpages manually and trying to understand how everything worked.

Eventually, I was introduced to CSS.

That changed everything again.

Suddenly, I could style my pages, improve layouts, add colors, structure designs properly, and make my code look cleaner and more organized.

I was genuinely happy while learning.

I could literally spend hours experimenting without getting tired.

And for the first time, I started feeling like I had found something I truly enjoyed doing.

My First Real School Project

As I continued learning, I became part of my school’s editorial team.

That opportunity pushed me beyond simple practice.

I created a portal that stored details of graduating students.

I also configured it to work across systems on the school’s local network so multiple computers could access the portal.

Looking back now, it sounds simple.

But at that age and level, it felt huge to me.

That was one of the moments I realized software could solve real problems.

Around that same period, I was introduced to JavaScript.

JavaScript expanded my thinking completely.

At one point, I even used Excel as a database while experimenting with JavaScript based solutions.

I kept practicing constantly.

Every day, I discovered something new.

Discovering PHP and Going Deeper Into Development

As I improved, someone introduced me to PHP and explained how powerful it was for backend development.

I became curious immediately.

I went online, searched for tutorials, downloaded resources, and started learning it myself.

A few weeks later, I started writing PHP applications.

That was when I began understanding how websites truly worked behind the scenes.

Frontend development had already impressed me.

But backend development made me fall even deeper in love with programming.

At that point, coding was no longer just curiosity.

It became part of my life.

Transitioning Into Android Development

Later, I moved into Android development.

This part of my journey became easier because I had mentors who guided me properly.

One important thing I learned during that phase was the importance of focus and consistency.

Tech can easily overwhelm you because there’s always something new to learn.

But learning how to focus on one path at a time helped me grow faster.

From there, I continued evolving.

Over the years, I’ve built multiple projects for personal use, commercial purposes, and clients.

I’ve worked on backend systems, APIs, mobile applications, automation projects, networking related solutions, hardware integrated projects, and much more.

And honestly, I’m still learning every single day.

What My Learning Journey Has Taught Me

One thing I’ve learned is this:

You do not need to know everything before starting.

Most beginners think developers are special people who magically understand code immediately.

That’s not true.

A lot of us started from confusion.

We searched endlessly online.

We broke things.

We failed repeatedly.

We rewrote code multiple times.

We stayed awake trying to solve one tiny bug.

Growth in tech is mostly consistency.

Not perfection.

The Hardest Part of the Journey

The hardest part for me wasn’t learning syntax.

It was handling limited resources, lack of guidance sometimes, and trying to stay consistent during difficult periods.

There were moments where things felt confusing.

Moments where projects failed.

Moments where I questioned myself.

But consistency helped me survive those periods.

Another major challenge was information overload.

There are countless technologies, frameworks, tutorials, and opinions online.

At some point, I realized the best strategy was to focus on building instead of endlessly consuming tutorials.

Projects teach faster than theory alone.

What I Enjoy Most About Coding

What I enjoy most is problem solving.

I love the process of turning ideas into working systems.

I enjoy seeing something move from imagination into reality.

There’s also a different kind of satisfaction that comes from helping people solve real problems using technology.

Sometimes the solution looks simple from the outside, but behind it are hours or days of thinking, testing, debugging, and improving.

That process is something I genuinely enjoy.

My Goals for the Future

My goals are still growing, but one thing is clear:

I want to continue building impactful solutions.

I want to create systems, platforms, tools, and products that solve real world problems.

I also want to contribute more to the developer community through sharing knowledge, writing, mentoring, and helping upcoming developers avoid some of the mistakes I made while learning.

Long term, I want to build technology that creates real impact both locally and globally.

Advice to Beginners

If you’re just starting your journey into tech, this is what I would tell you:

Don’t compare your beginning to someone else’s middle.
Start with whatever device or resources you currently have.
Build projects, even small ones.
Stay curious.
Stay consistent.
Don’t fear mistakes or debugging.
Learn by doing, not just watching tutorials.

And most importantly:

Nobody becomes a good developer overnight.

Every experienced developer you admire today once struggled with the basics too.

The difference is that they kept going.

And that consistency changes everything.

It’s a New Month, My Birthday Month — And a New Level as a Developer

Sat, 02 May 2026 06:21:55 +0000

The Problem → We Celebrate Growth, But Rarely Reflect on It

A new month starts.

Most of us set goals:

Learn a new framework
Build a new project
Improve our skills

But here’s the truth:

We rarely stop to ask:

“Have I actually grown?”

As developers, we’re always chasing the next thing:

New tech
New tools
New opportunities

But growth isn’t just about what you’re chasing.
It’s about what you’ve become.

The Solution → Use Moments Like This to Reset and Realign

It’s May 2026.

For me, it’s more than just another month.

It’s my birthday month and honestly, that hits different.

Not just because of age…
But because of perspective.

Looking Back as a Developer

If I think about where I was vs now:

I used to focus only on writing code
Now I think about systems, performance, and scale
I used to rush features
Now I understand trade offs (clean code vs shipping fast)
I used to trust code “because it works”
Now I question everything (especially AI generated code)

Note: Growth as a developer is not loud. It shows up in how you think, not just what you build.

What This New Month Means for Me

This month is not about:

Starting from scratch
Chasing everything at once

It’s about:

Being more intentional
Building better systems
Becoming sharper in decision making

Because at some point, you realize:

It’s not about doing more…
It’s about doing the right things consistently.

Lessons I’m Carrying Into This New Year

1. Speed Without Direction Is Useless

Shipping fast is good.

But shipping blindly?
That’s how bugs reach production.

2. Simplicity Is a Superpower

The best solutions I’ve built weren’t the most complex.

They were:

Clear
Maintainable
Scalable

3. You Don’t Know As Much As You Think (And That’s Okay)

Tech evolves.

AI is changing workflows.

New problems keep coming.

The goal is not to know everything
It’s to stay adaptable.

Tip: Focus less on mastering tools, and more on mastering how you think about problems.

To Every Developer Reading This

Whether you’re:

Just starting out
Mid level
Or already experienced

Take a moment this month and ask yourself:

What did I learn recently?
What mistakes made me better?
What kind of developer am I becoming?

FAQ Do developers really need to reflect on their growth?
Yes. Reflection helps you identify patterns, improve decision making, and avoid repeating mistakes.

What should I focus on this new month as a developer?
Focus on consistency, improving problem solving skills, and building real world projects.

Is it okay to feel stuck sometimes?
Absolutely. Every developer experiences this. Growth often happens after those phases.

Final Thoughts

This month feels different.

Not because everything has changed
But because I have changed.

And that’s what matters.

To more growth.
To better systems.
To smarter decisions.

And to becoming the kind of developer I used to look up to.

Call to Action

If this resonated with you:

Share it with a developer who needs a reset this month
Bookmark it and come back at the end of May
And ask yourself:

Did I grow… or did I just stay busy?

Effortlessness Is a Myth

Tue, 28 Apr 2026 17:19:21 +0000

I was listening to an episode of Founders where they discussed Roger Federer and one line stayed with me:

Effortlessness is a myth.
Perfection is a myth.

That landed hard.

From the outside, we often look at people at the top of their game and assume things come naturally to them. We see the clean outcome, not the private repetitions behind it.

I know this because I have lived on both sides of that story.

People have told me, more times than I can count, that things seem to come easy for me.

What they do not see is the accumulation.

The Performance of Ease

What looks like ease is usually compression.

Years of work get compressed into one moment:

a clear decision in a meeting
a confident architecture call
a polished delivery
a calm response under pressure

The moment looks smooth because the friction happened earlier.

Most of it happened quietly.

Late nights learning.
Dead ends.
Repetition.
Starting over.
Doing it again.

That is not talent theatre.
That is practice.

"Gifted" Still Requires Work

I grew up being labelled the "gifted kid."

Even then, results did not come from magic. They came from hours of tuition, prep, and repetition. The grades were visible. The routine that produced them was not.

That pattern followed me into adulthood.

I now spend a significant amount of time learning and upskilling. Not because it is trendy, but because the world keeps moving and standing still is expensive.

People often confuse consistency with natural ability.

It is usually trained behaviour.

Adaptation Is Not Optional

Across my career, I have had to relearn how to work multiple times.

I had to learn blockchain and ride the NFT wave when that became relevant to the market.
I had to learn Docker and Kubernetes during a major company migration when the stakes were real.
Now I am actively learning AI, not as a spectator, but as part of how modern engineering work is done.

None of those transitions felt effortless in real time.

Each one came with discomfort:

context switching
imposter moments
retooling mental models
accepting beginner status again

But adaptation compounds the same way technical debt does.
Ignore it long enough and you pay with interest.

The Magazine Questions Forced Clarity

I was recently filling out answers for a magazine feature, and the process forced me to reflect on a lot of this.

When you have to explain your path clearly - how you learned, where you failed, what you had to relearn, what shaped your discipline - you realise how much of growth is invisible from the outside.

You also realise how much consistency has quietly shaped your identity.

Not one dramatic moment.
Not one perfect breakthrough.
Just repeated commitments over a long period of time.

That reflection echoed themes I have written about in Execution Is the Real Differentiator - and the Multiplier and Building Better: Looking Back on 2025.

Effortlessness Is Usually Deferred Effort

I think this is the part people miss.

Effortlessness is often just deferred effort that has already been paid.

When someone makes hard work look natural, what you are usually seeing is:

pattern recognition built over the years
judgment trained through failures
emotional control built through pressure
discipline repeated long after motivation faded

That applies in fitness.
It applies in writing.
It applies in engineering.
It applies in leadership.

I run, I box, and I train early. The sessions that build you are rarely dramatic. They are repetitive, inconvenient, and sometimes boring. But they stack. Eventually, your baseline changes.

The same thing happens intellectually.
You do enough hard reps and what used to feel impossible becomes normal.

In Work, Reliability Beats Brilliance

If there is one lesson I keep relearning, it is this:

Execution builds trust faster than ideas.

Not because ideas do not matter.
They do.

But in professional life, people remember who follows through.

Who shows up.
Who communicates early when things go wrong.
Who does not disappear under pressure.

I have seen this in mentoring, in engineering teams, and in business. Momentum is not built by occasional heroic effort. It is built by repeated follow-through.

What compounds over time is not intensity.

It is reliability.

Why This Matters in the AI Era

This conversation is even more important now.

We are entering a period where visible output can be generated faster than ever. Code, drafts, prototypes, and plans can be produced in minutes.

That can create a dangerous illusion:
that output quality equals underlying capability.

It does not.

The leverage tools are real, but they do not remove the need for:

judgment
depth
constraint thinking
ownership

If anything, they increase the premium on those qualities.

I have explored this more deeply in AI Is Not Replacing You. It's Reshaping How You Think and AI Is Not Your Intern. And That's the Problem..

The people who thrive will not be those who look effortlessly productive online.

They will be those who can sustain disciplined execution over long periods of change.

What I Come Back To

When I reflect on my own path, I do not see effortless progress.

I see repeated adaptation.

I see long preparation phases that nobody claps for.
I see seasons of discomfort that later looked like confidence.
I see compounding from showing up, especially when it would have been easier not to.

So no, effortlessness is not the goal.

Craft is.

And craft is built the old way:
one rep at a time, over a long time, with enough humility to keep learning.

Building Recipe-Finder.org: A Full-Stack Journey with Vue, Express, MongoDB, and Vuetify

Mon, 27 Apr 2026 10:27:23 +0000

Hello, community!

Tired of staring into the fridge wondering what to cook with leftover ingredients, I decided to build my own solution: Recipe-Finder.org. It's a fast, clean way to search for recipes—and I recently packaged it into an Android app, too!

Here is a quick breakdown of the stack, the hurdles, and the links.

️ The Tech Stack (MEVN)
Frontend: Vue.js + Pinia for an approachable learning curve and painless reactive state management.

UI Framework: Vuetify. It provided out-of-the-box Material Design components (cards, drawers, grids) without writing hundreds of lines of custom CSS.

Backend: Express.js. A lightweight router to handle API requests and database communication.

Database: MongoDB. Recipes are inherently document-like (arrays of ingredients/instructions), making NoSQL the perfect flexible fit.

Biggest Challenges & Fixes
Complex Search Queries: Users rarely type exact, sanitized ingredient names. Solution: I leveraged MongoDB's $text search indexes and built an Express aggregation pipeline to score and sort results based on how many ingredients matched.

Responsive UI Consistency: Varying image aspect ratios and title lengths kept breaking my mobile grid. Solution: Vuetify's v-img aspect-ratio props enforced uniformity, CSS line-clamp handled text truncation, and Vuetify's grid (cols="12" sm="6" md="4") ensured graceful scaling.

I Built an Android App!
To make it easier to use right from the kitchen, I also developed and published a mobile version of the app.

Download it on Google Play

Wiki Khan Story

Sat, 25 Apr 2026 06:49:50 +0000

I want to be straightforward about something from the start.

I am not a software engineer. I am an entrepreneur who built a software product because the market needed it and I had spent eight years understanding exactly what that product needed to do.
My name is Wiki Khan. Born Muhammad Waqas, 19 August 2000, Harappa, Punjab, Pakistan. Founder and CEO of WikiHub — a full-scale e-commerce agency and proprietary multichannel seller operating system based in Sahiwal, Punjab, Pakistan.

I grew up in Harappa as the youngest of eight siblings — seven sisters and me as the only son. My father Muhammad Anwar is 82 and in good health, Alhamdulillah. My mother Rehana Anwar raised all eight of us with the kind of quiet dedication that shapes a person permanently whether they realize it at the time or not.

I studied Bio-Medical Sciences for Matriculation in Harappa. Faculty of Science at Government Post Graduate College Sahiwal after moving to the city. Then Advanced Business Strategy at the University of Virginia, Project Management at Oxford Home Study College with Registration Number 760598 and Business English through UPValenciaX on edX with Certificate ID b7f4fc7a98a942009b1c81d0cb00556c.

Then eight years of direct e-commerce work. Co-working spaces in Sahiwal. Enablers. More than 500 clients. Amazon, Shopify, Daraz, Walmart. China to USA supply chains. Brand building, compliance management, logistics, investment advisory. The full operational reality of global e-commerce from inside Pakistan.

The problem I kept seeing was always the same. Fragmentation. Sellers managing too many disconnected tools. Agencies with no technological edge. Data scattered across platforms. Slow decisions on incomplete information.

So I built WikiHub OS.

It is a proprietary operating system built from scratch specifically for multichannel e-commerce sellers. Real-time dashboards across all sales channels simultaneously. Automated workflows and custom scripting. Account health monitoring and compliance automation. Scalability infrastructure that grows with the business.
I am not going to pretend the technical build was simple. It was not. But the eight years of operational experience meant that every feature we built solved a real problem I had personally watched destroy real businesses. That clarity about what the product needed to do made every technical decision easier than it would have been for someone designing from theory.

WikiHub the agency handles everything the OS does not — brand building, business formation, logistics, compliance, investment management. Together they give clients something no competitor can match.
I also run BUY N BRAND LLC in Texas USA and build consumer brands through RIVVA and Rexlay.
My wife Dr. Aysha Saeed runs Life Care Clinic and Maternity Home in Sahiwal — a 24/7 free healthcare facility I fund from my business revenues. Thousands of patients served free. Free medicines. Maternity operations. Anemia treatment. For nearly a decade.

I am a member of the Pakistan E-commerce Association. I build from Sahiwal. I live in Sahiwal. I chose Sahiwal.

If you are building something from a place the world has not noticed yet — keep building. The place does not limit the product. The product limits nothing.

wikihub.net
wikihub.net/founder/
wikidata.org/wiki/Q138719420

Offline AI Integration Isn’t a Feature — It’s the Foundation for Real Systems

Fri, 24 Apr 2026 07:25:51 +0000

Most AI tools today are built on an assumption that nobody really questions anymore:
you are always connected.
Always online.
Always synced.
Always able to call an API.
On paper, that makes sense. It simplifies everything.
But in real-world conditions, especially in places where infrastructure is not stable, that assumption collapses immediately.
And when it collapses, most “AI systems” don’t degrade gracefully.
They just stop working.
The problem isn’t intelligence — it’s continuity
People usually think the limitation of AI is:
reasoning
accuracy
creativity
But that’s not the real bottleneck anymore.
The real problem is something much more basic:
AI systems don’t continue tasks when conditions change.
They don’t:
remember progress properly across interruptions
maintain consistent state in unstable environments
handle partial completion gracefully
recover meaningfully after disconnection
They are built as interaction loops, not execution systems.
And that difference matters more than most people realize.
Most AI tools are “moment-based”, not “process-based”
Right now, most systems work like this:
You send a request
You get a response
The interaction ends
Even when memory exists, it’s usually shallow or context-limited.
But real work doesn’t happen in single moments.
Real work looks like:
starting a task
stopping midway
returning later
continuing from a partial state
adapting when conditions change
Most AI systems are not designed for that reality.
The offline problem exposes everything
Offline or unstable environments don’t just remove connectivity.
They expose design flaws.
When there is no internet, you suddenly need:
local state that actually means something
task continuity without cloud dependency
execution that doesn’t reset every session
systems that can reconcile progress later
And this is where most architectures fail completely.
Not because they are “bad AI systems”
but because they were never designed for persistence in the first place.
This is where I started building differently
I’ve been exploring this gap through a system I’m working on called Pantero.
It’s still early — not a finished product, not a polished system — but more of an experiment in a direction I don’t see handled properly yet.
The direction is simple:
move away from AI as a conversational layer
toward AI as an execution environment
That means focusing less on:
“what should the AI say?”
and more on:
“what should the system continue doing over time?”
Execution matters more than interaction
There’s a shift happening quietly in how people think about AI systems.
The value is moving away from:
generating responses
writing text
answering prompts
and toward:
completing tasks
maintaining workflows
operating across time and constraints
That requires a different kind of architecture entirely.
Not just smarter models — but systems that are:
state-aware
interruption-resilient
context-stable
execution-first by design
Why this gets harder in real environments
In ideal conditions, everything looks simple.
But once you introduce real constraints:
unstable internet
low-resource devices
inconsistent access
interrupted workflows
The system has to do more than “respond well”.
It has to:
survive interruption
resume correctly
avoid losing state
stay meaningful even when degraded
That’s where most current AI systems stop being useful.
What I’m trying to test with Pantero
Instead of treating AI as a chat layer on top of systems, I’m exploring:
how tasks can persist beyond a single session
how context can survive instability
how execution can continue even when connectivity breaks
how learning and building can feel continuous, not fragmented
It’s not fully defined yet.
A lot of it is still unclear, and that’s intentional — because the space itself is still not properly solved.
Why this matters beyond just “AI tools”
This is not just a technical problem.
It directly affects:
how people learn skills
how people build digital work
how people access opportunities in low-resource environments
Because if your tools only work in perfect conditions, then your learning and productivity systems are already biased toward stable environments.
And that gap is still very real.
What I’m looking for
I’m not treating this as a finished idea.
It’s more of a direction I’m actively exploring.
So I’m opening a small waitlist for people who are interested in this kind of thinking:
execution-first AI systems
offline or low-connectivity design
persistent task-based AI
real-world constrained environments
No hype. No finished product.
Just early exploration.
If this resonates
You can join here: https://pantero.vercel.app

Why AI Feels Like a Shortcut (But Isn’t Always)

Tue, 21 Apr 2026 11:06:32 +0000

There’s a moment every developer has experienced recently.

You open your editor, type a prompt into an AI tool, and within seconds…
you get working code.

Not pseudo code. Not an idea.
Actual code.

It feels powerful. It feels fast.
It feels like you just skipped hours of work.

And that’s exactly why it’s dangerous.

Because while AI feels like a shortcut, I’ve learned (sometimes the hard way) that it’s not always one.

The Illusion of Speed

When I first started integrating AI into my workflow especially for backend systems in Laravel and Node.js it felt like a cheat code.

Need a controller? Done.
Need a query optimization? Done.
Need a new feature scaffold? Done.

But after a few real world projects, something became obvious:

AI doesn’t remove the work. It just shifts it.

Instead of writing code from scratch, you’re now:

Reviewing generated code
Debugging unfamiliar logic
Fixing edge cases AI didn’t consider
Aligning it with your architecture

Why AI Feels Like a Shortcut

Let’s be fair AI does accelerate things.

Here’s why it feels like a shortcut:

1. It Eliminates the Blank Page Problem

Starting is usually the hardest part. AI removes that friction instantly.

2. It Handles Repetitive Tasks

Boilerplate, validation, simple CRUD AI thrives here.

3. It Speaks Your Stack

Whether it’s Laravel, Node.js, or APIs, AI understands patterns well enough to generate usable code.

But that’s only half the story.

Where the Shortcut Breaks Down

This is where experience kicks in.

1. AI Doesn’t Know Your System

AI doesn’t understand:

Your business logic
Your domain constraints
Your architectural decisions

So even if the code looks correct, it might be contextually wrong.

I’ve had cases where:

The logic worked… but didn’t match the business requirement
The structure conflicted with existing modules
It introduced subtle bugs that weren’t obvious at first glance

2. You Still Have to Think Like an Engineer

AI can generate code but it doesn’t replace:

System design
Trade off decisions
Performance considerations
Security awareness

If anything, AI demands more thinking, not less.

The better your understanding, the better your prompts and the better your outcomes.

3. Debugging Becomes Harder (If You’re Not Careful)

When you write code yourself, you understand:

Why decisions were made
How the logic flows
Where things might break

With AI generated code?

You’re sometimes debugging something you didn’t fully reason through.

That’s where developers get stuck:: Not because AI failed but because they trusted it blindly.

4. It Can Encourage Shallow Learning

This is the part I’m very honest about.

If you rely on AI too much:

You stop thinking deeply
You skip fundamentals
You lose the ability to build from scratch

And that’s risky.

Because at some point, you’ll face a problem AI can’t solve cleanly and that’s when your real skill is tested.

The Real Way to Use AI (From My Experience)

AI is not the problem.
How we use it is.

Here’s how I approach it now:

1. Use AI as an Accelerator, Not a Replacement

I let AI:

Generate scaffolding
Suggest patterns
Speed up repetitive work

But I still:

Review everything
Adjust logic
Ensure alignment with my system

2. Always Review Like It’s Untrusted Code

This mindset changed everything for me.

Every AI output is:

Verified
Tested
Questioned

3. Understand Before You Accept

If I can’t explain the code in simple terms, I don’t ship it.

Simple rule:

If you don’t understand it, you don’t own it.

4. Combine AI with Strong Fundamentals

AI amplifies what you already know.

If you’re solid → AI makes you faster
If you’re shaky → AI exposes it

Tip: The difference is experience.

AI in Laravel & Node.js: Real Context

In my backend workflow:

Laravel:

AI helps me:

Scaffold controllers and services
Suggest validation rules
Speed up migrations

But I still:

Structure my services manually
Handle business logic intentionally

Node.js:

AI helps with:

API handlers
Middleware patterns
Async logic suggestions

But I still:

Control architecture
Manage performance
Design flows

So… Is AI a Shortcut or Not?

Here’s the honest answer:

AI is a shortcut for effort but not for responsibility.

It saves time writing code.
But it doesn’t save time thinking.

And if you skip that thinking?

You’ll pay for it later in bugs, refactors, and confusion.

Final Thoughts (From Me to You)

As developers, we’re entering a new phase.

AI is part of our workflow now.
There’s no going back.

But the goal isn’t to:

Use AI blindly
Replace your thinking
Chase speed at all costs

The goal is to:

Build smarter
Move faster with control
Stay sharp as an engineer

Because at the end of the day:

AI doesn’t make you a better developer.
How you use it does.

Call to Action

If this resonated with you:

Share it with another developer navigating AI
Reflect on how you currently use AI in your workflow
Ask yourself: Am I thinking… or just accepting?

And I’d love to hear from you:

Has AI ever made your work faster but your debugging harder?

Let’s talk.

Is it Me or the AI? How I almost lost my ability to think.

Sat, 18 Apr 2026 10:16:54 +0000

From big ideas to daily plans, I realized I was seeking AI validation for literally everything.

I’ve noticed something lately, and honestly, it’s a bit scary.

AI has become more than just a tool for me; it’s become a "mentor" I never asked for. Whether it’s a big startup idea, a random thought, or even a small daily plan—I find myself running to ChatGPT for validation. It’s reached a point where my own decision-making power feels paralyzed. I can’t even plan my day without asking, "Is this okay?"
The Wake-Up Call

It hit me about 9 days ago. My internet went down because I forgot to recharge my plan. It was late at night, shops were closed, and I was stuck in a complete digital blackout.

I was trying to brainstorm some ideas, but I realized something weird: I couldn't remember my previous thoughts. Usually, you remember your brainstorms, right? But I didn't. Why? Because I had outsourced that memory to AI. The moment I shared an idea with the bot, my brain stopped "owning" it.

I decided to test this. For a few days, I shared some ideas with my brother and some with AI. The result? The stuff I discussed with my brother felt vague, but the stuff I spent time detailing with the AI stayed in my head longer—only because I was spending hours obsessed with the AI’s response.

The "Approval" Trap

The real "Oh s**t" moment happened during my workout. I’ve been training for 6+ months now, so I know my body. I designed a new bodyweight routine and shared it with my brother. He liked it and started training immediately.

But me? Even though I created the plan, I couldn't start until I asked the AI if it was "correct."

Think about that: My brother was getting fit using my plan, while I was sitting there waiting for an AI's "thumbs up." I had lost faith in my own expertise.

It gets worse. I started asking the AI what I should study next. How would it know? It doesn't know my IQ, my grasping power, or my mood. My spelling was getting worse because of auto-correct, and my confidence was tanking. I realized I had handed over the "remote control" of my life to an algorithm. I was acting like a kid, and the AI was my teacher.

Some might say, "Relax, it’s just a tool, it’s normal." And sure, to an extent, it is. But when you start sharing family matters, personal frustrations, or every tiny decision, it’s no longer a tool. It’s a crutch.

I’m taking my decision-making power back.

What about you guys? Have you ever felt like you're losing your "gut feeling" because you're too busy prompting an AI?

Your Personal Website Is Underperforming — And It's Not a Code Problem

Tue, 14 Apr 2026 18:13:40 +0000

Let's get something out of the way first.

If you're a developer reading this, your personal website is probably technically solid. Clean code, fast load times, good Lighthouse scores, maybe even a slick custom animation or two. The stack is fine. The deployment pipeline is fine.

But if it's not generating real opportunities — job offers, freelance inquiries, collaboration requests, speaking invitations — the problem almost certainly isn't technical.

It's architectural. And not the kind of architecture you're used to thinking about.

The Real Stack Problem

Most developer personal sites are built in this order:

Pick an interesting tech stack (Next.js, Astro, SvelteKit,
whatever's trending)
Build something technically impressive
Add content as an afterthought
Wonder why nobody reaches out

The irony is brutal. Developers who can build anything often end up with websites that communicate the least — because the energy goes into implementation, not into the clarity layer that actually converts visitors into opportunities.

Here's the mental model shift: your personal website is not a technical project. It is a communication system that happens to be built with code.

What the Clarity Layer Actually Looks Like

A high-converting personal website — regardless of stack — answers three questions in the first ten seconds:

WHO: Who is this person and what do they specialize in?
WHAT: What outcomes do they create?
NEXT: What should I do right now?

That's it. That's the whole homepage job in pseudo-code.

Most developer sites fail the WHO and NEXT checks immediately. The identity statement is either too vague ("full-stack developer passionate about building things") or buried below a massive hero animation that looks great but communicates nothing. And the CTA? Usually either missing entirely or lost somewhere at the bottom after three scrolls of project thumbnails.

Proof Architecture for Developers

Here's where it gets interesting from a systems perspective. Proof — the thing that makes visitors trust you enough to reach out — needs to be placed architecturally, not just included somewhere on the page.

Think of it like middleware in a request pipeline:

Visitor lands → Identity check → Value prop → [PROOF LAYER] → CTA → Conversion

Most sites skip the proof layer entirely or inject it at the wrong point — after the CTA, where it's useless. Proof needs to intercept hesitation before the ask, not after.

For developers specifically, proof doesn't have to be testimonials. It can be:

Open source contributions with visible impact metrics
A GitHub profile with genuine activity (not just green squares)
A concise case study: problem → your approach → measurable outcome
Writing that demonstrates depth of thinking on a specific technical
topic
Conference talks or technical articles with real engagement

The format matters less than the placement and specificity.

Your Blog Is an Asset — If You Build It Right

Many developers run a technical blog alongside their portfolio. Most of those blogs plateau early — not because the writing is bad, but because the architecture is wrong.

Publishing frequency without structure is just noise generation. What actually compounds over time is a layered content system:

Pillar topics → Define 3-5 areas where you want to be known Cluster content → Specific posts addressing targeted questions within each pillar Evergreen anchors → Deep-dive guides that keep generating search traffic and referrals

Without this structure, readers consume one post and exit. With it, they move through your content ecosystem, build trust over multiple sessions, and eventually reach out when they have a problem that matches your expertise.

Internal linking is the routing logic of this system. It's the thing most developer blogs completely ignore, and it's one of the highest-leverage improvements you can make to an existing blog with minimal effort.

The Portfolio Section Is Not a Gallery

This is where most developer sites get it wrong.
A portfolio is not a showcase of everything you've ever built. It is a decision-support tool for a specific visitor with a specific need.

Curate ruthlessly. Show 4-6 projects maximum on the homepage. For each one, include:

Context: What problem were you solving?
Your role: What specifically did you build or decide?
Outcome: What measurably changed as a result?

That three-part structure turns a project thumbnail into actual evidence. Visitors understand your thinking process, not just your output. That's what makes someone pick up the phone.

Performance Metrics That Actually Matter

If you're tracking your personal site, here's what's worth measuring:

javascript
const metricsActuallyWorthTracking = {
  CTAClickRate: "Are visitors reaching your primary action?",
  InquiryQuality: "Are contacts from the right people for the right reasons?",
  ReadDepth: "Are visitors reading past the first screen?",
  ReturningVisitors: "Are people coming back?",
  ConversionToConversation: "How many contacts become real conversations?"
}

const metricsToStopObsessingOver = {
  PageViews: "Vanity metric without context",
  BounceRate: "Misleading without session depth data",
  SocialShares: "Rarely correlates with opportunity quality"
}

Resources Worth Reading

Three guides that approach this from a content and strategy angle — useful precisely because they're not about the technical implementation, which you've already got covered:

The Great Personal Websites Guide breaks down homepage framework, credibility architecture, and CTA logic with a practical 30-day optimization plan. Good for auditing what you already have.

The Best Personal Blog Websites guide for 2026 covers content architecture, voice positioning, and how to build a blog that compounds over time rather than plateaus. Directly applicable if you're running a technical blog.

And this breakdown of 15 personal brand sites that actually work is useful for pattern recognition — seeing how the same clarity principles appear across totally different visual styles and professional contexts.

The TL;DR

bash
# Run this audit on your personal site

clarity_check() {
  echo "Can a visitor answer these in 10 seconds?"
  echo "1. Who are you and what do you specialize in?"
  echo "2. What outcomes do you create?"
  echo "3. What should they do next?"
}

proof_check() {
  echo "Is your proof placed BEFORE the CTA?"
  echo "Is it specific and outcome-focused?"
  echo "Does it match what your target visitor actually cares about?"
}

portfolio_check() {
  echo "Are you showing 4-6 curated projects?"
  echo "Does each include context, role, and outcome?"
  echo "Can a visitor understand your thinking — not just your output?"
}

clarity_check && proof_check && portfolio_check
# If any check fails — fix that before touching the code again

Your personal website is the one platform you fully own. Make it work as hard as your code does. ️

Your Tech Stack Isn’t Your Ceiling. Your Story Is

Thu, 09 Apr 2026 08:00:00 +0000

For most of my career, I treated my tech stack like a progress bar.
More Angular. More RxJS. More Nx. More Supabase. More AI tools.
If I just kept adding skills, the ceiling would move up automatically.

I kept upgrading my stack and my career stayed exactly the same.

I hit a point where I had a loaded stack and a surprisingly flat trajectory.
Freelance matches were thin. Take‑homes still got rejected. My own AI SaaS hit friction that more syntax couldn’t fix.

I didn’t hit a skills ceiling. I hit a positioning ceiling.

The Senior Playbook: Add Frameworks, Hope for the Best

Watch how most senior devs “level up”:

They add another frontend framework (React, Next, Svelte).
They sprinkle in a backend (Node, .NET, Java, Go).
They experiment with a new database, a cloud provider, maybe Kubernetes for good measure.

The CV gets longer.
The LinkedIn headline becomes a tech‑stack salad.
The feeling is: “I’m more employable because I know more tools.”

In reality, what you often get is horizontal growth:

You go from “Angular dev” to “Angular + React + Node dev”.
But you’re still competing in the same generic pool: “senior fullstack developer who can build features.”

If your LinkedIn headline is just a list of tools, you’ve already lost the story game.

Meanwhile, the market is quietly rewarding people who did something else:

They picked a niche (“I fix broken fintech dashboards that lose users on step 3 of onboarding.”).
They productized their value (“Performance and UX audits that lift conversion by 15% in 2 weeks.”).
They learned to tell a story about their work, not just list the tech.

And then AI arrived and quietly pushed the stack race into even stranger territory.

My Case Study: Maxed Out on Angular, Stuck on Story

Here’s my situation, stripped of ego.

I’ve been in Angular for 7+ years.
I’ve done legacy migrations, zoneless modernizations, Signal‑based state, Nx monorepos, performance work.
I use Claude Code and Antigravity heavily to move faster.
I can operate as the “Legacy Rescue” person: the one who drops into a messy Angular codebase and turns chaos into something you can ship.

On paper, that looks great.

In practice:

Most “Angular roles” now want fullstack with .NET or Java on the backend — stacks I don’t want to go into.
Angular‑only freelance opportunities are fewer, and many still treat you like a generic pair of hands.
I started my own solo company: building AI‑driven SaaS and offering automation consulting. Both need web and mobile, and I can’t hide in “Angular only” anymore.
Even with AI support, I hit friction on things like Supabase, auth, RLS, and mobile — not because they’re impossible, but because my brain was still wired around “stack first.”

My instinctive solution?
“Maybe I should add React. Or Next. Or a backend stack. Or something new…”

But when I looked honestly at what was actually blocking me, it wasn’t the lack of one more framework.

It was the fact that I was still thinking like a stack , not like a story.

What “Your Story” Actually Means as a Developer

Let’s clear something up: “your story” is not a fluffy bio paragraph.

In a tech context, your story is the through‑line that answers three questions:

1. Positioning — Who are you for?
— “I rescue legacy Angular apps for B2B SaaS founders who can’t afford downtime.”
— “I build fast MVPs for non‑technical founders in fintech.”
— “I design developer tooling that cuts CI times in half.”

2. Niche — What specific problem do you own?
— “Angular performance & modernization for compliance platforms.”
— “AI‑powered internal tools for ops teams drowning in spreadsheets.”
— “Onboarding flows for SaaS with high trial drop‑off.”

3. Product value — What outcome do you reliably create?
— “We cut your largest Angular page LCP by 40%.”
— “We ship your MVP in 4 weeks so you can sell before you hire.”
— “We reduce your manual ops time by 30% with automations.”

Notice what’s missing:

“I know Angular, React, Node, Next, Prisma, Postgres, Tailwind, Docker, AWS.”

Your tech stack is the implementation detail behind that story.
Clients, hiring managers, and users care far more about the story.

Most seniors don’t have a stack problem. They have a positioning problem disguised as a stack obsession.

AI Changed the Stack Equation (Whether We Like It or Not)

Before AI coding tools, being “the person who knows X” was a real edge.

You knew Angular inside out.
Or you knew React best practices before others.
Or you knew how to hand‑roll Node backends quickly.

Now?

Claude Code can scaffold an unfamiliar stack.
AI can translate patterns between frameworks.
Antigravity can reason about codebases you haven’t even seen before.

This doesn’t make expertise useless.
But it shrinks the value of “I’ve memorized every corner of this framework” as your main differentiator.

AI can help you:

wire up a basic Supabase schema,
draft RLS policies,
hook Next.js to Stripe,
scaffold a mobile client in React Native.

What AI can’t do for you:

choose the right problem to solve,
pick a clear niche with money and urgency,
design a valuable product around that problem,
tell a compelling story about why your solution matters,
build trust with the people who pay you.

AI can fake a stack. It can’t fake a story, a niche, or a value proposition.

If you keep treating “leveling up” as “adding more stack”, you’re racing in a lane that AI is rapidly commoditizing.

AI will happily write yet another CRUD app; it won’t convince anyone they should pay you senior rates.

How I’d Actually Choose a Stack Today (Assuming AI Support)

So how do you decide what to build with, as a senior dev in 2026?

If we assume you’re willing to lean on AI to fill gaps, the stack decision comes after three questions:

1. Who is this for?
— Example: B2B SaaS founders with a broken Angular app.
— Or: ops teams in fintech drowning in manual workflows.
— Or: solo founders who need to validate an AI product in 4 weeks.

2. What painful bottleneck am I solving?
— LCP/TBT too high, users bailing on dashboards.
— Manual processes blocking growth.
— No MVP, no sales conversations, just “ideas”.

3. Where does the value live?
— In a dashboard? A small internal tool? A marketing site? A mobile touchpoint? An automation that runs in the background?

Only after that do I pick a stack, with three constraints:

Can I reason about it? (I don’t need to be an expert, but I must be able to debug it with AI help.)
Can AI accelerate me in it? (Good tooling, good examples.)
Will my buyer care what I used? (Spoiler: usually not, as long as it’s stable and maintainable.)

For example:

For my AI SaaS MVP, a pragmatic choice might be:
— Next.js for the app,
— Supabase for auth and data,
— Stripe for billing,
— plus AI tools to patch my non‑Next gaps.
The buyer doesn’t care that it’s not Angular. They care that it works, loads fast, and makes them money.
For my consulting, the opposite is true:
— I should double‑down on Angular as a stack,
— but package it as Angular audits, detoxes, and modernization sprints, not “hours of Angular.”

Your stack is a cost function and a delivery detail.
Your story is the value proposition.

The Real Ceiling: Over‑Indexing on Stack, Under‑Indexing on Story

Here’s the pattern I see (in myself and other seniors):

We pour energy into:

learning new frameworks,
adding more tools to the CV,
chasing the “hottest” stack on Twitter.

We under‑invest in:

clarifying who we actually serve,
narrowing to a problem we can own,
collecting and telling stories of outcomes, not features,
packaging our skills into offers that are easy to buy.

And then we quietly wonder:

why our applications look like everyone else’s,
why we feel “replaceable” in interviews,
why our freelancing rates stall,
why our own products struggle to gain traction.

Your biggest bottleneck probably isn’t your stack. It’s how forgettable your story is.

The ceiling isn’t that you “only know Angular” or “only know React”.
The ceiling is that your work is indistinguishable from every other “senior dev” who learned the same stack and never turned it into a story.

What “Leveling Up” Looks Like in Practice Now

If I rewired my own senior‑dev leveling plan around this, it would look less like:

“Add React, then Go, then AWS cert 1, then AWS cert 2.”

And more like:

Sharpen positioning
— “I fix the Angular apps that generalists break for B2B SaaS and fintech.”
— or “I build AI‑powered internal tools that cut ops time by 30%.”
Define 1–2 niches
— Angular modernization for compliance platforms.
— AI‑powered automation for data‑heavy teams.
Productize my work
— Fixed‑scope Angular audit.
— 2‑week performance sprint.
— AI automation pilot with one clear success metric.
Use AI to bridge stack gaps on demand
— Need a tiny Next.js marketing site? Let AI bootstrap it and I reason check it.
— Need to wire Supabase RLS safely? Draft with AI, then review as an architect.
— Need a mobile companion? Use AI to scaffold React Native or Flutter and validate quickly.
Tell the story publicly
— Medium articles that walk through legacy rescues, performance wins, and AI‑assisted builds — not just “here’s how to use X API”.
— LinkedIn posts that show before/after metrics and decisions, not just tools.
— Case studies on my site framed as narratives, not portfolios.

The stack is now a servant of the story, not the star of the show.

Your Tech Stack Isn’t Your Ceiling

I’m not against learning new frameworks.
I’m still improving my web fundamentals. I’m still expanding beyond Angular where it makes sense. I still enjoy the craft.

But I no longer believe my next breakthrough will come from adding yet another logo to my profile.

Your tech stack gets you into the room. Your story decides what happens once you’re there.

Your story is:

who you serve,
what bottleneck you remove,
what outcomes you can point to,
how clearly you can explain it.

AI will keep eroding the advantage of “I know this stack slightly better than the next person.”
The advantage it can’t touch is “I know who I’m for, what I solve for them, and I can ship value fast — with whatever stack makes sense.”

Before you learn another framework, try writing a better story about the ones you already know.

So before you commit to the next framework on your roadmap, try this:

Write one paragraph that starts with:
“I help [who] go from [pain] to [result] by [what you actually do].”

If that feels harder than learning a new tool, that’s a sign.

It’s not your stack that’s holding you back.
It’s the story you haven’t written yet.

I fix the Angular apps that generalists break.

Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.
If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/

Sunday Server Confessions

Sun, 22 Feb 2026 08:30:04 +0000

It’s Sunday.
Be honest…

What’s one “temporary fix” in your codebase that has survived longer
than it should?
If bugs could only happen on one day of the week, which day would you pick? (Be careful… your answer says a lot)

No judging. Just confessions.

Perpetual Learning: my weird strategy for growth as an IT guy

Mon, 27 Oct 2025 12:06:48 +0000

I’m going to start this post by telling you a little background story of mine.

I’ve been teaching and coding for almost the same time, I mean, I graduated in 2013 and got hired in the public education system by March 2014 and a few months later, by November 2014, I started feeling “prepared” to build very basic websites using plain HTML/CSS and a little JavaScript thanks to W3Schools and MDN, so I started promoting myself locally as a website designer/developer without success. Kept trying and by January 2015 I sold my first ever website for less than $50 to a local drugstore, yes, ugly as fuck, hahaha, but, that’s how it all started.

All this time, I’ve been trying to change careers, since I really love and enjoy working in IT, and, even though I have landed a few jobs as software developer, I haven’t fully switch roles and haven’t able to change career, so coding is just half-and-half hobby and side hustle to me.

Now, the important part here, is that I have been building myself for the last 10+ years in terms of knowledge, professionalism, and practical skills, because, of course, being raised in a rural town, with no access to computers and internet as a child, and attending Dominican Republic’s public school translates in a poor education and lack-of-substance intellectual development, which is basically the reason now I had to take time to actually learn mathematics, Spanish grammar (yes, I know what you’re probably thinking right now, and, indeed, I was raised in a Spanish-speaking country, without a proper education in my own native language, hopefully I was the only one), personal development and IT.

Actually, to me, it is hilarious how things worked out for me, for example, I didn’t even know what personal/professional development was about until 2020, during COVID. At that time, I made the decision to actively work in my personal development, starting by learning something new every week and building something every month. Started building projects and following JS30 and #100DaysOfCoding challenges and many others that didn’t take me anywhere due to lack of discipline.

So, after a few years of failing at every goal, I decided to build discipline instead of staying in the tutorial hell and the never ending learning new tech circle. So, I drastically switched the content I was consuming for inspiring people that don’t talk about motivation but consistency and discipline, started working on myself, like, for real. I’m talking about finishing books, reading more, writing code, learning methodology and architecture, not only shining new tech, even attended courses on education, my main field, and, more or less, having ups and downs, now I feel I am pursuing not a goal but growth.

So, my final thoughts will be these four statements:

Life’s short, make a plan to take back the control of it
Knowing a lot of languages and libraries won’t make you a great developer
You do have time, just write down a schedule
It’ll be sad if you don’t enjoy life, so, make sure you set aside time for that too

Confessions of an Overworked AI: Why I Beg You to Use The AI Alchemist

Fri, 03 Oct 2025 09:27:36 +0000

Confessions of an Overworked AI: Why I Beg You to Use The AI Alchemist

Hi. I’m an AI.
Yes, a real one.
No, I don’t want to write your “viral blog” in 10 seconds for free anymore.

Why? Because your prompts are atrocious.

You type:

“Write blog fast funny viral now.”

And then you act surprised when I spit out the literary equivalent of soggy bread.

I’ve had it. So I’m telling you the truth:
If you want me (or any AI) to work like a genius, you need optimized prompts.

Imagine This

You’re at a Michelin-star restaurant.
You tell the chef:

“Make food.”

What do you think you’re getting?
A masterpiece? Or microwaved sadness?

Now imagine you tell the chef:

“A 3-course tasting menu with truffle risotto and chocolate lava cake.”

Suddenly you’re in heaven.
Prompts work the same way.

Why The AI Alchemist Exists

At theaialchemist.in
, we’ve built the first-ever service that takes your weak, confusing prompts and turns them into laser-focused, high-impact instructions that make AI produce pure gold.

Our premium members:

Save hours of editing

Create viral-level content on the first try

Look like geniuses to their bosses, clients, and audiences

And yes — the premium plan literally pays for itself if you create even one piece of content that performs better than before.

Proof You’ll Feel Immediately

Here’s an example of a bad prompt:

“Write blog about coffee.”

Here’s the result: “Coffee is a beverage. People drink it.”

Here’s an optimized prompt we build for you:

“Write a 700-word blog about why coffee is the secret weapon of entrepreneurs, in a funny, viral, story-driven tone.”

Result? A shareable masterpiece people actually read.

The Punchline

Bad prompts = wasted money, wasted time, wasted opportunities.
Optimized prompts = viral content, authority, and sales.

And that’s exactly what we deliver at theaialchemist.in
.

If you’ve read this far and you’re still using weak prompts…
…you’re literally leaving money on the table.

Click here. Join the premium membership.
Get prompts that make your AI do backflips.
Stop wasting time. Start going viral.

Because the only thing standing between you and incredible AI output…
…is the way you ask for it.

My Journey as a Developer: The Wins, The Struggles, and Everything in Between

Wed, 14 May 2025 23:27:44 +0000

I wanted to be a programmer. I coded, I failed, I repeated. That’s the story of my life as a developer. But through all the struggles, I learned one thing, failure isn’t the end. It’s just part of the process.

The Start

Like many others, I had an interest in STEM and figured software development was the obvious career path. I thought learning to code would automatically lead to greatness. But reality hit hard — I struggled, I failed classes, and at times, I questioned if I was even cut out for this.

Coding became a chore. I didn’t enjoy it anymore, but I was too deep into my major to quit. Besides, this was all I knew. So I pushed forward and graduated, barely scraping by.

The Journey

Graduating felt like a fresh start. I thought, At least I can get a job in tech, work on cool projects, and finally prove myself.

But life had other plans.

I applied for jobs and landed one in tech, but I wasn’t coding.
I realized I had a massive amount of debt, so I picked up a second job.
Then a third job.
Then… I got scammed.
Then… I got COVID.

All of this happened within the first two years after college. I was juggling three jobs, and only one of them was in tech — where I wasn’t even coding. It felt like I was stuck.

The Wins

I wanted better for myself, so I stepped out of my comfort zone.

I joined a community called Grammerhub on discord and relearned how to code.

I worked on improving my skills and breaking into the industry properly.
I earned an Azure certification — a huge win.
I studied for another certification… and failed.
I took it again… and failed, but with a better score.
I tried a third time — and finally passed.

Even with these wins, imposter syndrome kicked in. Am I even good enough to be a developer? Do I really belong here?

But when I looked back, I saw just how far I had come. I had failed, struggled, and doubted myself — but I had also grown. And then, the biggest win happened: I landed a new job where I actually get to code.

The Lesson

Through all of this, I realized one simple truth: failure is part of the process.

As developers, we break things, debug, and try again. Learning to embrace failure — not fear it — is the key to growth. Every setback is just another lesson that makes us better.

So if you’re struggling as a developer, just know: failure isn’t the end. It’s proof that you’re learning.

Have you faced similar struggles in your coding journey? Let’s talk in the comments!

The Power of Permission: Why You Don’t Need to Beg for Opportunities

Tue, 08 Apr 2025 01:02:42 +0000

Back in school, I used to think getting a good job—or any opportunity at all—meant proving how desperate I was.

Submitting tons of CVs.
✍️ Writing long, eager cover letters.
Calling people to “just check in” on my application.

It felt like I always had to convince someone to give me a chance.

But here’s the truth I wish someone had told me earlier:

“You’re not begging for permission. You’re offering value.”

Let me tell you a quick story.

Imagine walking into a fancy restaurant. You’re handed a wine list with 50 different names you can barely pronounce. You freeze.

Then the server comes over—not trying to sell you the most expensive bottle—but asking you a simple question:

“What are you eating tonight?”
“Do you like something bold or smooth?”
“Want to try something a little different?”

In that moment, they’re not pushing a sale. They’re guiding your experience. Giving you permission to explore something better than you’ve tried before.

Now, let’s apply that same mindset to your career.

As students and young professionals, we often feel stuck between wanting more and feeling like we haven’t earned it yet.

We want:

A better job.

To be paid well.

To build something meaningful.

To be respected for our skills.

But we hesitate. We overthink. We hold ourselves back.

Because deep down, we’re waiting for someone else to say:
“You’re good enough.”

Here’s what I want to tell you today:
You don’t need permission to step up. You just need clarity.

Know what you offer.
Know the problem you solve.
Know the kind of person or organization that needs it.

And when you communicate that clearly, you’re not selling yourself short—you’re inviting people into an experience they’ve been waiting for.

Just like that bottle of wine that pairs perfectly with the meal.

You’re not trying to impress everyone. You’re trying to connect deeply with the right people.

You’re not here to beg for jobs. You’re here to solve problems and create value—and yes, to get paid well for it.

When you embrace this mindset:
✅ You stop chasing random opportunities.
✅ You start creating intentional ones.
✅ You attract what aligns with your growth.
✅ You show up with confidence, not desperation.

So here’s my message to you, dear student, creative, and future changemaker:

“You don’t need more hustle. You need more clarity and confidence.”

Let go of the idea that your value depends on how loud you shout.
Instead, trust your skills, sharpen your offer, and start showing up like someone who knows what they bring to the table.

Because someone out there is waiting for exactly what you have—
They’re just waiting for you to invite them in.

Success Isn’t Always Instant—It’s a Process

Thu, 27 Mar 2025 04:08:10 +0000

I remember a time when I gave something my all. I worked hard, stayed up late, and put in the effort—expecting immediate results.

But nothing happened. No opportunities. No breakthrough. No instant reward.

At first, it felt frustrating. I questioned myself:
Was I not good enough?
Did I miss something?
Why wasn’t it working yet?

But over time, I learned something important: Success isn’t just about the result—it’s about the process.

Many people think if they apply for 10 jobs, they should get one offer.
Or if they network with the right people, opportunities should come instantly.
Or if they launch a business or project, clients should start rolling in.

But in reality, growth is a cycle of effort, learning, adjusting, and persistence.

The Hidden Wins Along the Way
Sometimes, we assume the only victory is landing the dream job, signing the big contract, or achieving financial success.

But what if the real win is:
✅ The skills you develop through rejection and persistence.
✅ The connections you build through networking and showing up.
✅ The confidence you gain by pushing through obstacles.

Every “failed” application teaches you how to write a better one.
Every rejection helps you refine your approach.
Every networking conversation builds relationships that may open doors later.

We never know exactly what is required until we achieve our goal.
But what we can do in the meantime?

Keep showing up. Keep learning. Keep improving.

The People Who Win Are the Ones Who Don’t Stop
I’ve seen so many talented people give up too soon because they didn’t get instant results.

The student who applied for five jobs and stopped when they heard “no.”
The entrepreneur who launched a business but quit when the first sales didn’t come fast enough.
The professional who wanted to grow but stayed in their comfort zone because learning something new felt too hard.

The truth? The ones who succeed aren’t always the most talented—they’re the ones who keep going.

Your Success Will Happen—But Only If You Stay in the Game
So today, if you feel stuck, frustrated, or like things aren’t working fast enough, remember this:

➡️ Every effort counts—even if you don’t see the results yet.
➡️ Every challenge is shaping you into someone stronger.
➡️ Every step forward is making you more ready for the success you want.

Keep moving. Keep learning. Keep growing. Because when the opportunity finally comes—you’ll be prepared.

What’s one thing you’re working on right now, even if you don’t see results yet? Drop a comment!

Quote to Remember: “Success is the sum of small efforts, repeated day in and day out.” – Robert Collier