Product design / Practical notes
Hiring a Product Designer in Nepal for SaaS or Web3 Work
Choose a designer by the work your product needs. Look at their contribution, the decisions they can explain and how they collaborate with the people who build it.
Meet the person behind the work
I am Nischhal Raj Subba, a Senior Product Designer based in Nepal and available for remote work. My cases cover different kinds of complexity, including CRM, multi-role financial workflows and mobile messaging with wallet actions.
The useful question is which part of that work matches your product. The portrait introduces me; the project stories give you something more specific to evaluate.
Start with the kind of complexity you need help with
A role description that asks for SaaS, fintech and Web3 experience can hide very different problems. Are you changing a multi-role workflow, building a component system, explaining a technical product or improving a mobile transaction journey? Name the task and the consequence before comparing portfolios.
For a Nepal-based remote designer, also agree the overlap hours, communication expectations and employment or contract arrangement. Confirm those details directly rather than assuming a country implies a particular availability or legal arrangement.
Inspect contribution, artifact and boundary together
A strong case should explain what the designer did and provide a relevant artifact. It should also say what the artifact cannot establish. A Figma prototype can show an interaction model; it does not prove revenue, research quality or production adoption.
In my portfolio, Orkest supplies CRM hierarchy and shared-system discussion, piHub supplies multi-role financial workflow context, and Yarsha supplies a messaging-and-wallet design context. Those are distinct examples to inspect, not interchangeable labels on the same template.
The dated portfolio homepage below is a first-party introduction, not independent validation of every claim. Use it to find the case studies, then inspect the actual artifact, contribution and outcome limits together. For experience duration, check the role chronology and overlapping dates in the résumé rather than adding simultaneous jobs as separate years.
Use a focused conversation
| Ask | Listen for |
|---|---|
| What was your part of this work? | A precise contribution and team boundary |
| Which decision was difficult? | Constraints, alternatives and an explicit trade-off |
| What happens when it fails? | States, retained context and recovery |
| How did the design reach implementation? | Contracts, review and actual limitations |
| What would you validate next? | A testable question instead of an invented outcome |
Discuss one real product problem
Bring a small example from your product and talk through the information needed to make a design decision. For a multi-role workflow, the piHub review screen below is the kind of responsibility boundary I would want to understand.
The conversation should establish how the designer works with product and engineering. It does not need to become unpaid production work, and it should not require design to invent business rules.
Choose the engagement that fits the uncertainty
If you know the problem and need delivery, define the design slice and acceptance conditions. If you have conflicting symptoms, a bounded audit may be a better starting point. If you need an ongoing product partner, discuss how priorities, evidence and implementation review will be maintained.
I am based in Nepal and collaborate remotely. The relevant next step is to discuss your product, the contribution you need and what evidence would help both sides decide whether the fit is right.
