Namaste, I’m Priyanshu 🙏
I was born in India and have been curious about technology for as long as I can remember — sometimes dangerously curious.
Once, as a kid, I plugged a battery directly into the house’s main circuit. It exploded and knocked out the lighting. Not my proudest moment, but definitely one of the earliest signs that I preferred learning by doing rather than being told.
My mother used to call me mechanic because I kept opening things. old Heaters. TVs. Anything with screws. Most survived. Some didn’t.
The computer that started everything
We had a computer at home that my father had assembled himself — a Pentium 4 with 1 GB RAM running Windows XP, later Windows 7. It struggled with games but was perfect for that time.
Around the age of seven, I wrote my first program — a tiny text-to-speech script that ran on startup and said “hello.” It felt like I had bent reality a little.
Later, while trying to reinstall Windows to make games run faster (i was dumb, i know), I accidentally wiped the entire drive including our childhood photos. Panic doesn’t even begin to describe it.
I spent hours researching file systems and recovery tools on YouTube and somehow managed to recover about 90% of the data from a raw disk.
That day I learned two things:
Computers are fragile.
Understanding them is power.
I never looked at technology casually again.
Trying everything
My learning style has always been simple: try → fail → understand → repeat.
I started a YouTube channel helping people install programs, skins, and games. It’s gone now, but it taught me video editing and how to explain technical ideas clearly.
One day, while I was deep into GTA San Andreas, my father casually said:
“Why don’t you build games instead of playing them?”
That sentence quietly redirected my life.
I discovered Unity and began building small indie games — mostly unfinished, all educational. I followed tutorials like this excellent playlist and learned by shipping imperfect things.
I tried Android development with Java skipped it pretty quickly. Then I started blogging, mostly hoping it would make some money. It didn’t, but it quietly introduced me to writing and web development.
Web development stuck immediately. I liked how simple it was — build something, send a link, and it just works.
I hadn’t discovered GitHub yet, so hosting was pure trial and error. Lots of mistakes, lots of late nights.
Around then, I earned my first $10 online. I was 13 and disproportionately proud of it.
School vs building
I was never the “top of the class” student. Physics fascinated me understanding why things behave the way they do but the structure of school never fully clicked for me.
While others were optimizing for grades, I was usually distracted by ideas I wanted to try or things I wanted to build. I learned more from making mistakes on real projects than from memorizing answers for exams.
That doesn’t mean school wasn’t useful. It just wasn’t where most of my learning happened.
Even now, I don’t build primarily for money. Money is usually a side-effect. What drives me is the process understanding a problem, working through it, and turning something abstract into something real.
Building is how I think.
Open source and writing
At some point, I started contributing to open source — fixing things, adding small improvements, learning how large codebases actually move.
I spent time with projects like Oppia (where I briefly joined the team with triage access), MindsDB, Daytona, and Cyclops UI. It was my first real exposure to software built in the open.
One of my technical articles was later officially published by Fluvio:
https://infinyon.com/blog/2024/09/fluvio-google-sheet-connector/
I write occasionally on Dev.to. Some of it has reached more people than I expected.
Building my own path
I spent some time working at a startup that was building a unified API gateway. It was the first time I saw how much thought goes into infrastructure — the tradeoffs, the edge cases, the things users never notice unless they break.
Around that period, I started P8labs as a place to keep the projects I was building. I didn’t overthink it — I just needed a home for my work.
Most of what lives there started as curiosity. Some stayed experiments, some turned into real tools, and a few are still quietly evolving.
More recently, I’ve been getting deeper into electronics and low-level programming. Software began to feel incomplete without understanding the layers beneath it. That led me to build things like Piperpad.
Apparently, I still like opening systems to see what’s inside — just with fewer things exploding now.
How I think now
Over time, I’ve found myself drawn to systems that are built to last.
There’s something deeply impressive about engineers creating things that continue to work for decades. Voyager 1, for example — still operating millions of kilometers away, still receiving firmware updates long after it left Earth. That level of foresight and engineering discipline is hard not to admire.
I feel the same fascination when I think about cars. The technology inside them is expected to work in heat, cold, rain, dust — every condition imaginable. Once a car is in someone’s hands, there’s very little room for failure. It simply has to work.
That idea — building things that endure — has shaped how I approach software too. I try not to chase trends or clever shortcuts. I’d rather understand the system properly and build something that won’t fall apart a year later.
Stoic philosophy has influenced me in similar ways: focus on what matters, ignore what doesn’t, and avoid unnecessary noise.
I still spend an unreasonable amount of time installing Linux distributions, breaking them, fixing them, and trying to understand what’s happening beneath the surface.
Channels like Veritasium and Ben Eater continue to remind me how much depth there is behind the technology we use every day — and how much there still is to learn.
How I work
I tend to gravitate toward small teams where ownership is clear and communication is straightforward. Fewer layers usually mean better decisions and less noise.
I prefer writing things down — ideas, plans, even rough thoughts. Writing slows thinking just enough to make it clearer, and it avoids many conversations that don’t need to be meetings.
Constraints don’t bother me much. In fact, they often make the work better. Too many options usually lead to unnecessary complexity.
I do my best work when I have space to think before acting. Not endless planning — just enough time to understand what we’re really solving. Once that’s clear, I like moving steadily and iterating rather than waiting for perfect conditions.
I’m not very drawn to flashy launches or short bursts of attention. What interests me more is software that continues to be useful years later — things that quietly hold up over time.
More
If you’re curious about how I operate in a working environment, there’s a short manual that goes deeper.
If you want to reach me, email is best.
I’m occasionally elsewhere on the internet.