Hiring a Software Team in Nepal: How to Judge One Honestly

We are a one-person software studio working from Kathmandu, and what follows is advice on how to judge studios like ours. You should read it with that in mind.

That conflict is worth stating plainly, because most writing on this subject is a sales pitch wearing a guide's clothing. The genuinely useful version has to include the parts that are inconvenient for us — where this arrangement fails, and what should make you walk away. Those sections are below.

The cost question, answered honestly

Almost everyone arrives at this topic because of rates. Engineering hours in Nepal cost less than equivalent hours in the US, UK or Australia. That is true, it is the reason most people start looking, and it is the worst possible basis for the decision.

Here is why. A rate is a price per hour. What you actually care about is the total cost of arriving at working software that keeps working — and the largest costs in that number are rarely hourly. They are the weeks lost to a misunderstood requirement, the rebuild after an architecture that could not carry the second feature, the months of paying someone to maintain code nobody documented, and the cost of the whole thing stalling because the one person who understood it disappeared.

A cheap hourly rate attached to any of those is not cheap. We have seen — and, honestly, been asked to rescue — projects where the rate was excellent and the total was catastrophic.

So treat rate as a constraint, not a criterion. Work out what you can afford, discard anyone outside it, and then choose on everything else. If a studio's main argument is that it is cheaper than the alternative, that is the argument of someone who has nothing better to offer.

What actually decides whether this works

Four things, in roughly this order.

Whether the scope is genuinely understood. Not agreed — understood. The failure mode is a vendor who says yes to everything in the first call. A partner who has understood your problem will tell you which parts are harder than you think, which parts you probably do not need, and where the estimate is a guess. If nobody pushes back on anything, nobody has thought about it.

Who you actually talk to. Ask directly whether you will speak to the people writing the code. In larger firms the answer is often no, and the layer in between is where requirements go to be misremembered. This is one of the few places a very small studio has a structural advantage: there is no layer.

What happens when something goes wrong. It will. A deploy will break something, an estimate will be badly wrong, a dependency will turn out to be unmaintained. What matters is whether you find out early and plainly, or late and dressed up. Ask a prospective partner to describe a project that went badly and what they did. An answer with no such project in it is not a good sign.

Whether you end up owning it. Your repository, your cloud accounts, your domains, your data — in your name, from day one, not handed over at the end if the relationship stays friendly. Anyone reluctant about this is telling you something important.

Timezone overlap, realistically

Nepal Standard Time is UTC+5:45. The practical picture:

The honest version is that this is genuinely easy for Europe and the Gulf, workable for the UK and Australia, and requires real accommodation for the US West Coast. Anyone who tells you that time zones are a non-issue everywhere has not worked across them. What makes the gap survivable is not heroics but working in a way that does not need constant synchronous contact: written decisions, recorded demos, and a short overlap used for the things that genuinely need a conversation.

How to test a partner before you commit

Do not evaluate on a proposal document. Proposals are written by whoever is best at writing proposals.

Pay for something small first. A scoped, self-contained piece of work — a diagnostic, a prototype, one real feature — will tell you more in two weeks than any amount of calls. You are buying information about how they work, and it is cheap at the price.

Read their code. Ask for a repository you can look at, or the code from that first small engagement. You do not have to be an engineer to notice whether there are tests, whether commits explain themselves, and whether a README exists.

Give them something ambiguous. Describe a problem where the right answer is not obvious and watch what they do. Do they ask a clarifying question, or do they produce a confident estimate for the thing you literally said? The second is a bad sign.

Check whether they will say no. Ask about something outside their competence. An honest studio will say so and often point you elsewhere. A studio that can apparently do everything is describing its sales process, not its capability.

Questions worth asking any partner, anywhere

These are not specific to Nepal. Ask them of a studio in Austin or Berlin too.

• Who writes the code, and will I talk to them directly?
• What happens to this project if the person leading it becomes unavailable?
• What in this scope do you think I do not need?
• Where is this estimate most likely to be wrong?
• Who owns the repository and the infrastructure accounts?
• What does handover look like if we stop working together?
• What is the off-the-shelf alternative to building this, and why does it not fit?

That last one matters more than it looks. We publish a whole article arguing that most people should buy rather than build, because a partner who will not name the alternative is not giving you a real choice.

When this is the wrong call

Working with a distributed partner is genuinely a bad fit when:

• The work is exploratory and changes weekly. Very early product discovery, where the spec is rewritten every few days, benefits from being in one room. Distributed delivery rewards clear scope; it punishes churn.
• You need someone physically present. Hardware, on-site integration, regulated environments requiring supervised access.
• You have no capacity to make decisions. A remote partner is blocked by unanswered questions in a way an in-house hire is not. If nobody on your side can give an answer within a day or two, the arrangement will stall regardless of who you hire.
• The thing you actually need is a permanent team member. If this is ongoing, core, and never-ending work, hiring is usually the better answer. We will say so.

Where we stand

We are one person, in Kathmandu, building AI systems, automations and software products. That is worth knowing in both directions.

What it means in practice: you talk to the person writing the code, there is no account-management layer, and decisions happen quickly. What it also means: there is a hard ceiling on how much work can run at once, and concentrating a project on one person is a real risk you are entitled to weigh. We would rather you weighed it with accurate information than found out later.

We publish our starting figures and reference ranges rather than making you sit through a call to hear a number, and we would rather tell you a project is a bad idea than take it. If you want to test that, describe a problem and see whether the reply tries to sell you something.

### FAQ

Is my idea safe to share with a studio abroad? Sign an NDA before detailed discussions and put IP ownership in the contract — the same precaution you would take domestically. Any serious studio will sign without hesitation. Note that an NDA protects the specifics, not the general idea; the execution is the valuable part anyway.

How do I manage a remote engineering partner? Write decisions down, define what "done" means for each piece of work before it starts, and review something working on a regular cadence rather than reading status reports. Most remote-collaboration problems are actually unclear-requirement problems that distance made visible.

Should I hire a team or an individual? A team survives one person becoming unavailable; an individual gives you direct contact and lower coordination overhead. Neither is universally right. What matters is that you know which you are buying and have thought about the failure mode that comes with it.

What if it does not work out? Agree the exit before you start: who owns what, what gets handed over, and in what state. A partner who is comfortable discussing this at the outset is showing you something good about how they operate.