Why Most Software Projects in Nepal Fail (And What Actually Works)
A business owner in Kathmandu spends eight months and NPR 20 lakhs building a system for their operations. At launch, it works — barely. Three months later, the team is back on Excel. The system is technically still running, but nobody uses it, and everyone has quietly agreed not to talk about it.
This is not a rare story. If you've been around Nepal's business community for any length of time, you've either watched it happen or been part of it. And the frustrating thing is that it almost never comes down to the quality of the code. The code is usually fine. The failure was decided much earlier than that.
It starts with requirements that aren't really requirements
The first meeting between a business and a software team in Nepal usually follows a predictable script. The owner explains what they need: an inventory system, a CRM, an HR tool, something to replace the spreadsheets. The developer nods and starts thinking in features. A price is quoted. An agreement is signed.
What didn't happen: anyone asking what the business actually does today, step by step, when it processes an order or onboards an employee. Nobody mapped the existing workflow. Nobody asked which parts of the current process, however ugly, actually work. Nobody looked for the informal workarounds that staff have built over years of adapting to an imperfect situation.
Software built on a summary of what someone thinks they want solves imaginary problems. The real problems — the ones that determine whether the system gets adopted or abandoned — only surface when someone spends time in the actual operations before writing a single line of code. This phase is called discovery, and it's what most engagements in Nepal skip entirely, either to save time or because neither side knows to ask for it.
How vendors get selected, and why it goes wrong
The way most businesses in Nepal choose a software partner is understandable but deeply flawed. They ask for portfolios, get three or four quotes, and go with the most credible-sounding team at the most palatable price. Sometimes they ask a trusted contact for a recommendation.
What this process selects for is: whoever looks most trustworthy in a one-hour meeting and is willing to do the work for the least money. It doesn't select for the thing that actually determines project success — which is whether the team has the process discipline to translate a real business into working software.
The questions worth asking instead: Can you show me something you've built that's been running in production for more than a year and is still actively used? How do you handle scope changes when the client's requirements evolve mid-project? What does your discovery process look like before development begins? What happens after launch — who supports the system, and how?
These questions surface character and process in a way that portfolio decks don't. A team that's used to being asked easy questions will often be unprepared for hard ones. That unprepared reaction tells you something.
The fixed-price trap
A significant portion of Nepal's software projects are commissioned on a fixed-price, fixed-scope model. A document is written describing what will be built. A number is agreed. Work begins.
The problem is that software scope is never actually fixed at the time of signing. It only feels fixed because nobody knows enough about the problem yet. As development proceeds and the business sees what's being built, requirements clarify, gaps in the original spec become visible, and the thing they actually needed turns out to be somewhat different from what they thought they needed.
In a healthy engagement, this is normal and expected — requirements evolve, and the team adapts. In a fixed-price contract, every change is a negotiation. The vendor is trying to protect the margin on a price they agreed to before they fully understood the work. The client is frustrated that they're being charged extra for things they thought were included. Both sides dig in. The relationship deteriorates. The project slows. Something gets delivered, eventually, but it's not quite what anyone wanted.
The alternative isn't "no fixed costs" — it's milestone-based work where both sides can assess progress and direction at regular intervals, with honest conversations about what's changing and why. It's slower to agree to upfront, and it requires more trust on both sides. But it produces systems that actually get used.
"Done" is not the same as working
There's a finishing line in most Nepal software projects that both sides agree on without quite saying it aloud: the system is done when the code is done. Features are built, tested to some degree, deployed, and then the engagement closes. The team moves to the next project.
What comes after — staff training, data migration, the first month of real-world usage, the bugs that only surface under actual operational load, the workflow adjustments that are only discovered when real people try to use the thing every day — is usually treated as the client's problem now.
The result is that a large number of systems that get "launched" in Nepal never really get past the first month of real usage. Staff resistance builds up because nobody trained them properly. Data from the old system didn't migrate cleanly. The system breaks in ways that weren't caught in testing because testing was done by developers, not by the actual users in their actual environment. And the vendor, already halfway through the next project, is slow to respond.
Launching software is not the end of the process. It's closer to the beginning. The months after go-live, when real usage reveals what was wrong, what wasn't accounted for, and what needs adjustment — that's when good technical partnerships are separated from transactional ones.
The single point of failure nobody talks about
Here's one that comes up less often in polite conversation: many custom software systems in Nepal are effectively held hostage by one person — the developer who built them. There's no documentation. The codebase follows conventions only they understand. The deployment process lives in their head. When something breaks, only they can fix it. And when they move on — which developers do — the business is left with a running system they can no longer maintain or modify.
This is a governance problem as much as a technical one, but it's something to probe actively when selecting a software partner. Does the team follow standard frameworks and conventions that another developer could step into? Is the codebase documented? What does the handover process look like if the relationship ends? A team that has good answers to these questions is one that's thought about your long-term interests, not just the current engagement.
What actually works
The projects in Nepal that succeed — the systems that get used, evolve over time, and actually deliver the ROI that was hoped for — share a few consistent characteristics.
They started slow before going fast. Before a single line of code was written, someone spent time in the actual operations. Watching. Asking questions. Understanding not just what the business wants, but how it works today, why it works that way, and which parts of that are worth preserving.
They were built in milestones, not in one delivery. Real usage feedback shaped the direction after each phase. The system at month six was better because of what was learned at month three.
They treated adoption as part of the project. Staff were involved early. Training wasn't an afterthought. The people who were going to use the system every day had opinions that shaped how it was built, rather than finding out what it did when it was handed to them.
They planned for what comes after launch. Maintenance, monitoring, and iteration were part of the conversation from the start — not added on as an optional extra.
None of this is complicated. Most of it is common sense applied with discipline. The gap between software projects that work and those that don't in Nepal is rarely about technical capability. It's about process, honesty, and whether both sides are willing to slow down early enough to get the foundations right.
If you're about to commission custom software — whether it's a web application, a mobile app, or an enterprise platform — and you want to think through the process with people who have worked through all of the above, explore our Product Strategy & Consulting approach.