What to Ask Before Hiring a Software Development Company in Nepal

Nepal has a lot of software companies. Some of them are excellent. Some of them will build something that works in the demo and breaks in production. Here's how to tell the difference before you sign anything.

I've watched this happen many times. A founder picks a company based on a polished portfolio and a price that feels right. The build goes okay. Launch day is fine. Then three months later, something breaks and nobody's picking up the phone. Or the codebase they handed over is a mess that no other developer wants to touch.

The problem isn't Nepal. Nepal has good engineers. The problem is that most buyers don't know what questions to ask before they commit, so they can't tell the good companies from the ones who are just good at sales calls.

Questions about their process

Process questions reveal how a company actually works, not how they say they work. Anyone can describe an agile workflow in a sales call. What matters is how they handle the messier parts of real projects.

What happens when requirements change mid-build?

Requirements always change. The question isn't whether they'll change, it's how the company handles it when they do. A company without a clear answer here is a company that'll either charge you a surprise invoice or silently cut corners to stay on schedule.

Good answer: they have a defined change request process. New requirements go through scope assessment before work starts. They can tell you what that looks like.

Bad answer: "We're flexible, we'll work it out." That's not flexibility. That's no process.

Who makes the architecture decisions?

Some companies assign a senior technical lead to architecture. Others let whoever's available make the decisions. The difference shows up six months into a project when you discover the foundation was built in a way that makes every new feature twice as expensive.

Ask to speak with the person who would make architecture decisions on your project. If they can't name that person, or if that person isn't available for the call, that tells you something.

Can I talk to someone who worked with you for 12 or more months?

Any company can produce a happy client from three months post-launch. That's still the honeymoon period. What you want to know is what happens at month seven when something unexpected breaks, or at month twelve when the product needs a major change.

Here's a real example. I spoke to a founder who hired a well-reviewed agency in Kathmandu. The first six months were smooth. Then they needed a core feature changed. The company quoted double the original project rate to make the change, because the architecture didn't support it. The founder had no idea this was a risk when they signed. The agency's reference clients had all been contacted at month two.

Ask for references who are at least six months post-launch. Then actually call them and ask what broke after launch and how the company responded.

What does your deployment process look like?

Deployment is where theory meets reality. A company with no deployment process is handing you code and hoping for the best. You want to hear about staging environments, CI/CD pipelines, rollback procedures. You want them to be able to describe what happens the moment before they push to production.

If the answer is "we'll deploy it for you when it's ready," that's not a deployment process. That's a red flag dressed as a feature.

Questions about what happens after launch

Most software problems don't show up during the build. They show up after. The way a company handles post-launch is often the thing that matters most, and it's almost never discussed before you sign.

What's your maintenance model after launch?

Maintenance is keeping what you have working. Bugs fixed, security patched, dependencies current. Some companies include a support window and then disappear. Others offer a retainer model. Some hand over the code and consider the engagement closed.

None of these are automatically wrong. What's wrong is not knowing which one you're getting. Ask directly what's included in the price and what will cost extra after launch. Get that in writing.

If something breaks at 2am, what happens?

This question isn't about the actual 2am scenario. It's about whether they have an on-call process at all. Do they have monitoring? Do they get alerted when something goes down, or do they wait for you to tell them? Is there an SLA for critical issues?

A company that's never thought about this question hasn't thought seriously about production.

Who owns the infrastructure after handoff?

This one catches people off guard. Some companies run your application on their own cloud accounts and hand over access at the end. Others set it up on yours from the start. The difference matters when the relationship ends or when you want to bring in another team.

You should own your own infrastructure from day one. If a company resists this, ask why. The answer will tell you a lot about how they think about client relationships.

Red flags you'll see if you're looking

Some signals are obvious once you know to look for them. Others are easy to miss if you're excited about the portfolio or the price.

• They give you a fixed quote before understanding your problem. Quoting before discovery means they're guessing, not scoping.
• They have no references who are more than three months post-launch. Honeymoon references aren't useful.
• They don't ask about your business, only your features. A company that only talks about features doesn't understand what they're building or why.
• Everything is included in the price, but monitoring, deployment, and security are somehow extra. This is a scope trick. It'll cost you more than you expected.
• They can't explain past architecture decisions in plain language. If they can't explain it to you, they either didn't make it or don't understand it.

"We can build anything you need" is something every company says. The ones worth hiring can tell you what they won't build and why.

What good answers look like

Good companies have answers ready because they've thought through these problems already. They slow down. They ask questions before quoting. They can name the person who makes architecture decisions and put you in a room with that person.

They have clients who've been with them for a year or more and are willing to talk about it honestly, including the parts that didn't go perfectly. They're upfront about what's out of scope and they put it in writing.

They ask about your business, not just your features. A company that asks "what does success look like in six months?" before asking "what features do you need?" understands that software exists to solve problems, not to be built.

If you're not sure you have the technical background to evaluate the answers, that's a separate problem worth solving on its own. Working with a fractional CTO in Nepal before and during the vendor selection process means someone with the right technical context is asking these questions alongside you, and can tell when the answers don't add up.

At Asteroid Studio, we ask these questions of ourselves before any new engagement. We can name the technical lead on every project. We have a documented change request process. We set up infrastructure in the client's name from day one. Not because it sounds good in a sales call, but because projects built any other way tend to create problems we'd rather not be responsible for cleaning up.