Hi, I am Vishal "Goblin" Gurung. I write software and systems in Japan, and I grew up in Nepal. Somewhere in between, I stopped writing scripts to get through my own day and started writing things other people could use. That is the whole story, really. The rest is detail.
What I actually do
I am a system engineer. In practice, that means I sit somewhere between the code and the machine it runs on: release pipelines, CI, infrastructure, and the unglamorous parts that decide whether anything works on a Tuesday.
The parts I like best are the ones where the bug is not in the code you are looking at. A route that 404s because someone forgot a path segment. A configuration option that works on one platform and silently does nothing on another. Those are findable. They are real. And the fix is usually small enough to land in an afternoon, which is exactly why nobody has looked yet.
The tools
Most of my day is TypeScript and Node. Rust when I want the type system to argue with me first. React and Astro for anything with a surface. Postgres and SQLite for anything that should still work years later. Cloudflare when the infrastructure fits.
I care more about a thing being inspectable than about it being clever. Code you can read at 2am is worth more than code that was briefly impressive.
What I build
Small tools, usually. The pattern is consistent: something annoys me, I build the thing that fixes it, and then I find out whether anyone else had the same problem.
RealityMap is the clearest example. I kept opening large JavaScript repos to find out what imported what, and doing it by hand every time. Now it takes one command and runs entirely on your machine. There is no upload, service, or database involved.
Nyuz is the current one: a briefing product that reads feeds, works out which articles are covering the same event, and assembles briefings around your interests. It is still being built, so there is nothing to link to yet.
The pattern is not "startup". It is: notice a problem, remove the manual step. Sometimes that is a product. Sometimes it is a script. The distinction matters less than it sounds.
Writing
I write here when I get something wrong and work out why. It is a slow way to learn and a much slower way to be wrong in public than in a pull request, but the notes survive longer.
Mostly systems, tooling, and the specific misery of getting software to run somewhere it was never developed.
Getting in touch
Mail is best. It is in the sidebar, along with GitHub. I read everything and reply to most of it.