How to Vet and Verify a Software Development Company in Nepal: A Buyer's Checklist Before You Sign

Search for software companies in Nepal and you will find plenty of directories. What you will not find is a straight answer to a harder question: once you have a shortlist, how do you actually check that a vendor is what it claims to be, before money and code change hands?

That is the gap this guide fills. It is a process you can run yourself, not a ranking. We do not review, grade or recommend firms here, and we name none.

What this guide does, and does not, do

It does not rank companies, and it quotes no rates. There is no reliable, publicly documented rate card for this market. Anyone telling you "the going rate in Nepal is X" is either guessing or selling you something. Treat any unsourced price figure you are handed with suspicion, including from us.

What you get instead is a sequence of checks. Run them in order. Each one is meant to be verifiable by you, from a primary source, not from a vendor's own About page.

Step 1: Write down what you are buying

Before vetting anyone, put your own scope on one page: deliverables, milestones, technology, who owns the code and the design files, and what "done" means. Vendors who look strong against a vague brief and weak against a specific one are usually selling sales capacity, not engineering capacity.

Step 2: Confirm the company legally exists

Two separate checks, often confused for one.

First, company registration. Ask for the registration certificate, then look up the company number yourself against the Office of the Company Registrar's register. Confirm the legal name matches the name on the contract, not just the brand name on the website.

Second, tax status. A permanent account number (PAN) and VAT registration can be checked against the Inland Revenue Department's own records. Confirm the status as it stands on the day you check it and save a dated screenshot.

If a vendor hesitates over either request, that is your answer.

Step 3: Test the claims that are easy to fake

Industry association membership is a common trust signal. Do not take a logo on a website as proof. Go to the association's own published membership list and confirm the company appears there. If it does not, ask why, and note the date you checked.

Same discipline for everything else: team size, office address, years in operation, client logos. Ask for permission to contact two or three current clients and one former client. Former clients tell you more.

Step 4: Look at the work, not the portfolio page

Ask for a code walkthrough on a non-confidential project. You are not auditing quality line by line; you are watching how they talk about their own decisions. Do they have tests? Do they use version control properly? Can they explain a bug they shipped and how they fixed it?

If a technical lead cannot answer questions about their own codebase without a salesperson stepping in, you have learned something useful.

Step 5: Get security and continuity answers in writing

Ask who will own the cloud accounts, domains, repositories and third-party subscriptions. Ask what happens at offboarding: how code and credentials are handed over, and in what format. Ask who can access your production data and under what conditions. Get the answers in the contract, not in an email you will lose.

Step 6: Sort out contracts and cross-border payments

Check three clauses before signing: intellectual property assignment, confidentiality, and dispute resolution (which country's law applies, and where disputes are heard).

On payments, foreign-exchange and service-income rules apply to cross-border work, and they change. Confirm what applies to your transaction with your own bank, and with Nepal Rastra Bank's published rules as they stand at the time you contract. Do not rely on a blog post, including this one, for the current position.

Step 7: Ask the awkward questions early

Who will actually do the work day to day? Will any part be subcontracted? What is the team's turnover like, and what happens if your lead developer resigns? How are scope changes priced and approved? A vendor that answers these plainly is telling you how they will behave when something goes wrong.

Red flags worth walking away from

Reluctance to share a registration number. References that never quite connect. A contract with no IP assignment clause. Pressure to pay a large upfront amount before any milestone. Answers that change between calls.

A checklist you can print

Registration number verified against the primary register, dated. PAN or VAT status verified, dated. Association membership confirmed on the association's own list. Two current and one former reference spoken to. Code walkthrough completed. IP, confidentiality and dispute clauses reviewed. Account ownership and offboarding documented. Payment and foreign-exchange requirements confirmed with your bank.

The limits of any checklist

Verification reduces risk. It does not remove it. The cheapest way to test a vendor is a small, well-scoped first project with clear acceptance criteria and a clean exit. Do that before you commit a year of budget, and you will learn more than any due-diligence document can tell you.