DEV Community: DivyanshuLohani

My 2025

DivyanshuLohani — Thu, 01 Jan 2026 18:04:58 +0000

2024 was about proving things to myself that I could build, learn fast, and keep shipping projects. 2025, on the other hand, was about understanding what it actually means to build software.

This year wasn’t flashy. It didn’t revolve around frameworks or buzzwords. It was messy, practical, and occasionally uncomfortable. I shipped code to production, dealt with real failures, made architectural decisions that had consequences, and learned lessons that no tutorial could’ve taught me.

These are not lessons I learned by reading, they’re lessons I learned by doing.

Stepping Outside the Screen: Real-World Opportunities

This year I finished high school and also got into actual real world things, for the longest time, my entire relationship with tech existed behind a screen but after my boards I had very much free time to go and explore the real tech world.

This year, I attended my first ever tech fest: DevFest by GDG Ranchi . It might sound small on paper, but for me, it was a turning point. Seeing developers, speakers, and students in the same physical space made something click that online learning never quite did.

Until then, tech had felt like a solo pursuit me, my pc and an internet connection. DevFest showed me the human side of software: people sharing failures, debating decisions, and talking about systems they’ve actually broken and fixed in production.

What surprised me most wasn’t the scale of the event, but the realization that I belonged there. I wasn’t “too early” or “underprepared.” I understood the problems being discussed, asked better questions, and left with a stronger sense of direction.

This experience taught me that learning doesn’t only happen through code it also happens through exposure. Being in the same room as people building real things pushes you to raise your own standards. It made me want to ship better software, think more responsibly, and stop treating projects as disposable experiments.

Production Is a Different Game Entirely

Thanks to this habbit of writing blogs I got quite lucky I secured my first clients to work as a freelance web developer and take my skills to the real world. For a long time, I treated “shipping” as the finish line. If the app worked locally, deployed successfully, and didn’t crash immediately, I considered it done (I knew few edge cases but left it there because it was just a casual project). 2025 completely destroyed that illusion. This year I dealt with apps made for real users, real people using them, bugs that weren't just there all along but left unspotted due to manual testing and treating the app with care.

Shipping code to production is not an extension of side projects, it’s a different discipline altogether. Suddenly, every decision carries weight you can't just break things and push to prod or like get a quick change. Logs matter a lot I mean a lot things can go wrong in the frontend as well as backend. Rollbacks matter. Downtime matters. Even small changes feel heavier when real users depend on them. One wrong mistake and your whole app is down for minutes cosing you a lot.

In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops” it’s someone else’s workflow interrupted, someone's dilevery failed, data potentially affected, or trust slightly eroded.

This year taught me that production software demands a mindset shift:

You think twice before deploying.
You test flows you previously ignored.
You plan for failure instead of assuming success.

The biggest change wasn’t technical — it was psychological. I stopped asking “Will this work?” and started asking “What happens when this breaks?” "What more ways a user can perform this action to break things" these questions alone made me a better engineer.

Vulnerabilities Don’t Care About Your User Count

One of the most uncomfortable lessons of 2025 was realizing how exposed even a small application can be. I used to believe that security becomes important after you have users. That belief didn’t survive this year.

Major vulnerabilities surfaced that directly affected production apps including one that took my own app down. It didn’t matter that my user base wasn’t massive. It didn’t matter that the app wasn’t popular. Once something is publicly accessible, it becomes a target.

The most painful realization came at the end of the year when a critical CVE hit the ecosystem I was using. My production app was suddenly vulnerable, and the damage wasn’t theoretical it was immediate and real.

That experience taught me hard rules I won’t forget:

Never run applications as root in production — ever.
Assume every service will be scanned, probed, and tested.
Security is not an “enterprise problem”; it’s a baseline responsibility.

Security stopped being an abstract concept for me in 2025. It became personal. And once that happens, you never build the same way again.

Projects That Shaped How I Think About Software

2025 wasn’t about the number of projects I built, it was about how each project forced me to confront a different kind of complexity. Every serious project this year changed the way I reason about systems, trade-offs, and responsibility.

One of the earliest was a grocery delivery app, inspired by products like Blinkit. On the surface, it looked straightforward: users, products, carts, orders. In reality, it introduced me to time-sensitive workflows, state transitions, and operational pressure. Orders aren’t just data — they’re promises. Late updates, inconsistent states, or missing edge cases immediately translate into broken trust. You can read more about this project here

Later, I went deep into live streaming, transcoding, and video processing. This was a completely different mental model. I learned that video systems are not frontend problems —they’re infrastructure problems. Encoding formats, transcoding pipelines, latency, and resource usage all matter more than UI polish. This exploration reshaped how I think about performance and scalability. more about this here

Finflow, my expense tracker, evolved significantly this year. What started as a web app grew into a system with major updates and a Flutter mobile app that synced data with the web. Handling consistency across platforms taught me that shared state is one of the hardest problems in software. UI is forgiving — data corruption is not.

When GitHub Actions were blocked for me, I didn’t wait. I built a simple CI/CD pipeline myself. It wasn’t fancy, but it worked — and more importantly, it forced me to understand deployments at a lower level. When the tooling disappeared, the learning multiplied.

Payments were another major theme. I integrated multiple payment gateways, explored different verification patterns, callback flows, retries, and failure handling. Payments taught me that correctness matters more than elegance. You don’t optimize for beauty when money is involved — you optimize for certainty.

I briefly explored Flutter more deeply, but eventually realized my long-term focus was better aligned with Expo and JavaScript-based ecosystems. That detour wasn’t wasted — it clarified my direction.

By the end of the year, I was building something bigger: a platform-style app inspired by Hago and WePlay. Not just a game, but a system — users, sessions, state, and real-time interaction.

Every project added a new layer to how I think. Not “how do I build this?” but “what breaks first, and why?”

ReadmeHub and Remembering Why I Build

I vibe coded a simple app to try out vibe coding but also spread a positive message around the world a small, almost sarcastic project aimed at calling out fake participation during Hacktoberfest. It was for the developers who show up only for the T-shirt, not the contribution.

The app wasn’t complex. It didn’t introduce new architectural challenges. But it served a purpose it let me build something opinionated, fast, and honest without worrying about polish or metrics.

That mattered more than I expected.

ReadmeHub reminded me that building can still be playful. That not every project needs to become a product. Some projects exist just to say something, explore an idea, or scratch an itch.

In a year full of responsibility, production pressure, and real consequences, this small project helped me reconnect with why I started building in the first place.

You can checkit out at: https://readmehub.divyanshulohani.xyz/

The Biggest Lesson Wasn’t Technical

Looking back, the most important things 2025 taught me had very little to do with frameworks, languages, or tools. I didn't build too much projects I explored every aspect in my existing apps I could yeah some distractions were there that did contribute to the factor of not building new projects

But I learned that building software is an act of responsibility. Your mistake can cost a lot in production a mistake is not just a mistake its a real thing you are accountable for.

Once something is in production, it stops being “your code” and starts being something other people rely on. That shift changes how you think, how you test, how you deploy, and how you respond when things go wrong.

I also learned that speed without intention leads to fragile systems, and that maturity in engineering often looks like choosing the simpler, safer option — even when you could build something more impressive.

Most importantly, I learned that growth isn’t about how much you ship. It’s about how deeply you understand the consequences of what you ship.

That mindset changed everything.

Looking Ahead to 2026

If 2025 was about learning through experience, 2026 will be about sharing those experiences openly and building more software tougher ones.

Next year, I want to create more content not tutorials chasing trends, but honest write-ups about what worked, what broke, and what I’d do differently. I want to document the decisions behind the code, not just the code itself.

I’m entering 2026 with clearer priorities:

Build fewer things, but build them better
Treat production as sacred
Keep learning, but stay grounded
Share the journey, not just the outcomes

2025 taught me how fragile software can be. 2026 is about building it with more care and helping others do the same.

I hope you spent your 2025 just as amazing and fantastic as I did and looking forward I Wish you all a Happy 2026

The Compromise of a Production VPS

DivyanshuLohani — Wed, 10 Dec 2025 19:41:08 +0000

Security incidents often arrive quietly, without alarm bells or dramatic warnings. They sneak into production environments when we least expect them, on weekends, during moments of downtime, or when routine vigilance slips just a little.

This is the story of how my production VPS was compromised by attackers who deployed crypto-mining malware and persistent agents. What followed was a long learning process filled with investigation, cleanup attempts, unexpected failures, and finally, a deep dive into what true production-grade security really means.

A Sunday Evening Shock

It began innocently. On a calm Sunday evening, I opened my production app to check something. Except… it didn’t load. No error page. No timeout. Just a silent blank screen nothing except the slpash screen.

I assumed the server might be having a hiccup. Maybe a deployment issue or that core just again said I will not work. Maybe some error or the hosting service down (which is happening a lot recently) but I was so wrong.

My first thought today is sunday lets leave it for tomorrow but curiousity began in my mind so I got to my workstation and tried to SSH into the VPS. Connection timed out. Tried again. Timed out again I thought hmm... maybe connection failure or may the vps have been shutdown due to overdue bill I supposed. again I was so wrong.

After multiple attempts, the SSH prompt finally appeared. the machine was slow and sluggish like running ls was also taking 3 - 4 seconds that sluggishness became my first real clue

The machine wasn’t down, it was overwhelmed.

Once I logged in, the system felt painfully sluggish. Even typing commands felt like wading through molasses.

I ran:

top

And saw something that changed the tone of the night and runined the few hours of my weekend

The Bad Actor

A process named rysyslo\, located in /usr/bin/rsyslo, was consuming roughly 80% CPU and a significant amount of RAM and almost all of the disk space

I had never installed any binary by that name. Ubuntu the os, doesn’t ship such a file.

A quick chat and search confirmed it. It was malicious.

My server had been breached.

First Cleanup Attempt; Sense of a False Victory

I deleted the suspicious binary. Removed unfamiliar services. Killed the rogue processes. The load dropped. The system behaved normally. Everything felt fine. But deep down in my mind I knew that it may not have been gone with such simple attempts (spoiler alert: I was right) but still I left it as I thought I will backup the data tomorrow

The Next Day Things Get Worse, Not Better

The following morning, I again opned the app, still unavailable. Over 16 hours of downtime at this point.

SSH once again behaved erratically — refusing connections for minutes at a time. I even had to ask chat gpt to get me script to constantly try to get in using ssh because it just kept on timing out.

When I finally got in, the situation had escalated dramatically.

Running top revealed:

xmrig — a notorious crypto-mining tool
Multiple disguised binaries with random names
Fake kernel threads impersonating system processes
A mysterious program called monarx-agent consuming memory
Node processes I had not launched

The first obvious solution that came to my mind was to kill them but I knew this was not going to do anything because they must have set backdoors and other ways to restart the service. The system was no longer merely “infected.” It was owned.

The Attackers’ Footprint

I still am very beginner in devops and linux systems even though I use it as my daily driver. I asked chat gpt how can I clean the system follwed the steps closely and this bought me some time to backup any server data that was there.

First I did basic scans to search for malicious services and found alive.service and lived.service these are too not created by the os and ofcourse not by me hence: malicious they both pointed to a script file located in the following locations:

/tmp/runnv/alive.sh
/tmp/runnv/lived.sh

Both services were configured to:

Restart=always
RestartSec=5s

These scripts continuously fetched, restored, and relaunched the miner — even seconds after deletion. This explained everything: No matter how many times I killed a process or removed a binary, the malicious services resurrected them.

This wasn’t a small compromise. It was a full-scale, multi-vector persistence setup.

Services Begin to Break

Over time, the machine became unstable:

SSH stalled or dropped repeatedly
System operations slowed to a crawl
Memory usage spiked unpredictably
System logs showed irregularities
A fake agent (monarx-agent) reappeared no matter how many times it was removed
The machine would barely stay functional long enough for basic commands

There was no longer any pretense of stability it became like the VPS was setup intentionally for mining bitcoin.

The attackers had established root-level foothold (this was due to my fault but more on this later), and the operating system had been modified in ways I could no longer trust.

My Response to the things

At this stage it was not about that how can I fix the server but the important server data that's on there should be extracted asap and the user data should be checked to see that it did not have a breech

I began systematically backing up:

PostgreSQL database dumps using pgdump
Application server files
Media directories
Configuration files
User uploads
Essential environment variables
Reverse proxy configs
Logs for analysis

Because the system was barely responsive, everything required workarounds,

For anything related to files I used rsync and copied the files to my local machine but this was not the usual way I had to write scripts to check the access of the ssh and then copy the files because the ssh connection kept on dropping.

Eventually, I succeed in the task every important asset was safely backed up.

After confirming data integrity and to my surprise the application data was untouched by the hackers they just wanted to use my machine to mine crypto, so I made the decision to shut down the compromised machine permanently and migrate to a fresh VPS instance because this was destroyed beyod repair.

Searching for the Entry Point

After all the chaos I was geniunly curous that how did they get access to my server, I never had my keys leaked nor the IP so I began looking into this.

I began by reviewing all forensic data:

/var/log/auth.log
SSH access attempts
Systemd unit file timestamps
Root-level process creation logs
Cron jobs
Unknown script origins
Unfamiliar executables
Running port lists
Binaries in /usr/bin, /tmp, /dev/shm, /usr/share/updater

What I discovered:

I was right I did not had my keys leaked or something like that. The log only showed rejected SSH requests which I know happen because some people just leave everything to the default (I am one of those but not at this point)

Everything was good but annoyingly:

❗ There was no definitive entry point.

So where did they get in?

The prime suspect is the very recently disclosed React2Shell vulnerability (CVE-2025-55182) revealed just a day before the attack. This vulnerability allows remote code execution under certain misconfigured environments.

Web servers or exposed ports would have been particularly vulnerable. Another major factor:

And yes I was right I checked the nginx logs for the server and there I see someone forcefully did a post request to every endpoint they could've found and there might been vulnerable endpoints which gave them access to the machine.

Hostinger VPS firewall defaults to allow ALL inbound and outbound traffic.

Unlike cloud platforms with strict security groups (AWS, GCP), this VPS was wide open at the network level. this was the default thing I never touched.

This alone dramatically increases the attack surface.

The Biggest Lesson — Never Run Applications as root

One big mistake I had made knowingly that not to run apps with root privelleges that they can modify the system in anyway. My PostgreSQL server, which ran under a non-root system user, remained untouched by the attacker, I know they were not looking for it but in case then it would've still remained safe No tampered files. No altered configurations. No corrupt data. No suspicious access. Even though the system was compromised, the database was safe.

This incident reinforced a principle I will never ignore again:

Never run applications as root. Ever.

Give them the smallest permissions required to function and nothing more. not even modification outside the directory (unless your app has to access).

The Rebuild

After recovering and moving to a fresh VPS, I rebuilt the environment with proper security measures:

Firstly I ensured that I do not run the process as the root user I create users for each module like for the server for the frontend or for the api. NO compromise should be made in setting users up.

I enforced strict firewall rules only allow http and https ports to be expoed to the public because my app does run postgres but as an internal tool and the database should not be accisble publically all traffic is handled via nginx so other ports should not be open.

This wasn’t just “rebuilding a server.” It was rebuilding an entire philosophy about production infrastructure.

Final Thoughts

Security incidents can be unsettling, especially when a server is actively failing under the strain of malware and critical data must be preserved in a limited window of time. Yet, despite the pressure, this experience provided a deeper and more practical understanding of DevOps and cybersecurity than any structured lesson could have offered. Real incidents force you to confront the consequences of design decisions, configuration choices, and operational habits in a way theoretical learning never does.

Key lessons learned:

A VPS exposed with open ports is an open invitation for attackers. Any publicly accessible service increases the attack surface. Without strict access controls, monitoring, and proper configuration, automated scanners and bots will quickly identify and target vulnerabilities.
The presence of a crypto miner is a clear indicator of full system compromise. Attackers who deploy miners rarely stop there; they often modify system files, escalate privileges, and establish hidden footholds. Once this occurs, trust in the system is lost. Rebuilding from a clean state is the only reliable response.
Attackers rely on persistence mechanisms that are deeper than a single malicious process. Modern attacks may involve cron jobs, rootkits, altered binaries, SSH backdoors, and hidden user accounts. Removing one visible component does not eliminate the underlying compromise.
Least privilege is a critical layer of defense. Systems designed so that applications do not run as root help ensure that, even if an intrusion occurs, the damage is limited. Proper isolation, permissions, and role separation can prevent attackers from accessing sensitive data or making irreversible changes.
Backups are invaluable during emergencies. When a system is compromised, having recent, verified, and off-server backups can mean the difference between a smooth recovery and catastrophic data loss. Backup integrity and testing should be treated as core operational practices.
Default configurations are rarely secure. Vendor defaults prioritize usability and compatibility, not security. Hardening a system requires deliberate configuration: limiting access, disabling unnecessary services, enforcing strong authentication, and enabling proper logging.
Incident response demands composure and methodical action. In high-pressure situations, rushing often leads to mistakes. A structured approach—assess, contain, preserve evidence, recover, and improve—ensures that decisions are informed and effective rather than reactive.

Ultimately, this was far more than an unplanned lesson in server hardening. It served as a reminder that security is not a checkbox or a one-time setup. It is an ongoing discipline that requires continuous awareness, proactive measures, and a mindset of vigilance.

TL;DR

My production VPS was fully compromised by attackers who deployed crypto-mining malware and multiple persistence mechanisms. Initial cleanup attempts failed because the system had already been taken over at the root level. After identifying disguised services, malicious binaries, and severe instability, I focused on backing up critical data before rebuilding everything on a fresh server.

The investigation showed that open ports, default firewall settings, and a likely exploitation of a newly disclosed vulnerability created the entry point. The incident reinforced essential lessons: never expose unnecessary services, never run applications as root, always enforce least privilege, and treat security as an ongoing discipline—not a one-time setup.

When Hacktoberfest Became README-fest - I did this

DivyanshuLohani — Wed, 08 Oct 2025 10:59:58 +0000

The October of Open Source 🎃

October is a magical month for developers. While most people think it as just a normal month transition from summer to winter, we developers have our own tradition, Hacktoberfest. It’s that time of year when GitHub notifications blow up, Discord servers buzz with collaboration, and developers from every corner of the internet collectively shout,

“Hey, let’s contribute to open source!”

Hacktoberfest, started by DigitalOcean in 2014, was a simple yet brilliant idea: encourage developers to contribute to open source, reward them with limited-edition swag, and spread the joy of collaboration. It lowered the barrier for beginners so suddenly, even your first small PR (Pull Request) felt like a ticket to the world of real-world software.

It wasn’t just about code; it was about community. People made friends, joined projects, fixed typos, improved docs, and sometimes even built features that millions now use. For many developers, Hacktoberfest was their gateway drug into open source.

But like all things on the internet, what starts wholesome… eventually mutates into chaos.

Open Source: The Internet’s Most Beautiful Mess

To anyone outside the dev world, “open source” sounds like a technical term. But for us, it’s much more than that. it’s a philosophy. It’s about sharing knowledge, collaboration without boundaries, and believing that software gets better when everyone can help shape it.

I still remember my first real open source contribution. It was at Formbricks as a part of combined initiative that was oss.gg I stepped into the world by just making a small change adding a Last Used indicator to the login page.

But as we know every coin has two faces open source is no exception to that, the noble idea of coming together and helping build good software for people collided with internet culture’s favorite game: the numbers game (it ruins everything).

The Problem: When “Open Source” Turned Into “Open Spam”

Let’s be honest — the moment a reward system exists, people will find a shortcut to just abuse it and get the reward no matter the outcome.

As Hacktoberfest grew, so did YouTube tutorials titled “How to Win Hacktoberfest FAST!” New devs, excited to participate (and maybe get a free t-shirt), started following “guides” that basically said:

“Just find any repo, fix a typo, and submit four PRs.”

And thus began the era of the README Pull Request Apocalypse.

Repos everywhere were getting flooded with contributions like:

“Fixed a small grammar mistake.”
“Added full stop at the end.”
“Updated README title from H1 to H2.”
“Added emojis for ✨aesthetic✨.”

Some poeple (yes people not devs) just be like I will add my name to the readme for what reason god knows but they will do.

Open source maintainers were drowning in meaningless PRs. Some people were even creating repos just to spam each other with fake PRs. Github like introduced a feature to like limit new users from contribution which can be turned off every major framework or library has that turned on, It became a game changed from who can get do meaningful help to who could get four green squares the fastest.

Now, don’t get me wrong — I don’t blame anyone. For many, it wasn’t malice; it was desperation to belong. Beginners wanted to see their name in the contributors list. They wanted proof they were “part of open source.”

But in chasing that feeling, Hacktoberfest started losing what made it beautiful — genuine collaboration.

My Pun-In-Code Response: Enter ReadmeHub

I could’ve written a tweet thread complaining about it. Or made a meme. But instead, I thought — why not turn the whole situation into a joke that actually works as an app?

That’s how ReadmeHub was born — a parody platform for “open source contributors” who just can’t resist updating README files.

It’s like GitHub’s unserious cousin — built purely for fun and satire. You log in, type your username, and you’re now a “contributor.”

The app has a variety of repositories to contribute to:

cool-project – “The coolest project you’ll ever see (probably not)”
todo-app-9000 – “Yet another todo app that will definitely change your life”
useless-project – “A project so useless, it’s actually useful”

You can contribute to them in following ways:

Fixing Typos
Adding Emojis (AI thinks it makes a repo look professional)
Adding Quotes randomly
Vibe edit the readme using AI ofcourse

Every “contribution” you make earns you badges like:

🏆 Fixed 10 Typos – Grammar police salute you!
🚀 Added 500 Emojis – Houston, we have a contribution!
☕ Coffee-Fueled Coder – 2 a.m. commits, fueled by caffeine and chaos.
🐦 Early Bird – You were here before it was cool.

And the best part? You can generate a shareable image — a fake contribution card to flex on your developer friends.

Because sometimes, instead of fighting absurdity… it’s more fun to join in and make it funnier.

👉 Try it here: https://readmehub.divyanshulohani.xyz/

The Hidden Message Beneath the Joke 💭

ReadmeHub isn’t just a meme project (okay, maybe 90% meme, 10% message). But it also says something about developer culture today.

The world of programming is increasingly gamified — GitHub streaks, LeetCode badges, AI-assisted commits, contribution graphs. Sometimes, we forget that code is supposed to solve problems, not just earn points.

ReadmeHub pokes fun at that obsession with metrics. It’s satire for anyone who has ever stared at their GitHub profile thinking,

“I need more green squares.”

"I need to have that perfect looking github graph"

It’s a reminder that your value as a developer isn’t measured in PR counts or stars. It’s measured by curiosity, learning, and the problems you solve — even if they’re small.

Ironically, by making a fake-contribution app, I ended up having deeper conversations with developers about real open-source contribution. Sometimes humor opens doors that serious rants can’t.

The Irony of It All

The funniest (and maybe saddest) realization? A parody app about fake contributions probably got more engagement than many genuine open-source repos do in a month.

But that’s also what makes developer culture fascinating — we love building weird things, just because we can.

Every viral project starts with a mix of humor and curiosity. Whether it’s a useless API that returns random cat facts, or a website that tells you “how many coffees you’ve coded today,” — it’s all part of the same creative chaos that fuels open source.

ReadmeHub fits right into that lineage — silly, smart, and just self-aware enough to make people smile.

Conclusion: What Hacktoberfest Still Means

At its core, Hacktoberfest is still a beautiful idea. It gets thousands of people writing code, exploring projects, and learning skills they’ll carry for life maybe we will see some more open source projects.

But maybe we all need a reminder: Contributions are more than commits — they’re collaboration, communication, and creativity combined. If you’re contributing to open source this October, do it for the right reasons: to learn, to share, to help.

And if you’re just here for the badges, emojis, and “README updates”… don’t worry — we’ve got you covered. Visit ReadmeHub and go wild. After all, sometimes the best way to make a point is to turn it into a punchline.

Now go and fix some typos while I find a repo that can run on my pc.

Implementing Real-Time Chat with SSE vs WebSockets (and Why I Chose One)

DivyanshuLohani — Mon, 15 Sep 2025 04:12:03 +0000

Every developer building a chat app eventually stumbles into the same rabbit hole: Do I use WebSockets or Server-Sent Events (SSE)? It sounds like a minor technical choice at first—just pick whichever tutorial looks nicer on YouTube and move on. But trust me, this one decision can quietly shape the scalability, complexity, and sanity of your project (and your future AWS bills if you pick wrong).

When I started working on real-time communication for my Django app, I had to make this exact decision. The app needed chat, but chat wasn’t the main feature just a nice to have. So naturally I didn't wnat to spend more time on selecting techonlogies and give it a whole new timeline.

In this article, we’ll dive deep into what real-time communication really is, explore how SSE and WebSockets work, compare them side by side, and finally, I’ll share why I picked SSE for my project (and why it was some sort of inspired by linkedin).

Deep Dive into SSE

How It Works

Sever Sent Events (SSE) is like an open door which the client makes to the server the open door only allows one way communication from server to the client not the other way around it sends messages its just another TCP connection which just has its end packet forgotten so it keeps on going.

It’s built on plain old HTTP, so you don’t need to break your brain setting up new protocols.

Code Example: SSE in Django

Server (Django view):

    from django.http import StreamingHttpResponse
    import time

    def sse_chat_stream(request):
        def event_stream():
            while True:
                # In reality, pull from Redis/pub-sub
                yield f"data: New message at {time.time()}\n\n"
                time.sleep(2)

        return StreamingHttpResponse(event_stream(), content_type='text/event-stream')

Client (JavaScript):

    const eventSource = new EventSource("/chat/stream/");

    eventSource.onmessage = function(event) {
        console.log("New message:", event.data);
    };

That’s it. You’ve got a real-time connection with about 20 lines of code. (Which is about 50 fewer than WebSockets usually require.)

Pros of SSE

Simple and easy to impliment with very less of a overhaul.
One way communication mostly realtime but this can become a down side too
Your browser autoretrys the connection in an event of failure
Almost all browsers support it (Almost is due to IE)

Cons of SSE

So one way communication is also pro but can be a con depending on your project.
Not great if your app relies on the milisecond the message is sent you have to recieve it
No binary data (text only). If you need binary, look elsewhere. but can be useful

But here’s the kicker: for 80% of “real-time” needs—like chats that aren’t the entire focus of the product—SSE is more than enough you don't need NASA like communication that every millisecond matters.

Deep Dive into WebSockets

How It Works

WebSockets are like having a direct phone line between client and server. Once connected, both can talk freely, as much as they want, whenever they want, just a private, always-on conversation.

It’s a separate protocol that starts with an HTTP handshake and then upgrades to a persistent TCP connection.

Code Example: WebSockets

Server (Node.js with ws*):*

    const WebSocket = require('ws');
    const wss = new WebSocket.Server({ port: 8080 });

    wss.on('connection', ws => {
      ws.on('message', message => {
        console.log(`Received: ${message}`);
        ws.send(`Echo: ${message}`);
      });
    });

Client:

    const socket = new WebSocket("ws://localhost:8080");

    socket.onopen = () => socket.send("Hello Server");
    socket.onmessage = event => console.log(event.data);

Now you’ve got two-way communication—chat, games, collaborative docs, you name it.

Pros of WebSockets

Both ways of communication can happen any time.
Latency is very low almost realtime
Perfect for chat apps if your main focus is reducing latency to the 10th of a second
Binary data handling is supported.

Cons of WebSockets

Complex to scale and has lots of network limitations
Requires extra setup in case of django it can be another level of headache
Its too powerful for simple apps and comes with the same cost.

My Real-World Implementation

Here’s the context: I was building a Django app where chat was a nice-to-have feature, not the core. Think of it as the beverages that come in a Burger King combo not needed but good to have. (Yes I don't like soft drinks that much)

I first considered WebSockets. They’re the gold standard for chat, after all. But as I dug deeper, I realized setting up Django Channels, handling scaling with Redis, configuring sticky sessions, and then debugging it all would be like bringing a rocket launcher to open a soda can.

Then I started researching more on the topic and did some reverse engineering on apps I use such as linkedin what they use in their apps for the same I found that linkedin used SSE for the chats and it just works very well I know they have put a lot of thought in selecting this as their primary system but it gave me a way then I learned about SSE and implimented it in my app. It has allowed me to have the following:

Real-time server → client updates.
Super easy scaling with existing HTTP infra.
Less complexity to manage.

And to be honest that's all I need for my app I don't need like crazy good realtime updates its not Telegram or Discord. All I do is create a POST request for new message from clients and using simple redis queue and some pubsub magic it just works.

Simple. Effective. And no therapy sessions required.

Minimal Chat with SSE

Server (Django + Redis pub/sub):

    import json
    import redis
    from django.http import StreamingHttpResponse

    redis_client = redis.StrictRedis()

    def stream(request, room_id):
        def event_stream():
            pubsub = redis_client.pubsub()
            pubsub.subscribe(f"chat_{room_id}")
            for message in pubsub.listen():
                if message['type'] == 'message':
                    yield f"data: {message['data'].decode()}\n\n"
        return StreamingHttpResponse(event_stream(), content_type="text/event-stream")

Client:

    const eventSource = new EventSource(`/chat/stream/room123/`);

    eventSource.onmessage = function(event) {
        const message = JSON.parse(event.data);
        console.log("New message:", message.text);
    };

    // Sending messages
    document.querySelector("#send").onclick = () => {
        fetch("/chat/send/", {
            method: "POST",
            body: JSON.stringify({ text: "Hello world" }),
        });
    };

Lessons Learned & Best Practices

Start simple. Don’t dive into WebSockets unless you truly need bidirectional communication they just require lot more effort than they should. (If all you want is notifications, SSE is your friend.)
Scale smartly. Use Redis pub/sub for message distribution. Throw in Nginx as a reverse proxy, and you’re good for a long time.
Fallbacks matter. If SSE fails (say, old browsers), fall back to long-polling. Your users don’t care about protocols; they just want their message to show up.
Measure before you optimize. Don’t assume you’ll have 10 million concurrent users tomorrow. Pick the tool that works now and is easy to evolve later.

Conclusion

To sum it up:

SSE: Lightweight, simple, perfect for one-way updates.
WebSockets: Powerful, full-duplex, perfect for heavy chat/gaming apps.

For my project, I chose SSE—because it was easy, scalable enough, and fit my use case without unnecessary complexity.

Real-time communication isn’t about flexing the fanciest tech—it’s about delivering the right experience without making your life miserable as a developer.

So, what about you? Did you pick SSE or WebSockets for your project? Let me know—I’d love to hear your war stories.

How Shipping Code in a Rush Can Cause Uncalculated Losses

DivyanshuLohani — Tue, 09 Sep 2025 11:02:24 +0000

There’s a golden rule in software development—something every junior developer learns within their first month of writing code: “Never ship untested code to production.”

It sounds simple enough, right? Like “look both sides before crosing a road” or “don't use metal in a microwave” Yet, every now and then, giant corporations (with teams of thousands of developers, mind you) somehow forget this rule. And when they do, the results are usually hilarious for users and catastrophic for the company’s balance sheet.

This past week, Reliance JioMart (yes, the Reliance-backed e-commerce giant) may have had their mishappening. Officially, JioMart hasn’t said a word about it (and they probably never will—because who likes to admit they left the door wide open?). But users discovered something that looked suspiciously like a bug, and the telegram mafia did what it always does best: exploit it, and turn it into flowing cash

The Incident: When Offer Turned into Infinite Money Glitches

On the surface, JioMart’s scheme looked innocent enough. They rolled out a promotion saying: spend ₹101 or more, and you’d get ₹100 off. Great deal, right? (No, not even if this was not the incident) The kind that makes you add that extra packet of biscuits to your cart just to qualify.

Except… the way they set it up apparently had a fatal flaw. The promotional link they sent wasn’t just a one-time coupon link—it was reportedly a coupon factory. Every time you clicked it (or tweaked it just a little), boom: a brand-new coupon worth ₹100 landed in your account. Unlimited. Endless. Like Willy Wonka’s chocolate river, but instead of chocolate, it was discount codes.

And because the internet is faster at finding loopholes than companies are at closing them, people quickly caught on. Telegram groups saw a great opportunity and turned it to a cash thing. They started offering hundrends even thousands of cupons for free and once they ran out(which was pretty quick) they started selling them ₹10–20 each. Think about that: a ₹100 coupon going for just ₹10 or even free if you were lucky and quick. That’s not just a discount—that’s arbitrage, baby.

In effect, JioMart’s marketing campaign accidentally created a black market economy inside Telegram. Imagine explaining that in a board meeting:

“Sir, our competitors are not the issue. Our biggest competitor is now a Telegram group run by some college kids selling our coupons at 90% off.”

What (Allegedly) Went Wrong

From digging into the reports (and yes, some curious minds actually tested the link), the bug seemed almost embarrassingly simple. The link they sent out had a query parameter which likely was a tracking id for the specific customer but was not checked.

But here’s the kicker: the parameter could accept any random value and still generate a fresh coupon code like a coupon creating machine. Now, as developers, we can all imagine how this might have happened. Maybe someone forgot to add a validation check. Maybe QA was skipped because deadlines were looming. Or maybe the dev team thought, “Who’s going to notice?” (Answer: everyone. Everyone noticed.)

It raises the question: what kind of logic was powering this system? Was it something like:

if (request.hasQueryParam) {
    generateCoupon();
}

Because that’s what it felt like. One missing if condition. One missing database check. One small oversight that spiraled into thousands of coupons.

And the funny part? This wasn’t some deep, sophisticated hack that required genius-level skills. No, this was low-hanging fruit. It’s the digital equivalent of leaving your shop unlocked at night with a sign saying, “Please don’t steal.”

The Aftermath: Servers Down, Coupons Everywhere

As word spread, chaos followed. JioMart’s cart service and related systems reportedly buckled under the load. Think about it: hundreds (maybe thousands) of people hammering the system, generating coupon after coupon, placing order after order.

For customers, it was like Diwali came few weeks early. For JioMart, it must have looked like a DDoS attack—but powered not by bots, but by real coupon hungry people.

Financially, the losses could have been massive. Even if only a fraction of the coupons were redeemed, each represented ₹100 in lost revenue. Multiply that by thousands, and you’re staring at some very uncomfortable spreadsheets.

JioMart has not confirmed the incident. Which makes sense. You don’t exactly want your brand trending on Twitter under #UnlimitedCoupons. Admitting it would be like saying, “Yeah, we accidentally let people print money for a day. Oops.”

But interestingly, the next day the link magically stopped working. Coincidence? Or a silent fix? I’ll let you decide. (Spoiler: it was a fix.). Still some sort of bug or intended feature like everyday you would click the same link you would still get a brand new coupon but seems like its intended working.

Why This Matters (and Why It’s Funny)

On one level, this is hilarious. Big company leaves giant hole, users exploit it, chaos ensues. It’s the kind of story that makes developers shake their heads and laugh nervously, because deep down, we all know: this could happen to any of us if we’re not careful.

But on another level, it’s dead serious. This wasn’t just a minor UI glitch or a typo in the app. This was a systemic design flaw—the kind that directly hits revenue.

The sarcasm writes itself:

“Why bother with rate limiting? Let everyone generate coupons like new orders”
“Who needs backend validation when you can trust query parameters, the most trustworthy part of the internet?”
“Unit testing? Nah. Let production users do the testing for us. They’ll find bugs faster anyway.”

Lessons for Developers (and Corporates Who Don’t Listen)

Validation is sacred. Never trust input from the client side. Ever. It doesn’t matter if it’s a coupon code, a price, or a user ID—if your backend just accepts it blindly, you’re inviting chaos.
Abuse scenarios are real. When designing a system, don’t just think, “What’s the happy path?” Think, “How would someone misuse this?” Because trust me, someone will.
Testing isn’t optional. Yes, deadlines are tight. Yes, management wants the feature out “yesterday.” But the cost of rushing can dwarf the cost of a delay. Which would you rather explain in a meeting: “We’re shipping a week late,” or “We accidentally lost crores because our coupon system was a slot machine”?
Transparency matters (sometimes). JioMart chose silence, which is understandable. But imagine the goodwill they could have earned by acknowledging it lightly—“Hey, we goofed, it’s fixed, no free money anymore.” At least it would have made them human.

The Bigger Picture

Incidents like this aren’t rare. History is full of “fun” bugs that cost companies millions:

In 2014, a bug in Shoppers Stop’s online store let people order items worth thousands for ₹1.
In 2019, a Paytm glitch allowed people to generate unlimited movie tickets using promo codes.
And who can forget the infamous “Amazon accidentally listed expensive cameras for $94” bug? (Someone, somewhere, got Christmas and Diwali rolled into one.)

The common thread? Rushing to production without proper testing. It’s the software equivalent of building a skyscraper but forgetting to check if the elevator works.

Closing Thoughts

Whether or not JioMart ever admits it, this was an interesting choke point in their system design—a perfect example of how one unchecked assumption can snowball into a full-blown crisis.

For developers, it’s a cautionary tale. For users, it was a once-in-a-lifetime sale. And for JioMart, it’s probably a very expensive lesson written into some internal post-mortem doc with the title: “Why We Test Promo Systems Before Sending Them to 100 Million Users.”

So the next time you’re tempted to push that untested code to production because “it’s just a small feature,” remember JioMart’s infinite coupon generator. In the world of software, shortcuts aren’t just risky—they’re sometimes very, very costly.

Or, to put it simply: you can either test your code, or your users will test it for you—and they’ll do it with a lot more creativity.

Why MVP Mindset Saves Projects (And How I Apply It)

DivyanshuLohani — Tue, 12 Aug 2025 11:08:06 +0000

The Project Graveyard in My Github

I have a lot of unfinished projects in my GitHub. They are digital tombstones of grand ambitions that died somewhere between "revolutionary idea" and "hmm, maybe I need user authentication AND real-time chat AND AI integration AND..." everything I can think of during the planing phase and only have kanban boards or todo lists for them never got to be real.

Sound familiar?

For years, I was that developer who'd start projects with a mental feature list longer than a CVS receipt. I'd spend weeks architecting the perfect system, planning for edge cases that might never happen, and building features "just in case." The result? A graveyard of half-built applications and a growing sense that I couldn't finish anything.

Then I discovered the MVP mindset. Not just as a business concept, but as a personal productivity philosophy. And it changed everything.

What MVP Actually Means

Most people think MVP means "build something basic and hope for the best." That's wrong.

MVP means building the smallest thing that solves a real problem and gives you real feedback. It's not about being lazy or cutting corners—it's about being ruthlessly focused on what actually matters.

The skateboard-to-car analogy gets thrown around a lot, but here's what it really taught me: each iteration should be a complete, working solution. A skateboard gets you from point A to point B. So does a car. But you learn different things from each version. The way you maintain balance on a skateboard is not the same as gearing up in a car.

My mistake for years was trying to build the car from day one. Spoiler alert: it doesn't work and after this realization I belive it will never work projects built from ground up should be treated like wheels without wheels skateboard or cars are just not possible.

The Project That Actually Shipped

Last year, I had an idea for a expesne management app specifically for me. My initial plan was insane:

GitHub integration
Passbook integration
Accounts managemnet
Todo Apps
Custom admin dashboard
AI-powered suggestions
Native Mobile app
Dark mode (obviously)
Kanban boards
Budget system
Reports and analytics

I spent three weeks just setting up the database schema. Then I realized I was doing it again—building the app which is only needed by me or maybe few others when I launch

So I stopped. Started over. Built the dumbest version possible: a single page where you could add expenses only no balance maintence nothing. That's it. No database, just localStorage. No user accounts, no fancy UI. Just a working app for tracking transactions and exporting them

I shipped it in two days.

And you know what? People used it. My friends started asking for the link. I got feedback I never expected. Some wanted categories. Others wanted due dates. A few asked about multiple accounts features

But here's the key: I learned what people actually need, not what my delusional brain thought they needed.

How I Apply MVP Thinking Now

1. The "One Problem" Rule

Every project starts with one question: What's the ONE problem this solves? Not five problems. Not "it could also do this and that." One problem. My current project is expense tracker. The one problem it solves: I keep forgetting just stroing expense and nothing more than that.

That's it. Not "social media for sharing things" or "Bank account passbook" Just "store and generate csvs of your transactions."

2. The 80/20 Feature Cut

I list every feature I can imagine, then cross out 80% of them.

The remaining 20% becomes version 1. The crossed-out features? They go in a "maybe later" file. Most of the time, "later" never comes—and that's perfectly fine that feature may not be worth that time and effort maybe it will become a feature that is just there and only you use it and no one else which is obviously bad.

3. The Two-Week Test

If I can't build a working version in two weeks, the scope is too big. This isn't about rushing or cutting quality. It's about being realistic. Two weeks forces me to focus on what's actually essential versus what's just nice to have and not waste time in thinking peculiar edge cases which may be only hypothetical.

4. The "Embarrassing" Launch

I launch when I'm slightly embarrassed by how basic it looks. This was hard to learn. I'm a perfectionist since I've been in my mind. But I realized that "slightly embarrassing" to me is often "perfectly adequate" to users what I seem imprefect everyone using my app is fine with like I still think the UI could be way better but it works and helps me focus on features first. And shipping something imperfect beats not shipping anything perfect.

The Compound Effect of Small Wins

Here's what I didn't expect: shipping small things consistently builds momentum faster than planning big things perfectly. When you plan things you get into a world where everything seems like ideal like the bodies in physics they do not apply in real world and maybe are too redundent for users like I told earlier some features may seem apealing to you but may not be useful for the users.

Every completed project teaches you something. Every launch gives you confidence. Every piece of feedback makes the next version better and if you only plan and plan you will only plan and gain no expeirence in theory everything seems very easy like only I have to push it to vercel or netlify and the project is deployed but what if the time comes and you have to run it on a custom VPS how will you be able to do that.

My unfinished projects taught me nothing except how to start things. My finished MVPs taught me how products actually work in the real world and what to expect when deploying them instead of thinking this feature would be a great thing or like make my app seem better to users as a solo developer you can not know if what are you thinking will be appealing to users hence you need to launch the bare minimum to get the things your users think what they actually need and what are just nice to have.

Final Thoughts

The MVP mindset isn't just about building products faster (though it does that). It's about building products that people actually want what makes your core idea speak rather than a polished ui of a similar kind of app.

Every feature you don't build is a feature that can't break, can't confuse users, and can't distract from your core value proposition. Constraints force creativity. Limitations inspire focus. It helps you to be more productive and a better person in hitting the deadlines better.

Your first version doesn't need to be your final vision. It just needs to be the first step toward it. So what's your skateboard? What's the simplest thing you can build that solves a real problem for real people?

Stop planning the car. Start building the skateboard it will then lead to better car than you expect your car to be it will not just run it will break all the records

TL;DR: MVP isn't about building cheap products—it's about learning fast and building what people actually want. Start small, ship quickly, iterate based on real feedback.

From Web to Mobile: Building PWAs with Next.js & Bubblewrap

DivyanshuLohani — Tue, 17 Jun 2025 14:19:01 +0000

The Realization That Hit Me Like a Truck

So there I was, scrolling through my phone, and I noticed something weird. Almost every "app" I was using daily wasn't really an app—it was just a website pretending to be one. Twitter, Instagram, even some banking apps. They loaded fast, worked offline, and felt native.

That's when it clicked: Progressive Web Apps (PWAs).

I'd been building React/Next.js apps for years, but I was missing this whole world where you could take your web app and make it feel like a proper mobile app. No app store approval hell. No learning Swift or Kotlin. Just good old web tech doing mobile things.

Wait, What Actually IS a PWA?

Okay, so before I dive into the how-to, let me break down what PWAs actually are—because I definitely overthought this at first.

A PWA is basically a website that acts like a mobile app. It can:

Install on your phone like a real app
Work offline (kind of)
Send push notifications
Access device features like camera, GPS, etc.
Feel smooth and native-ish

The magic happens through something called a Service Worker (handles offline stuff) and a Web App Manifest (tells the browser how to behave like an app).

And the best part? If you're already building with Next.js, you're like 70% there already.

Why I Went Down This Rabbit Hole

I had this side project that worked great on desktop, but mobile users kept asking "where's the app?" Every time someone visited on mobile, they'd try to find it in the app store.

Building separate iOS and Android apps felt like overkill for what was essentially a web app. Enter PWAs and Bubblewrap—Google's tool that takes your PWA and wraps it into a proper Android app you can actually publish to the Play Store.

Step 1: Icons (Because First Impressions Matter)

You can't have a proper app without proper icons. I used to spend hours in Figma creating different icon sizes, but there's a much easier way.

Head over to https://pwa-icon-generator.vercel.app/ and upload your base icon. This tool generates all the sizes you need—from tiny 16x16 favicons to massive 512x512 app icons.

Download the zip, extract it to your public directory, and boom—icon problem solved.

Step 2: The Manifest (Next.js Makes This Easy)

Here's where Next.js really shines. Instead of manually creating a manifest.json file, you can create a manifest.ts file in your app directory and Next.js will automatically generate the webmanifest for you.

import type { MetadataRoute } from "next";

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "My Awesome App",
    short_name: "AwesomeApp",
    description: "A really cool web application",
    start_url: "/",
    display: "standalone",
    background_color: "#ffffff",
    theme_color: "#2563eb",
    orientation: "portrait",
    lang: "en-US",
    scope: "/",
    id: "/",
    icons: [
      {
        src: "/icon512_maskable.png",
        sizes: "512x512",
        type: "image/png",
      },
      {
        src: "/icon192.png",
        sizes: "192x192",
        type: "image/png",
      },
    ],
  };
}

The display: "standalone" is crucial—it tells the browser to hide the address bar and make your app feel like a native one.

Step 3: Enter Bubblewrap (The Game Changer)

This is where the magic happens. Bubblewrap is a CLI tool that takes your PWA and packages it into a proper Android app.

First, install it:

npm install -g @bubblewrap/cli

IMPORTANT: Do NOT run this in your Next.js project root. Seriously. I learned this the hard way when I accidentally pushed Android build files to production and my app crashed. Create a separate folder for this.

mkdir my-app-android
cd my-app-android
bubblewrap init --manifest https://yourapp.com/manifest.webmanifest

Bubblewrap will ask you a bunch of questions—app name, package name, keystore password, etc. Just answer honestly, and it'll set up the entire Android project structure for you.

[Image placeholder: Terminal showing bubblewrap init process]

Step 4: Building Your App

Once the setup is done, building is surprisingly simple:

bubblewrap build

This generates:

An APK file (for direct installation)
An AAB file (for Play Store upload)
All the necessary Android project files

The build process takes a few minutes, but when it's done, you have a real Android app that you can install on any device.

Step 5: The URL Bar Problem (And How to Fix It)

Here's something that tripped me up initially. Even after all this setup, your app might still show that ugly browser address bar. That's because Android needs to verify that your website actually "owns" this app.

You fix this by creating a file at public/.well-known/assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.myapp.example.twa",
            "sha256_cert_fingerprints": [
                "A1:B2:C3:D4:E5:F6:G7:H8:I9:J0:K1:L2:M3:N4:O5:P6:Q7:R8:S9:T0:U1:V2:W3:X4:Y5:Z6"
            ]
        }
    },
    {
        "relation": [
            "check_validation"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.myapp.example.twa"
        }
    }
]

To get that SHA256 fingerprint, run this command in your Android project directory:

keytool -list -v -keystore android.keystore

Enter the password you set during bubblewrap init, and you'll see output like this:

Certificate fingerprints:
    SHA1: 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78
    SHA256: A1:B2:C3:D4:E5:F6:G7:H8:I9:J0:K1:L2:M3:N4:O5:P6:Q7:R8:S9:T0:U1:V2:W3:X4:Y5:Z6

Copy that SHA256 value into your assetlinks.json file.

The Play Store Gotcha

If you're planning to publish to the Google Play Store, there's one more step. Google re-signs your app with their own key, so you'll need to add their SHA256 fingerprint to your assetlinks.json file as well.

You can find this in the Google Play Console under Setup → App Signing. Just add it as a second entry in the fingerprints array. A detailed guide

What Actually Changed for Me

After going through this whole process, here's what I gained:

Real app experience: Users can install it from the Play Store, it appears in their app drawer, and it feels native.
Better engagement: People are way more likely to use something that's "installed" vs bookmarked.
Offline capability: With service workers, core functionality works even without internet.
One codebase: I'm maintaining one Next.js app instead of separate web and mobile codebases.

The Reality Check

Let's be honest—PWAs aren't perfect. iOS support is still weird (thanks, Apple). Some device features are limited. And you'll still need to understand Android development concepts if you want to customize things.

But for most web apps that want mobile presence, this approach is so much faster than building separate native apps.

Conclusion

So yeah—PWAs aren't just a buzzword. If you're already building with Next.js and want to tap into the mobile app ecosystem without learning entirely new technologies, this is probably your best bet.

The whole process took me maybe 3-4 hours from start to finish (including the learning curve and that one time I accidentally nuked my build folder).

I'm still experimenting with advanced PWA features like background sync and push notifications, but so far, this has been one of the smoothest paths from web to mobile I've ever taken.

If you're sitting on a Next.js app wondering how to make it "feel more appy"—maybe it's time to go PWA.

Building Your Online Dev Identity (Before It's Too Late)

DivyanshuLohani — Mon, 09 Jun 2025 06:57:05 +0000

In 2025, Your Resume is Your Feed

The best job offer you can get today isn't from a fancy MNC or a funded startup—it's from yourself, from the brand you've built online. Having your own identity online, shaped not by a company or a brand but by your own presence, is now a legitimate career path. It takes time, no doubt. But if you don't start today, it'll always stay "someday."

The world has shifted. Traditional hiring processes are broken. HR departments are drowning in applications, and most resumes never even get seen by human eyes. Meanwhile, the most interesting opportunities are happening in DMs, through network connections, and from people who've been following your work for months. Your GitHub contributions, your blog posts, your hot takes on the latest JavaScript framework—that's your real resume now.

My Regret (and How I Fixed It)

I've been into development for over 6 years. I used to think, "Why post online? Who cares? If I'm good, people will find me." That's not how it works.

For years, I was the typical "head down, code hard" developer. I believed in meritocracy—that good work speaks for itself. I'd build amazing projects, solve complex problems, and then... nothing. No one knew about it except my immediate team. I was essentially invisible in an industry where visibility increasingly matters.

The wake-up call came when I saw junior developers with half my experience landing better opportunities simply because they had an online presence. They weren't necessarily better developers, but they were better at showing their work. That stung, but it was the reality check I needed.

In 2023, I realized the harsh truth: No one is going to dream about you and magically send an opportunity your way. You have to tell the world, again and again, that you exist. And so, in 2024, I made a shift.

I started posting updates about my dev projects, small wins, bugs I fixed, new tech I was trying—all on X (formerly Twitter). Then came blog posts: things I built, lessons learned, opinion pieces on tools, tech, or just stuff trending in the dev space. Hackathon updates, micro-tutorials—basically anything I was doing or learning.

The hardest part? Getting over the imposter syndrome. Who was I to have opinions about React when Dan Abramov exists? Who cares about my struggles with Docker when there are experts everywhere? But here's the thing—beginners and intermediate developers learn better from people just a step ahead of them, not from the untouchable experts.

Talking to a Wall (At First)

nitially? It felt like shouting into a void. No followers. No engagement. Maybe a cousin would like it once in a while. But I kept writing.

Those first few months were brutal for the ego. I'd spend hours crafting what I thought was a brilliant post about some obscure bug I'd fixed, only to get zero reactions. I started questioning everything—was my content bad? Was I posting at the wrong times? Was I even cut out for this?

I experimented with reels and YouTube videos—but honestly, I was spending more time editing than coding. The pressure to make things “viral” took away from the joy of development itself. So I backed off from daily content and chose a sustainable pace instead. (Yes, you can still check out my YouTube and Instagram)

This was a crucial lesson: sustainability beats perfection. I'd rather post one genuine article a week than burn out trying to create daily "content" that felt forced. The algorithm rewards consistency, but your sanity should come first.

Then, out of nowhere, one article hit. It wasn't even my magnum opus—just a breakdown of a Skribbl clone I had built, paired with a few improvements I was thinking of. It was honest, scrappy, and unpolished—but real. And it resonated. Slowly, views started to roll in. A few comments, some shares. Nothing viral—just 500–600 views. But when you're starting from zero, that's momentum. It meant someone out there was listening. It felt validating.

That article taught me something important: authenticity beats polish. People connect with real struggles and genuine insights more than they connect with perfectly curated content.

The Snowball Effect

Now, even when I don’t have time for constant updates, I make sure I push 2–3 solid articles a month. These usually focus on a few key areas:

Problems I’m facing – Whether it’s a tricky bug, a frustrating tool, or just a confusing decision I had to make, I document it. Writing about these challenges not only helps others but helps me make sense of my process too.
How I solved something weird – When something breaks and I fix it in a way that feels clever (or stupid), I write it down. These kinds of posts are always relatable to other devs and spark the best discussions.
Random insights – Sometimes I notice a pattern, trend, or just have a thought that might help others. These posts are spontaneous but surprisingly well received.

This isn’t about going viral. I’m not trying to be the next dev influencer. It’s about being consistent—because consistency builds presence. The more I post, the more searchable and discoverable I become. And maybe someday, that consistency becomes the reason someone reaches out with a cool opportunity.

So How Do You Start?

There is nothing I would say that is a secret sauce that I would tell you. You already know what you have to do and you're just lazy or don't feel like doing it but here are the steps anyways if you want there is nothing fancy.

Pick a Platform: X/Twitter is great for daily thoughts. Dev.to, Medium, Hashnode for longer articles. YouTube/Instagram if you like visual formats.
Share What You Do: Doesn’t have to be mind-blowing. Ship something? Share it. Broke something? Share that too.
Engage: Comment on others' posts. Be part of the community. You’ll learn and get visibility.
Repeat: Keep showing up, even if it feels like no one’s watching.

Why It Matters

When you have an online identity, it matters way more than you think:

People trust you more because they see the proof of work online and are confident on you and they can be sure you will be the one to finish their job
Recruiters find you, not the other way around, its same as you know your teacher but the teacher you know teaches hundreds of kids so you have to be special to be in his eyes.
Once you gain traction you will also start getting inboud requests no more hassle of going on to freelancing platforms to find work your inbox will be filled of it.
You become what you wanted to become in less time because these things put up a high impact.

Final Thoughts

If you’re learning dev or already good at it, your work deserves an audience. Start small. Stay consistent. Don’t care about metrics at first—just build.

Your online presence is like compound interest: the earlier you start, the bigger it grows.

TL;DR: Start building your personal dev brand today. The internet won’t find you on its own.

#PersonalBranding #DevJourney #ContentCreation #DeveloperLife

Payment Gateway Chaos: How I Converted Multiple Providers into One

DivyanshuLohani — Sun, 25 May 2025 20:25:35 +0000

Picture this: You're building an app, everything's going smooth, and then your client drops the bomb — "Can we support PayU, Stripe, and maybe Razorpay too? You know, for flexibility."

Suddenly you're staring at three different APIs, each with their own quirks, data formats, and authentication methods. PayU wants a hash, Stripe wants sessions, and don't even get me started on their different ways of handling amounts (seriously, who decided some should use paise and others should use rupees?).

I recently found myself in this exact situation while working on a project, and instead of copy-pasting code like a barbarian, I decided to build something that wouldn't make me want to throw my laptop out the window every time I needed to add a new gateway.

The Problem: Payment Gateway Spaghetti

Most developers handle multiple payment gateways like this:

Create separate functions for each gateway
Copy-paste similar logic everywhere
End up with a maintenance nightmare
Cry a little when requirements change

There's got to be a better way, right? Right?

The Solution: Abstract the Chaos Away

Here's the pattern that saved my sanity (and probably my career):

Step 1: Create a Universal Payment Interface

First, I created a common type that could handle all payment gateways without losing my mind:

    export interface PurchaseTransactionData {
      session: any;
      itemId: string;
      amount: number;
      itemType: PurchaseType;
      productinfo: string;
      gateway: PaymentGateway;
    }

    export interface PaymentData {
      // Common fields for all payment gateways
      gateway: PaymentGateway;
      transactionId: string;
      amount?: string;
      productinfo?: string;
      firstname?: string;
      email?: string;
      phone?: string;
      surl?: string;
      furl?: string;

      // PayU specific fields
      txnid?: string;
      hash?: string;
      key?: string;

      // Stripe specific fields
      stripePayUrl?: string;
      publishableKey?: string;
    }

Is it perfect? No. Does it work? Absolutely. The key insight here is that you need one interface to rule them all — even if some fields are gateway-specific.

Step 2: The Abstract Base Class (The Real MVP)

    import { PaymentData, PurchaseTransactionData } from "@/types/payment";
    import { prisma, PaymentStatus } from "@repo/db";

    export abstract class PaymentGatewayBase {
      abstract createPaymentData(
        transaction: any,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData>;

      async createTransaction(transactionData: PurchaseTransactionData) {
        return await prisma.paymentTransaction.create({
          data: {
            userId: transactionData.session.user.id,
            status: PaymentStatus.PENDING,
            amount: transactionData.amount,
            gateway: transactionData.gateway,
            itemId: transactionData.itemId,
            itemType: transactionData.itemType,
          },
        });
      }
    }

This abstract class does two things:

Forces every gateway implementation to have a createPaymentData method
Handles the common transaction creation logic so you don't repeat yourself

Step 3: Gateway Implementations (Where the Magic Happens)

Now here's where it gets fun. Each gateway just extends the base class and implements their specific logic:

PayU Implementation:

    export class PayUGateway extends PaymentGatewayBase {
      public async createPaymentData(
        transaction: any,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData> {
        const { merchantKey, merchantSalt } = await getPayUCredentials();

        const data = {
          key: merchantKey,
          gateway: PaymentGateway.PAYU,
          transactionId: transaction.id,
          txnid: transaction.id,
          amount: (transaction.amount / 100).toString(), // PAYU wants floats
          productinfo: transactionData.productinfo,
          firstname: transactionData.session.user.name ?? "John Doe",
          email: transactionData.session.user.email!,
          phone: "1234567890",
          surl: `${process.env.NEXT_PUBLIC_SITE_URL}/api/payu-response?status=success`,
          furl: `${process.env.NEXT_PUBLIC_SITE_URL}/api/payu-response?status=failure`,
          hash: "",
        };

        data.hash = generateHash(data, merchantSalt, merchantKey);
        return data;
      }
    }

Stripe Implementation:

    export class StripeGateway extends PaymentGatewayBase {
      public async createPaymentData(
        transaction: PaymentTransaction,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData> {
        const stripeCredentials = await getStripeCredentials();
        const stripe = new Stripe(stripeCredentials.secretKey);

        const session = await stripe.checkout.sessions.create({
          mode: "payment",
          customer_email: transactionData.session.user.email,
          client_reference_id: transaction.id,
          line_items: [
            {
              price_data: {
                currency: "inr",
                product_data: {
                  name: transactionData.productinfo,
                },
                unit_amount: transactionData.amount, // Stripe wants paise
              },
              quantity: 1,
            },
          ],
          billing_address_collection: "required",
          success_url: `${process.env.NEXT_PUBLIC_SITE_URL}/shop/?transactionId=${transaction.id}`,
          cancel_url: `${process.env.NEXT_PUBLIC_SITE_URL}/api/stripe-response?transactionId=${transaction.id}`,
        });

        return {
          gateway: PaymentGateway.STRIPE,
          transactionId: transaction.id,
          stripePayUrl: session.url || "",
          publishableKey: process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY!,
        };
      }
    }

Step 4: The Factory Pattern (Because We're Not Animals)

But wait, there's more! Manually instantiating gateway classes everywhere is still messy. Enter the Factory pattern:

    import { PaymentGateway } from "@repo/db";
    import "server-only";
    import { PaymentGatewayBase } from "./payment-base";
    import { PayUGateway } from "./payu";
    import { StripeGateway } from "./stripe";

    export class PaymentGatewayFactory {
      static create(gateway: PaymentGateway): PaymentGatewayBase {
        switch (gateway) {
          case PaymentGateway.PAYU:
            return new PayUGateway();
          case PaymentGateway.STRIPE:
            return new StripeGateway();
          default:
            throw new Error(`Unsupported payment gateway: ${gateway}`);
        }
      }
    }

Now your server-side code becomes beautifully simple:

    const gateway = PaymentGatewayFactory.create(selectedGateway);
    const transaction = await gateway.createTransaction(transactionData);
    const paymentData = await gateway.createPaymentData(transaction, transactionData);

Step 5: Frontend Magic (The Cherry on Top)

The frontend doesn't need to know about your fancy abstractions. It just needs to handle the response and redirect users accordingly:

    if (paymentResult.success) {
      switch (paymentResult.paymentData?.gateway) {
        case "PAYU":
          redirectToPaymentPage(paymentResult.paymentData);
          break;
        case "STRIPE":
          window.location.href = 
            paymentResult.paymentData?.stripePayUrl || window.location.href;
          break;
        default:
          throw new Error("Unsupported payment gateway");
      }
    }

Each gateway gets its own redirect logic, but the main flow stays clean and predictable.

Step 6: Adding New Gateways (The Real Test)

Now adding a new payment gateway is genuinely simple:

Create a new class that extends PaymentGatewayBase
Implement the createPaymentData method
Add the case to your Factory class
Add the frontend redirect logic
That's it. You're done.

Want to add Razorpay? Just create RazorpayGateway extends PaymentGatewayBase, add it to the factory, and handle the frontend redirect. No existing code needs to change.

The Beauty of This Approach

This pattern gives you:

Consistency: Every gateway follows the same contract
Maintainability: Common logic lives in one place
Scalability: Adding new gateways doesn't break existing code
Testability: You can mock the abstract class for unit tests
Sanity: You won't hate your life when requirements change

Conclusion

Payment gateway integration doesn't have to be a nightmare. With a little bit of abstraction and a lot of TypeScript magic, you can build something that's actually maintainable.

The next time someone asks you to "just add one more payment gateway," you can smile knowingly instead of updating your resume.

Now if you'll excuse me, I need to go figure out why Razorpay's webhook decided to stop working again. Some things never change.

My Experience with TurboRepo & Monorepos: From Chaos to Sanity

DivyanshuLohani — Sun, 20 Apr 2025 04:47:17 +0000

A Dev Setup That Started Like Everyone Else’s

If you’ve ever worked on a full-stack project, chances are your folder structure looked like this:

/client  
/server  
/README.md (you never updated)

And at first—it’s fine. Until one day, I was debugging something and realize that I am just copy-pasting the same utility function between folders and breaking the DRY rule.

Then the installs break. Then the dependency trees spiral. Then I am 10 commits deep into fixing a node_modules issue and forget what the feature even was.

Welcome to my life… until I discovered Monorepos.

Wait, What Even Is a Monorepo?

So, I had heard the term floating around in dev Twitter and Reddit threads, but I never really got it. I thought it was just one of those "enterprise-only" things Google does.

but it turend out—it’s just keeping all your packages, apps, and services in one codebase, organized and connected like a family that actually talks to each other.

You can share code. You can isolate builds. You can run tests on specific packages. And yeah, Google does it. That was enough to get me curious.

Enter: TurboRepo

I stumbled across TurboRepo, and the first thing I thought was:

“Wait, why didn’t anyone tell me about this sooner?”

It’s a high-performance build system for monorepos—designed to make your life less painful when managing multiple apps and packages in a single repo. And the cool part? It's designed for JS/TS devs like us.

No 20-step YAML configs. Just set up your pipeline, link things with workspaces, and boom—stuff starts working.

The Switch: Folder Chaos to Turbo Calm

I had an ongoing project with the usual split: one folder for the frontend (React), another for the backend (Express).

Converting that into a Turbo monorepo setup only took me an hour or two. (And that too with Express, which has like zero real monorepo resources out there—someone fix this please. (Article soon :)))

Now it looks more like:

/apps  
  /web  
  /api  
/packages  
  /ui  
  /utils  
  /config

And suddenly, my build scripts aren’t yelling at me. My eslint config is shared. And I'm not doing npm install in two places like an absolute fool.

The Real Benefits I Felt

Let’s be real, here’s what actually changed for me:

One place for all code: No more syncing packages manually or debugging two node_modules folders.
Code sharing became easy: Utils, types, and configs now live in one packages/ folder and are shared across both frontend and backend.
Less context switching: I don't need to cd into three places just to start the dev server.
My disaster folder got fixed: I once broke a project so badly because I didn’t understand workspaces properly. Turbo fixed that mess, cleaned up the structure, and gave me a fresh start.
Ease to Scale: Now it would be easier to add more things like admin or something like that.

Not All Rainbows

Turbo is powerful, but it’s also a bit opinionated. Some things still need digging around, especially if you’re working outside the Next.js happy path.

But once you get it running—it’s worth it.

(Also, don’t forget to cache smartly. Turbo's speed magic depends on it.)

Conclusion

So yeah—monorepos are not just for big corps. If you're building multi-package apps, it makes total sense even for solo devs or small teams. And TurboRepo? Chef's kiss. 🤌

I’m still experimenting and learning, especially with backend-heavy setups (looking at you, Express). But so far, I’d say this is one of the cleanest architectural decisions I’ve made in months.

If you’re stuck in the client-server folder spiral—maybe it’s time to go mono.

How I Built My Own CI/CD Pipeline for a Small Project (Because GitHub Said “No”)

DivyanshuLohani — Tue, 01 Apr 2025 07:12:15 +0000

Why I Ditched GitHub Actions

So long story short no one wants to make systems of their own and why should we there are great minds who have devoted years in perfecting it. Like most developers, my first instinct for CI/CD was to use GitHub Actions—it’s built-in, well-documented, and mostly reliable. Until it wasn’t.

For some unknown reason, my GitHub Actions got blocked. I submitted a support ticket, and after a quick look at GitHub’s response time (which was somewhere between a month and eternity), I knew I had to find another solution.

Waiting wasn’t an option. I needed continuous deployment now, (ego issues) not when GitHub finally decides to reply to my ticket.

So, I did what any frustrated developer would do—I built my own custom CI/CD pipeline from scratch.

Step 1: Setting Up My Own CI/CD Server

Since GitHub wasn’t going to help me, I set up a self-hosted deployment server using Express.js.

The goal was simple:

Whenever I push new code to my repository, my server should detect it.
It should pull the latest code, restart the app, and send me a notification if something fails.
No manual intervention. Just push and deploy. (and flex about pusing to production)

Sounds simple, right? It wasn’t.

Step 2: GitHub Webhooks

After some research, I discovered that GitHub provides webhooks, which can notify a server whenever specific events occur (like a push to the main branch or a pull request).

Setting Up the Webhook Listener

GitHub provides webhooks that trigger events whenever something happens in a repository, like pushing code, creating a pull request, or merging branches. My goal was to create a webhook that listens for a push event on the main branch, automatically pulling the latest code and redeploying the app.

First, I created a simple Express.js server and added an endpoint to listen for webhook events

Signature Verification Nightmare

If you think setting up a webhook is as easy as “just writing an endpoint,” let me save you some pain: GitHub doesn’t trust you.

Every webhook request from GitHub is signed using a secret key, and your server must verify this signature to ensure it’s a legitimate request.

Sounds simple? Not when the signature verification keeps failing.

For the next several hours, I tried everything:

Manually comparing signatures (they never matched).
Re-reading GitHub’s docs (which didn’t help).
Trying different hashing methods (none worked).

At one point, I even considered disabling verification entirely—which is a terrible idea unless you enjoy waking up to your server being hijacked.

Finally, after digging through GitHub issues, I realized my mistake:

I wasn’t using the exact raw body of the request for signature validation.
Instead, I was verifying the JSON-parsed body, which modifies the data slightly, causing the signature to mismatch.

A few painful adjustments later, my signature verification finally passed.

Automating the Deployment Process

With the webhook working, I automated the deployment with a series of commands:

Pull the latest code from the main branch of the repository
Install dependencies (if any new one was added)
Rebuild the project
Restart the server process to apply changes

With this setup, every time I pushed code to GitHub, my server automatically updated itself. No manual pulling, no SSH logins—just smooth, hands-free deployment.

Step 3: Email Notifications with Resend

I wanted immediate feedback if something went wrong, so I integrated Resend, a powerful email API.

Now, after every deployment, I get an email saying either:

✅ Deployment Successful – Life is good.
❌ Deployment Failed – Something broke, and I need to fix it ASAP.

This turned out to be one of the most useful parts of the setup because it meant I didn’t have to check manually whether deployments were working.

Lessons Learned (Or, What I’d Do Differently)

Building a custom CI/CD pipeline was an exciting journey, but it also came with its fair share of facepalm moments. Here’s what I took away from this experience and what I’d change next time.

1. A CI/CD Pipeline Is a Game Changer

Before this, I used to manually SSH into my server, pull updates, restart processes, and pray nothing broke. With this setup, deployments happen automatically, saving time and reducing human error. But what really hit me was how much mental overhead it removed—no more worrying about forgetting a step or accidentally deploying a broken commit.

That being said, there’s still a critical issue I didn’t expect and figured out while writing this post…

2. No Rollback Mechanism = Potential Disaster

As much as I love automation, it comes with a huge risk: what happens when a deployment fails and breaks the entire server? Right now, my setup blindly pulls the latest code and restarts the app. If there’s a fatal bug in the pushed code, the app crashes, and boom—downtime.

What I should have done:

Implement a rollback system: If deployment fails, revert to the last working commit instead of leaving the server broken.
Use a blue-green deployment approach: Deploy to a separate instance first, verify stability, and only then switch traffic over (maybe I will not go with this because I am a solo developer).

Next on my list is building a rollback mechanism that can detect failed deployments and automatically restore the last working version—because nothing’s worse than waking up to “Hey, your site is down.”

Conclusion

While most people rely on GitHub Actions, it’s not the only way to do CI/CD. Having a custom deployment pipeline gives you more control, fewer limitations, and zero dependencies on external services.

Sure, it took some effort to set up, but now I can deploy changes automatically and reliably—without waiting for GitHub support to wake up.

And while I figure out how to build a custom monitoring system, at least I have CI/CD fully automated.

The Vibe Coder: Non-Technical Developers and Mirage of AI

DivyanshuLohani — Sun, 30 Mar 2025 07:49:09 +0000

The Rise of "Vibe Coding"

So, "vibe coding" has been making waves recently, all thanks to some tweets about this guy who built an app using AI alone. No actual coding, just pure vibes. The result? His app got completely obliterated by the community and hackers alike. Turns out, AI may be smart, but it's not that smart.

But what exactly is vibe coding?

What is Vibe Coding?

Vibe coding is a development approach where instead of, you know, coding, you just prompt an AI model like ChatGPT or Gemini to generate everything for you. The AI writes the logic, structures the app, and spits out whatever you need.

Sounds futuristic, right? Just describe what you want, and boom—a full app ready to go. No need to learn syntax, algorithms, or debugging. Just vibes.

Except… reality isn’t so kind.

If you’ve spent any time on YouTube, you’ve probably seen those flashy AI coding videos:

“I built a full-stack app in 5 minutes using ChatGPT!”
“I made $10,000 with an AI-generated SaaS app!”
“No coding skills? No problem! AI will build your app for you!”

It all sounds too good to be true—and most of the time, it is.

Take, for example, the infamous case of a YouTuber who built an AI-generated startup. He used ChatGPT to code an entire project, launched it, and bragged about how easy it was. The catch? Within days, hackers tore the app apart due to security flaws, and the entire thing crumbled under actual user traffic.

Another creator tried making a full website using only AI-generated code. The result? A buggy mess with unoptimized performance, broken features, and missing authentication. He spent hours debugging and ultimately had to rewrite most of the project manually.

The bottom line: AI can generate code, but it doesn’t replace real development skills.

The Harsh Reality of Vibe Coding

A friend of mine—let’s call him AI Enthusiast #47—was hyped about AI-generated development. He told me, “Bro, you don’t even need to learn to code anymore! Just prompt the AI, and boom—crazy cool websites you're cooked bro”

So, naturally, I challenged him. “Alright, build something.”

Excitedly, he opened his favorite AI model and started prompting it to build a web app. After an hour of back-and-forth, he had something that looked decent—until he ran it.

Errors everywhere.
Broken UI components.
APIs not connecting properly.
And worst of all? He had no idea how to fix it. (He's not a dev)

At the end of the day, he spent more time prompting the errors to fix them than if he had just written the app himself from scratch after learning to code. The AI-generated code was messy, inconsistent, and lacked documentation. After hours of frustration, he rage quit and admitted, “Yeah, maybe I should learn the basics first.”

This is the problem with vibe coding—it sells a dream, but the reality is debugging a nightmare you don’t even understand.

While LLMs (Large Language Models) can generate pretty solid code snippets, building a whole app? That’s another story.

1. The Context Window Problem

AI models have a limited memory span. They might remember what you asked them five prompts ago, but try building a complex app with multiple components, and they’ll forget critical details halfway through. They even forget what they were doing and just staright go to write something else. This means you’ll constantly be re-explaining your own app to the AI, which is ironic because wasn’t the whole point to avoid writing code yourself?

2. The 70% Bad Code Problem

Most AI models are trained on publicly available code. And guess what? At least 70% of that code isn’t great—either outdated or present in repositories that were created to disrupt AI (Okay last one was a joke), inefficient, or just plain wrong. If you generate an app entirely with AI, you’re likely inheriting a ton of vulnerabilities (not talking about you Next JS), spaghetti code, and security risks and much more worse things such as law suits from the serverless architecture hosting companies for abusing their service.

3. Debugging is a Nightmare

Let’s say you manage to generate a fully functional app (somehow Not possible still). What happens when something breaks? What if you need more features and AI is unable to generate? Debugging AI-generated code is a horror story. You didn't write the logic so guessing the code is best way to go about it and since you wrote your code while vibing so you have no documentation even the model can't help you at this stage. Errors are just foreign text to you written in a different language.

At this point, you’re left with two choices: spend hours untangling the AI’s mess and give our your few brain cells left or just rewrite the app from scratch (this will be faster actually). And if you’re picking the second option, why even bother with vibe coding in the first place just to waste your time?

My Thoughts on Vibe Coding

Every few months, there’s a new AI breakthrough that makes headlines and sends the internet into a frenzy. Remember when Devin, the "first AI software engineer," was announced? People started saying, "This is it! Developers are doomed!"

And then… nothing happened.

Devin turned out to be just another AI coding assistant with a fancy label. It wasn’t writing full applications from scratch, wasn’t making high-level architectural decisions, and certainly wasn’t replacing skilled developers. The hype died down just as fast as it started.

Vibe coding is, at best, a gimmick. A flashy marketing term that AI companies love to push, promising a future where anyone can build apps without learning to code. But software development isn’t just about generating code—it’s about understanding why and how things work why your refrigerator can display a Friends episode.

That said, I don’t think we should shame people who are just experimenting with AI. Exploring new tools is fine curiosity is good, but if someone’s entire plan for becoming a developer is to let AI do the work, they're not meant to be in software or any field in that matter. Learning the basics first is crucial.

Oh, and if you’re interested in AI’s role in development, check out my previous article on AI and programming and beginners. here

Conclusion

Trends like vibe coding will come and go, but software development isn’t getting automated away anytime soon. AI is a tool—a powerful one—but it can’t replace actual developers. Instead, it’s best used to enhance productivity, not as a replacement for fundamental knowledge.

So, the next time you see someone talking about building a full app using just AI, remember: they might be shipping products, but they’re also shipping a lot of hidden problems with them.

While I sit back and watch AI-generated apps crash and burn, I’ll stick to writing code that actually works and is mine.