About Debugly

The short version

Debugly is a blog about why software breaks and how people figure it out.

Not tutorials. Not framework announcements. Not lists of ten VS Code extensions. The subject here is failure: the error message you pasted into a search box at eleven at night, the latency spike nobody can explain, the theme that worked perfectly until an app was installed, the pull request that reads beautifully and is quietly wrong.

Every post is something I actually hit. If I have not reproduced it on my own machine, it does not get published.

Who writes this

My name is Rohit Bhadani. I am a software engineer based in Surat, Gujarat, India, and I am the founder of Krova Cloud, where we build isolated Firecracker microVMs on our own hypervisor.

The path here matters, because it explains what I write about.

2019 to 2021, Hosting Gujju. I started as a full stack developer at a shared hosting company in Surat, working in React, Laravel, Express, and MySQL. The real education was operational rather than technical: keeping other people's websites online, answering tickets at inconvenient hours, and learning in detail how shared hosting fails. Almost everything I believe about isolation and blast radius comes from that period.

2021 onward, Secfense. Frontend work on a security product, in React, TypeScript, and Redux. Working on authentication infrastructure teaches you a particular kind of paranoia about edge cases, because in security the edge case is the product.

2022 to 2026, Debutify. Four years building Shopify themes used by thousands of merchants, joining as a developer and finishing as Chief Development Officer. Theme performance, Liquid rendering, app conflicts, and the strange failure modes that appear when your code runs on thousands of stores you cannot see. I left in August 2026.

2025 onward, Krova Cloud. I started building Krova alongside Debutify in January 2025 and went full time on it in 2026. It is the second version of the hosting business I began my career in: instead of putting every customer on one shared kernel and hoping, every workload gets its own kernel inside a Firecracker microVM. We run our own hypervisor on bare metal in Los Angeles.

I hold a Bachelor of Engineering in Information Technology and a Master of Engineering in Computer Software Engineering, both from Gujarat Technological University.

The practical consequence of that path is that my debugging has moved steadily down the stack. It started in application code, spent four years in the browser and in Liquid, and now lives largely in kernels, networking, and process isolation. All of those show up here.

Why I started this

There is an asymmetry in technical writing that has bothered me for years.

If you want to learn how to do something, the internet is generous. There are hundreds of articles on adding server side rendering to an app, and many of them are good. Supply is abundant because the work is legible: you make the thing work once, you write down the steps, you publish.

If you want to know why something broke, the internet is thin. You find a GitHub issue with fourteen "same here" comments and no resolution. You find a Stack Overflow answer from 2019 that no longer applies. You find a post clearly generated from the error string itself, offering five generic suggestions you already tried.

Writing about failure is harder. You need to have actually experienced it, reproduced it, understood the mechanism, and resisted the urge to stop the moment the symptom disappeared. That last part is where most debugging ends. Something changes, the error goes away, and the understanding never arrives.

I wanted a place to write down the understanding.

What you will find here

Error autopsies. One specific error message, taken apart properly. Reproduction steps, the actual mechanism underneath, the fix, and a ranked list of the other things that produce the same message. If you arrived from a search engine with an error in your clipboard, the fix is at the top. I am not going to make you scroll past a life story.

Bug hunts. Long form accounts of a single investigation, with the false leads left in. The wrong turns are the part you learn from. A writeup that goes straight from symptom to root cause teaches you one answer. A writeup that shows the three hypotheses that were wrong, and why each was reasonable, teaches you how to think.

Infrastructure and isolation. Containers, microVMs, kernels, networking, and the failure modes of multi tenant systems. This is what I do now, so it is what I am learning fastest.

AI development tooling. I use coding agents daily and I write about debugging their output. The failure modes of machine written code are genuinely different from human ones, and that deserves serious treatment rather than hype or dismissal.

Shopify and ecommerce. Four years of theme work does not evaporate because I changed jobs. Theme performance, Liquid, app conflicts, and platform tradeoffs. I have no commercial stake in that market now, which makes some of it easier to write honestly.

Opinions, occasionally. I think print debugging is underrated and I think most error messages are badly designed user interfaces. I intend to argue both properly.

Editorial standards

A few commitments, because a blog about failure should be honest about its own.

Everything is written by me. I use AI tools in my daily work and I write about debugging their output, but the posts here are mine: my investigations, my mistakes, my prose.

I state versions. "Node 22.14, Postgres 16.3, Firecracker 1.10" is not pedantry. Software behaviour is not timeless, and a post without versions wastes your time.

I disclose conflicts. I run an infrastructure company. When a post touches something Krova Cloud sells, that is stated at the top of the post, not buried in a footer. I am not going to write comparison posts that conclude my own product wins.

I correct things. If a post is wrong, I fix it and say what changed rather than quietly editing. See the editorial policy for the detail.

Getting in touch

Corrections are genuinely welcome, especially the ones that sting. If a post is wrong or incomplete, or if you hit a variant of a bug I described and solved it differently, I want to hear about it.

You can reach me through the contact page, or find me on LinkedIn and GitHub.

If you are new here, start here is a map of the posts worth reading first.