The long version

I didn't set out to become a software engineer. I started by being curious about how things on the internet actually worked — why a button did what it did, how a page knew your name, what happened between clicking "submit" and seeing a result.

That curiosity pulled me into computer science. I spent the early days bouncing between tutorials, breaking small projects, and slowly learning that the real skill isn't writing code — it's understanding the problem well enough that the code becomes obvious.

The first real turning point was building FinanCinno. Not because it was the most complex thing I'd built, but because it was the first time I shipped something people actually used. It taught me that a good product isn't about features — it's about clarity. The experience should feel calm, not crowded.

Then came my internships. At TheTastyMillets, I learned what production code looks like — the kind that has to work for real users, not just pass a demo. I built responsive UI components across 12+ pages and deep-dived into accessibility in ways no textbook had taught me.

At NextLearn Technologies, I went full-stack. I designed and deployed a learning application that cut page load time by 65%. But the bigger lesson was shipping 8 product features on schedule — learning to balance speed with quality under real constraints.

Each project after that — Lumina, StreamFlow, ZecoAI — pushed me in a different direction. Real-time systems, collaborative tools, AI-assisted workflows. Each one reinforced the same idea: the best interfaces stay out of the way.

I'm a final-year CS student focused on backend systems and full-stack product work. My day-to-day involves building things that are meant to ship — not sit in a repo.

Right now I'm most interested in the space between infrastructure and user experience: how the backend shapes what the frontend can promise, and how small design decisions ripple into reliability, speed, and trust.

I'm drawn to products that feel inevitable — the kind where every interaction makes sense on the first try. That means writing code that's boring in the best way: predictable, maintainable, and easy to hand off.

Going forward, I want to work on systems where the engineering is invisible to the user but obvious to the next developer who reads the code. I'm exploring distributed systems, developer tooling, and anything that makes building software feel less like a chore and more like a craft.