How to Choose a Software Development Company in Nepal

Choosing a software company is hard because the thing you are buying does not exist yet, everyone’s portfolio looks similar, and the cheapest quote is frequently the most expensive outcome.

Here is what actually distinguishes vendors, based on where projects go wrong rather than on what proposals contain.

Ask about a project that went badly

The single most informative question in any vendor conversation.

A company that has built anything substantial has had a project go wrong — scope that ran away, a client relationship that broke down, a technical decision that had to be undone. What you learn from the answer:

• Whether they will be honest with you when things are difficult
• Whether they understood why it went wrong
• What they changed afterwards

“We haven’t had one” means either they have not done much, or they will not tell you the truth when your project hits trouble. Both are disqualifying.

Ask who will actually do the work

Sales conversations are often had by senior people. The build may not be.

Ask directly: who is on this team, how many years have they been doing this, are they employees or contracted for this project, and will the person I am talking to be involved after signing?

There is no correct answer — a mixed-seniority team is normal and fine. What matters is that you get a straight answer rather than a vague one, and that the answer matches what you see once work begins.

Ask what happens after launch

More projects fail here than during the build. The system works, then needs a change, and nobody is available.

Specifically:

• What is included in support, for how long, and at what response time?
• Who fixes a bug found in month four?
• What does a small change cost, and what is a realistic turnaround?
• Is there a maintenance agreement, and what does it actually cover?
• What happens if we need something urgently during a business-critical period?

A vendor whose model is build-and-move-on is fine for a one-off marketing site. For a system your operations run on, it is a serious risk, and it should be priced into the comparison.

Insist on owning the code

Non-negotiable for anything the business depends on.

Ask: who owns the code, where does it live, do we get access to the repository during development, and can we take it elsewhere?

If a vendor will not give you the code, every future quote from them is unchallengeable, because you cannot go anywhere else. That is not a hypothetical — it is the most common way businesses end up trapped with a vendor they have lost confidence in.

The same applies to data: where does it live, in what format, and how do you get it out.

Look at how they respond to a vague brief

A revealing test. Give a vendor an under-specified requirement and see what they do.

A poor sign: they quote immediately. Either they did not notice the gaps or they will fill them with assumptions and bill for the corrections.

A good sign: they come back with questions, and the questions are about your business rather than about technology. “How do you currently handle a partial delivery?” is a better sign than “would you prefer React or Vue?”

The best vendors will sometimes tell you your requirement is wrong, or that you need less than you asked for. That conversation costs them revenue and is the strongest signal you will get.

Talk to a reference client without the vendor present

Ask for a client with a comparable project, and ask to speak to them directly.

Useful questions:

• Did it come in on time, and if not, why?
• What happened when you needed a change after launch?
• How were disagreements handled?
• Would you hire them again for something larger?

The last question is the informative one. “They were fine” and “yes, immediately” are very different answers.

Understand how they price

Neither model is inherently better; what matters is whether it is used honestly.

Fixed price works when the scope is genuinely well understood. Its failure mode is that everything not in the specification becomes a change request, and the relationship turns adversarial as both sides argue about what was implied.

Time and materials works when the scope will evolve, which is most real projects. Its failure mode is no ceiling and no urgency.

A vendor quoting fixed price on a vague brief either has not understood it or is planning to make it up in variations. A vendor offering only time and materials with no estimate at all is asking you to carry all the risk.

Reasonable middle ground: fixed price for a well-defined first phase, then time and materials once both sides know each other.

Prefer visible progress to a delivery date

Any arrangement where you see nothing until the end is a bad arrangement. You want working software in front of you every few weeks — not screenshots, not a status report, something you can use.

This is the mechanism that catches misunderstandings while they are still cheap. A vendor who resists it, or whose demos are always slides, is managing your perception rather than your project.

Where local matters, and where it does not

For a build with a fixed scope and a clear specification, distance is largely irrelevant.

For a system embedded in how your business operates, being nearby matters more than most vendor comparisons account for: the same working hours, the ability to sit with your operations team and watch what they actually do, being on site when a rollout needs it, and understanding the local context — VAT treatment, the Bikram Sambat fiscal year, landmark addressing, how cash on delivery actually works.

Those are not features anyone lists. They are the assumptions that get made wrongly by people who have not seen the business running.

Warning signs

• Quotes without asking questions
• Cannot name anyone who will do the work
• Will not give you the code
• No answer on post-launch support
• Every answer is yes
• Portfolio pieces you cannot verify exist
• Pressure to sign quickly

The last two, together, warrant walking away.

We are a software development company in Kathmandu building custom platforms for businesses in Nepal and abroad, and we are happy to answer every question above about ourselves. Talk to us.