From Janakpur to Kathmandu
A professional origin story shaped by two places, a systems engineering education, and the decision to build useful software in Nepal.
A profile can turn a person into a list of places and credentials. Janakpur. Kathmandu. A degree. A company. Those details matter, but they do not explain what I pay attention to when I build a system. For that, I have to look at the path between them.
My public profile lists Janakpur as my hometown and Kathmandu as the city where I live and work. The two places give me a useful way to think about software in Nepal. Work does not happen in one uniform environment. A system may begin with a central plan and end with a person working through a local office, a school, a shop, or a field visit. The distance between those places shows up in the details.
I studied BSc (Hons) Computer Systems Engineering at the University of Sunderland and also studied at The British College Kathmandu. Before that, I went to Saurya International College. Education gave me concepts, tools, and a way to reason about systems. Projects gave those ideas a place to become useful. I learned that a technical solution has to survive contact with the person who uses it at the busiest part of the day.
That lesson keeps returning in my work. A database can be well designed and still fail the organization if the search does not match the way staff remember a record. An interface can look polished and still slow people down if it hides the next decision. A deployment can be technically correct and still leave the team exposed if nobody knows how to restore a backup or report a problem.
My work now sits at that meeting point between software and routine. I lead Aasha Tech Pvt. Ltd. as Managing Director and Founder, and I build websites, management systems, billing tools, data platforms, and workflow software. The projects vary, but the starting question stays close to the same: what does this organization need to do more clearly and with less repeated effort?
Working from Kathmandu also keeps the practical side of technology close. Clients and teams have different levels of infrastructure, different ways of recording information, and different expectations about support after delivery. A useful system has to respect those conditions. It needs to be understandable to the person who uses it and maintainable by the person who will look after it later.
The geography is part of my professional identity, but it is not a slogan. Nepal is the place where I learned to take context seriously. Janakpur reminds me that a system should make sense beyond the central office. Kathmandu gives me a place to work with organizations that are trying to improve how they operate. The software has to connect both sides.
I do not think a portfolio should present a perfect path. Mine is a working one. Study, project work, client conversations, deployment, support, and the next problem have shaped each other. The result is a preference for software that earns trust through use rather than presentation.
If you are building from Nepal and want a system that fits the work your organization already understands, that is the kind of conversation I know how to start.