What Drives the Cost of Custom Software in Nepal

Software quotes for the same brief routinely differ by five times. That is not mostly dishonesty. It is that a vague brief is a different project to each person reading it, and the number reflects what they imagined.

Understanding the actual cost drivers lets you write a brief that produces comparable quotes, and lets you tell an expensive requirement from a cheap one before you commit to it.

What genuinely costs money

The number of distinct user roles. Every role has its own screens, its own permissions, and its own testing. A system with one type of user is a fraction of the work of one with five, even if the underlying data is identical.

Integrations. Each connection to an external system is a project: understanding their API, handling their failure modes, and dealing with their changes forever. Two integrations cost more than twice one, because failures now cross systems.

Workflow complexity. A linear process is cheap. Approvals, conditional routing, exceptions, and states that can move backwards are where the effort is. “It depends” in a requirements conversation is usually the most expensive phrase in the room.

Non-functional requirements. “Must handle a thousand concurrent users”, “must work offline”, “must be auditable to a regulator’s standard” — each of these can cost more than all the features together, and they are frequently mentioned in passing.

Data migration. From an existing system, this is routinely a third of a project. See ERP data migration.

Offline capability. Deserves separate mention because it is commonly assumed to be a setting. It is an architecture — local storage, conflict resolution, identifier generation that cannot collide. Genuinely necessary in this market for some systems, and never cheap.

What is cheaper than people expect

More screens of the same kind. The tenth CRUD screen costs a fraction of the first. Volume of similar things is not a cost driver.

Reports, once the data model is right. If transactions are recorded properly, reporting is comparatively straightforward. It is when the data is wrong that reporting becomes expensive.

Standard features. Authentication, file upload, email, PDF generation. These are solved. A vendor charging significantly for them is either rebuilding what exists or padding.

Where the money goes

For a typical custom build, roughly:

• Discovery and design — understanding the business, deciding what to build. Skipping it does not save money; it moves the cost into rework.
• Development — the largest single share, but usually well under half the total.
• Testing and fixing — larger than clients expect, and the first thing cut under pressure, always at a cost paid later.
• Deployment and infrastructure setup — small, but real.
• Data migration — highly variable, often the largest surprise.
• Training and rollout — consistently underestimated.
• Project management and communication — real work, and its absence is visible.

A quote that is only development hours is not a quote for a working system.

The costs that continue

Software is not a purchase. The recurring costs:

• Hosting, which scales with usage
• Third-party services — SMS, payment processing, mapping, email delivery
• Maintenance — dependency and security updates, which are not optional
• Support — someone available when it breaks
• Changes — every system in active use needs them continuously

A rough planning figure many teams use is that annual running and change costs land somewhere around a fifth of the original build. Take that as an order of magnitude to plan against rather than a rule; the real number depends heavily on how much the business changes.

The point is that a build with no ongoing budget becomes a system nobody can change, which is how businesses end up rebuilding in three years.

Why the quotes differ so much

Different assumptions about scope. The main cause. One vendor assumed an admin panel; another did not.

Different assumptions about quality. Automated tests, code review, documentation and error handling all cost time and none are visible in a demo. The cheap quote is often cheap because it omits them, and you find out in year two.

Different team composition. Senior engineers cost more and usually deliver faster with fewer defects. Which is better value depends on the work.

Different attitudes to risk. A vendor who has been burned by underestimating adds contingency. That is a mark of experience rather than of padding.

Some quotes are wrong. A number well below the others usually means they misunderstood, and the gap reappears as change requests once you are committed.

Making quotes comparable

Provide the same specifics to everyone:

1. Every user role and what each can do
2. Every integration, named, with the direction data flows
3. Expected volumes — users, transactions, data
4. Anything that must work offline
5. What data is being migrated, from where, and how much
6. What “done” means — the specific things that must work
7. What support you expect after launch

Then ask each vendor to break the quote into phases with what is included in each. Vendors who cannot break it down have not thought it through.

Reducing cost honestly

Ways that work:

• Cut scope, not quality. Half the features built properly beats all of them built badly.
• Phase it. Build the part that pays for itself first, and fund the rest from the value it creates.
• Use standard components. Do not build what you can configure.
• Prepare your own data. The cleaning work has to happen; your staff can do much of it more cheaply than a vendor.
• Have one decision-maker. Ambiguity and reversed decisions are among the largest hidden costs in any project.

Ways that do not: skipping testing, skipping discovery, choosing the cheapest quote without understanding why it is cheapest, or accepting a fixed price on a brief nobody has pinned down.

We are a software development company in Kathmandu and will tell you when a smaller build, or an off-the-shelf product, would serve you better. Talk to us.