Selling Software Services to US Clients From Nepal

Plenty of Nepali teams can build what a US client needs. Rather fewer are set up to be bought by one. The difference is rarely engineering quality; it is the surrounding commercial machinery that a US buyer takes for granted, never asks about directly, and quietly scores you on anyway.

What a US buyer is silently checking

• Can they sign a contract with you that their lawyer recognises, in a form and a governing law they have seen before?
• Can they pay you without their finance team spending a week working out how?
• Who owns the code, stated explicitly, in writing, before work starts?
• What happens to their customer data, where does it sit, and who else touches it?
• Who answers when something breaks at 2am their time, and what is the actual commitment?
• What happens if this does not work out, and how much notice does each side owe?

None of these is about your ability to write software. All of them get answered in the first two calls, whether or not anyone asks the question out loud.

The contract stack: MSA, SOW, NDA

Use a master services agreement covering the standing terms, with a separate statement of work per project covering scope, deliverables, dates and price. This is the structure US buyers expect, and it means the second project is a one-page document rather than another legal review. Get the MSA drafted properly once; it will serve for years.

• IP assignment. Say that all deliverables are assigned to the client, and be clear whether that happens on creation or on payment. Buyers prefer on creation with a payment covenant; either is workable, but silence is not.
• Pre-existing material. List what you bring in that stays yours, with a perpetual licence to the client to use it in the deliverable. Otherwise you have accidentally sold your internal libraries.
• Third-party and open source. State that you will disclose licences used. Enterprise buyers will ask eventually.
• Confidentiality. Mutual, with a defined term. A one-way NDA that only binds you signals you have not done this before.
• Termination. Thirty days for convenience is normal. Price and staff for that, because it will be exercised.
• Liability. Capped, usually at fees paid over some period. An uncapped clause is a real risk, not a formality.
• Governing law. You will usually be asked for a US state. Weigh the practical enforcement question against the cost of arguing, and take advice on whether the trade is worth it for the size of the deal.

Getting paid, in detail

Payment friction ends more relationships than late delivery. Sort this out before your first invoice, not after it is stuck.

• Invoice in USD, on a fixed day of the month, with a sequential invoice number, your full legal entity name and address, the client's entity name, the SOW reference and net terms stated on the face of it. Net 15 or net 30 is standard; net 60 is a financing decision you should price for.
• Agree the route with your bank first. An inward remittance for exported services needs a stated purpose and supporting documentation on the Nepali side, and the requirements are not identical at every bank. Ask your bank exactly what they want to see, in writing, before the money is in transit rather than while it sits unallocated.
• Expect a W-8BEN-E. A US client's finance team will normally ask a foreign company for one before they can set you up as a vendor. It is a form establishing that you are not a US person; it is routine, it is not a tax bill, and having it ready shortens onboarding by a week. Take your own advice on your tax position rather than mine.
• Say who pays the wire charges. Intermediary banks deduct along the way, and an invoice that arrives short by an unexplained amount creates a reconciliation problem for both sides. Put a line in the MSA.
• Take a deposit and bill milestones. Thirty to fifty per cent up front on fixed-scope work, and monthly in arrears on retainers, is unremarkable to a US buyer.
• Charge for late payment, even if you rarely enforce it. Its presence changes behaviour.

The vendor who is easy to pay gets renewed. It is unromantic and it is true.

Price the engagement model, not the hour

Hourly billing for straightforward implementation is the weakest position available, because that is the work whose price is falling fastest. Offer models a buyer can budget against. Fixed scope against a written specification: a marketing site from around Rs 65,000, about $900, over three to five weeks; software with logins, payments and dashboards from around Rs 320,000, about $4,200, over six to twelve weeks. Or a dedicated engineer at around $2,200 a month with a three-month minimum, which is what our outsourcing arrangement is built on. All of those are starting points against a scope document, and you should say that plainly rather than let a number harden into a quote.

Say who owns the result while you are still in the sales conversation. On every tier of our work the client owns the code, the domain and the hosting from day one, and a US buyer who has been burned by a vendor holding a domain hostage will notice you saying it first.

Time zones: the arithmetic, then the discipline

Nepal runs at UTC+5:45, which puts Kathmandu roughly nine and three quarter hours ahead of US Eastern in summer and ten and three quarter in winter, and about twelve and three quarter to thirteen and three quarter hours ahead of the Pacific coast. In practice a 6pm to 9pm block in Kathmandu lands on a New York morning, and pushing to 9pm reaches the West Coast start of day. Compared with clients elsewhere this is easy: Sydney is only four and a quarter hours ahead of Nepal, so an AEST client shares most of your afternoon, and CET and GMT clients come online around your mid-afternoon.

The advantage is that work genuinely progresses overnight. The liability is that a blocked question waits a full day for an answer, which converts a two-hour problem into a two-day one. So agree a fixed overlap window, protect it, and put decisions into it rather than status. Status belongs in a written update the client reads before their day starts.

The Nepali working week, and the autumn

The standard week here runs Sunday to Friday with Saturday off, which mostly works in your favour: your Sunday covers the client's Monday morning before it begins. The mismatch is Saturday, and the fact that your Friday is a working day while theirs is winding down. Decide deliberately whether the team serving US accounts runs Sunday to Friday or moves to Monday to Friday, and tell the client which, rather than letting them discover it.

Then flag Dashain and Tihar in writing, in July. They fall between late September and mid-November and move each year with the lunar calendar. Dashain typically closes offices for a week to ten days, with Tihar two to three weeks later for another three to five days. A US client will accept this without complaint if they hear about it in advance and see a plan: a coverage rota for anything live, no releases in the fortnight before, and a named person reachable for incidents. The same client will be genuinely annoyed to discover it in an out-of-office reply.

Reduce the buyer's risk before they ask you to

A first-time buyer sending money to a country they have never bought from is taking a risk, and your job is to make that risk small and visible. Offer a small paid pilot with a defined outcome and a defined price, so the first decision is cheap. Provide references who will genuinely take a call. Publish case studies that describe the problem and the constraint rather than only the finished screens: our writeups of Hub International Education and the rest of our client work are written that way deliberately. Answer security and data questions with a document rather than a paragraph.

If you want the longer argument for why Nepal is a sensible place to buy engineering from at all, we made it here. But the argument only lands once the commercial basics above are in place. Buyers do not choose a country. They choose a vendor who is straightforward to work with, and then notice afterwards where that vendor happens to be.