How to Vet a Software Development Company in Nepal (Red Flags Included)

Nepal's software industry has grown quickly, and that's good news for founders looking for skilled engineers at sensible rates. It also means the range in quality is wide. Some companies will build you something you're proud of. Others will take your deposit, miss every deadline, and hand over code nobody can maintain.

The good news is that most bad outcomes are visible before you sign anything, if you know where to look. This guide covers what to check, what to ask, and which warning signs should make you walk away.

Start With the Work, Not the Pitch

Every agency has a polished website and a confident sales call. What matters is what they've actually shipped.

Ask for live products, not just screenshots. A portfolio full of mockups proves someone can use Figma. Ask for links to products that are live, in use, and preferably from clients you can contact.

Look for relevance, not volume. Twenty unrelated projects tell you less than three that resemble yours in complexity, industry, or platform.

Ask what their role was. Some companies show projects they only contributed a small piece to. A simple question like "Which parts did your team design, build, and deploy?" clears this up quickly.

Talk to a past client. A good company will connect you with one without hesitation. Ask about communication, missed deadlines, and how problems were handled, because every project has problems.

Check the Team You'll Actually Get

The people in the sales meeting are often not the people writing your code.

• Ask who will work on your project, and request to meet or speak with the lead developer before signing
• Ask how many engineers are full-time employees versus freelancers or part-timers
• Ask what happens if a key developer leaves mid-project
• Ask how they handle code review and QA, and whether those are separate from the developers building the feature

A company with a stable, in-house team will answer these easily. Vague answers usually mean the team is assembled after you pay.

Understand the Process Before the Price

A quote tells you what you'll pay. Process tells you whether you'll get what you paid for.

• How do they scope? Good companies ask a lot of questions before quoting. A firm price after a ten-minute call is a guess, and you'll pay for the guess later.
• How do they report progress? Look for regular demos, a shared project board, and access to a staging build, not just verbal updates.
• How do they handle changes? Scope changes are normal. The question is whether there's a clear, fair process for them.
• What is delivered at the end? Source code, documentation, deployment access, and credentials should all be part of the handover.

Read the Contract Like It Matters

Contracts feel like a formality until something goes wrong. Before signing, confirm:

• You own the code and IP. This should be explicit, and it should transfer on payment, not at the company's discretion.
• Payment is tied to milestones. Large upfront payments with nothing tied to delivery leave you with no leverage.
• Support after launch is defined. Bugs appear after real users arrive. Find out whether fixes are free, for how long, and what counts as a bug versus a new feature.
• There's a clear exit. If the relationship isn't working, you should be able to leave with your code and data.

Test Communication Early

Communication problems are the most common reason outsourced projects struggle, and you can test for them before signing.

• How fast do they reply to emails and messages during the sales process? This is usually the best they'll ever be.
• Is their written English clear enough for detailed technical discussion?
• Is there guaranteed overlap with your working hours? Nepal is ahead of North America and Europe by many hours, so ask what overlap looks like in practice.
• Do they push back when something is a bad idea, or agree with everything you say?

That last point matters more than it seems. A team that says yes to everything is either not thinking critically or not being honest about what's possible.

Red Flags That Should Make You Pause

None of these alone is a guarantee of trouble, but several together are a strong signal to walk away.

• A price far below everyone else's. Very low quotes usually mean corners will be cut later, or scope will quietly grow.
• No questions about your business. If they never ask who your users are or what success looks like, they're planning to build to the letter of a spec, not to your goals.
• Reluctance to share references or live work. Confident companies show their work.
• Pressure to sign or pay quickly. Discounts that expire "today" are a sales tactic, not a service.
• Vague answers about who does the work. If you can't find out who your developers will be, assume the answer isn't good.
• No mention of testing or QA. If testing isn't part of the plan, you'll be the tester after launch.
• Overpromising on timelines. Anyone promising a complex product in a few weeks is either cutting scope silently or not telling you the whole story.
• No post-launch support. Software needs care after launch. A company that disappears at delivery isn't a long-term partner.

A Simple Vetting Checklist

Before you commit, you should be able to say yes to most of these:

• I've seen live products similar to mine
• I've spoken to at least one past client
• I know who will work on my project and have spoken to the lead
• The scope, milestones, and payment schedule are written down
• I will own the code and IP
• Post-launch support is defined in the contract
• Communication so far has been fast, clear, and honest

If several of these are missing, keep looking. Fixing a bad choice mid-project costs far more than taking an extra week to choose well.

What We'd Suggest You Ask Us, Too

This applies to us as much as anyone. We'd rather you ask hard questions and choose with confidence than sign quickly and regret it. Ask to see our live work, including the Sphere Five Services case study, ask who would be on your team, and ask what our 6 months of free post-launch support actually covers.

If you're evaluating options and want a straight conversation about your project, get in touch.