Software Development in Nepal: Custom Software, Costs and Build vs Buy

Short answer: buy existing software unless the process is genuinely specific to your business and is a competitive advantage. If you must build, write the specification before choosing a vendor, insist on staged delivery, and settle code ownership in writing before the first payment. Scope discipline saves more money than any rate negotiation.

Build versus buy, decided honestly

This is the most valuable section here and the one most likely to save you money, so I will start by arguing against the work.

Custom software is justified in three situations. When the process you are automating is specific to your business and is a genuine source of advantage. When no existing product fits without a compromise you cannot live with. When licence costs at your scale genuinely exceed the cost of building and maintaining your own.

It is not justified because an existing tool is mildly inconvenient, because you dislike subscriptions, or because a vendor proposed it. Off-the-shelf accounting, CRM, HR and inventory products exist, are supported, are updated by somebody else, and are enormously cheaper than a bespoke equivalent that you will then own forever.

A useful test: could a similar business in your sector use this software unchanged? If yes, you are rebuilding something you could buy. The exception worth noting is that many Nepali businesses have genuinely unusual requirements around cash handling, delivery logistics, the Bikram Sambat calendar and local compliance, where international products fit poorly. That is a real reason to build.

There is often a third option that gets overlooked: keep the off-the-shelf products and automate the joins between them. A great deal of what businesses want custom software for is actually moving data between systems and notifying people, which is workflow automation at a fraction of the cost and time.

Website or application, and why the distinction decides the price

A website presents information and collects enquiries. It can be quoted by page count reasonably. What that costs is covered in what a website costs in Nepal.

An application has user accounts, permissions, business logic and data that changes state. Booking systems, dashboards, inventory tools, portals, internal management systems. The visible screens are a small fraction of the work; the rest is rules, edge cases, validation and what happens when two people do the same thing at once.

If a vendor quotes an application by number of pages, they have either misread the brief or are about to discover the difference during your project, at your expense.

Scoping, which is where projects are actually won or lost

The dominant cause of failed software projects in Nepal is not skill. It is that requirements lived in a conversation rather than a document.

Before approaching any software company in Kathmandu, write down:

• Who uses it. Every role, and what each is allowed to see and do.
• What each role does, step by step. Written as sentences: "a sales staff member creates an order, selects an existing customer or adds a new one, applies a discount up to ten percent without approval."
• What data exists and which fields are mandatory.
• What must integrate with an existing system, and whether that system has an API.
• What happens when things go wrong. Cancellations, refunds, corrections, someone leaving the company. Exceptions are usually the majority of the work.
• What is explicitly out of scope for version one. The most important list of the six.

This does not need to be technical and you do not need a developer to write it. It needs to be specific. A vendor estimating from a document like this gives you a number that means something. A vendor estimating from a meeting gives you a number that will change.

The three pricing models

Fixed price

One number for a defined scope. Good when the specification is genuinely complete and stable. The trade-off is that every change becomes a negotiation, and vendors price risk into the number. Fixed price against a vague scope is the worst of both worlds: you get a low number and an adversarial project.

Time and materials

You pay for time at an agreed rate. Honest, flexible, and requires trust plus involvement. Best when requirements will genuinely evolve. Set a budget cap and review fortnightly so the meter is never running unobserved.

Dedicated team or retainer

You retain developers for a period. Sensible for ongoing product work rather than a one-off build, and this is the model much of Nepal's outsourcing sector runs on with foreign clients.

Insist on staged delivery

Never agree to a project where you first see working software at the end. Break it into stages, with something usable delivered and paid for at each one.

The reason is not distrust. It is that you will not know what you actually wanted until you use something, and discovering that in month two is cheap while discovering it in month six is not. Staged delivery also means that if the relationship fails you own working software rather than a partial system nobody can finish.

Choosing a software development company or IT company in Kathmandu

Nepal has a large and genuinely capable IT sector, much of it built on outsourcing for foreign clients, concentrated heavily in Kathmandu. Quality varies as widely as price. Six questions separate them:

1. Can I speak to the developers who would do the work? Not the sales lead.
2. Can I see a system you built that is still running after two years? Longevity reveals more than a launch.
3. How do you handle a change request mid-project? A real process, not "we are flexible".
4. What does handover include? Source code, documentation, deployment instructions, credentials.
5. Who owns the code and where does the repository live? See below.
6. What happens after launch? Bugs, support window, maintenance cost.

Weigh the fifth and sixth heavily. The expensive failure in software is not the hourly rate, it is a half-finished system that no other developer will take over.

Code ownership, settled before you pay anything

Agree in writing, before development begins:

• The source code becomes your property on final payment.
• The repository sits under your organisation's account, with developers granted access — not the other way round.
• Servers, domains and third-party service accounts are registered in your name.
• Handover includes documentation sufficient for another competent developer to continue.

Without these you have not bought software, you have rented a dependency. Businesses in Nepal have had to rebuild from scratch because a vendor held the repository and the relationship ended badly. This is the same principle as account ownership in marketing, covered in hiring an SEO consultant.

Business decision: in-house team, IT company, or independent developer

An in-house team makes sense once software is core to your business and needs continuous development. Premature hiring is expensive, because one developer alone with no senior review produces systems nobody else can maintain.

A development company gives you a team, continuity when someone leaves, and process. You pay for overhead and you may not get their strongest people.

An independent developer or small senior team gives you direct access and lower overhead, suiting well-defined projects. The risk is the bus factor, which is why documentation and repository ownership matter even more here.

When the answer is not to build at all

Worth saying plainly, because vendors rarely do. A significant share of the software enquiries I receive are better solved without custom development: an off-the-shelf tool configured properly, a spreadsheet with disciplined process, or automation connecting systems you already pay for.

If your actual problem is that data is retyped between three systems and enquiries fall through the gaps, that is usually weeks of automation work, not months of development. If the problem is that nobody agrees on the process, software will encode the disagreement permanently rather than resolve it.

Common questions

Should I build or buy?

Buy, unless the process is specific to your business and a competitive advantage. If a similar business could use it unchanged, buy it.

What does custom software cost in Nepal?

Priced by developer time, not features. The bigger risk is scope, not rate — undefined scope routinely multiplies the estimate.

Website or web application?

Websites present information and can be quoted by page. Applications have accounts, permissions and logic, and cannot.

Why do projects run over budget?

Because the scope was never written down. Everything else follows from that.

Who owns the source code?

You must, in writing, before work starts — including the repository under your account and full handover documentation.