Available 2026
Software Engineer based in Nepal. I work across the full product stack: interfaces, infrastructure, and everything in between. Lately, I've also been exploring game development on the side.
I'm a software engineer who cares about how things are built, not just that they ship. Over the past five-plus years, I've worked on web and mobile products, set up the infrastructure behind them, and led the teams responsible for delivering all of it.
Good engineering isn't about writing clean code. It's about decisions that hold up, communication that clarifies, and helping the people around you grow. Being a team lead, a mentor, and an instructor changed how I approach the work itself.
Lately, free time goes to game development. Not the art or the story side, the systems: how game loops work, how state flows, how the pieces talk to each other. A different kind of engineering problem, and that's exactly what makes it interesting.
Web and mobile applications, start to finish. The work moves between frontend, backend, or both, depending on what the project calls for. A typical week shifts between design conversations, data models, and the shipped surface itself. The aim is something that works well today and stays easy to change tomorrow.
Setting up and managing the environments where applications run. Infrastructure is treated as part of the product, not an afterthought: reliable, scalable, and shaped so the rest of the team can actually work with it. That covers networking, secrets, observability, and the less glamorous pieces that keep things upright at 2am. When something breaks, the path back to a good state should be short and well lit.
Pipelines and tooling that move code from a developer's machine to production without drama. The aim is less manual work, fewer surprises, and a release process that feels routine instead of risky. Small, fast feedback loops help: automated checks, reproducible builds, and environments close enough to production to be trusted. Done well, deploys stop being a calendar event and become a non-event.
Connecting services so they hold together over time. A lot of this work is API design, contracts between systems, and the third-party platforms that products inevitably rely on. The interesting decisions are usually about boundaries: what each service owns, how it fails, and how the next person extends it. If an integration still makes sense six months later, that's a good sign.
Lead a team of developers, designers, and QA engineers. A typical week mixes planning technical approaches with clients, reviewing pull requests, debugging production issues, and unblocking the team where needed. The work spans both what gets shipped and how it gets shipped.
Taught programming fundamentals to students, designed assignments and quizzes, and spent most sessions one-on-one or in small groups helping them work through problems. A short stint, but a useful one for learning how to explain technical ideas clearly.
My first engineering role, and the one with the most mistakes attached to it. Built reusable frontend components, took on API development, and wrote test plans for the endpoints behind them. Most of the lessons came from things that didn't quite work the first time, less about what got shipped and more about what it takes to ship something that actually holds up.
Upload a CSV. Ask questions in plain language. No formulas, no SQL: just answers and charts based on the question. Aimed at making data approachable for anyone on a team, not only the people who know how to write queries.
Leading the team, running the market research that shaped the early product direction, and working through the R&D on the technical side of how the pieces fit together, separate from the AI itself. On the implementation side, building out both the frontend and the backend APIs behind it.
A fast, casual mobile game where the goal is making ice cream as quickly as the orders pile up. Built around tight loops, small decisions, and the kind of pace that turns a one-minute break into ten.
My first released game. Worked the systems side of it: the game loop, the state, and how the pieces talk to each other. Less about the art or story, more about getting the underneath to feel right.
Consultation booking platform that brings messaging, calendar, and payment into one place. Built so a session can be discovered, booked, paid for, and followed up on without the user ever leaving the app.
Joined as a Flutter developer and grew into the team lead role for the whole project. Stayed close to the build through the full product lifecycle, from early feature work to release and the iterations that followed.
A discovery product in the travel space, helping people find places worth going to and the spaces to work from while they were there.
Built the first version of the discovery UI and helped set the early visual direction of the platform during its initial stage.
A platform in the healthcare space for running surveys and questionnaires and turning the responses into analysis on customer data. Less about scheduling, more about collecting the right inputs and making sense of them.
Focused on the survey side of things: how questions get built, how answers get captured, and how the data lands in a state that's ready to be looked at.
A booking and discovery platform for shared workspaces, built so people could find a place to work and reserve it in the same flow. The kind of product where the booking experience either gets out of the user's way or quietly becomes the reason they leave.
Joined as part of the engineering team and worked across features on the discovery side of the product. Spent time on the parts where the user flow met the data underneath, plus the smaller fixes and refinements that kept the experience steady as the platform grew.
Open to a good conversation: a project to build, a role, infrastructure or systems work, or just talking shop on how things ship. I read everything; usually reply within a day or two.
sauravads123@gmail.comAvailable 2026
·Kathmandu (UTC+05:45)·English / नेपाली