Custom vs Off-the-Shelf ERP for Businesses in Nepal

The ERP decision is usually framed as buy versus build, which makes it sound like a budget question. It is not. It is a question about whose process wins.

An off-the-shelf ERP encodes a way of running a business. Adopting it means adopting that way. That is often a good trade — the encoded process is frequently better than what a growing company evolved by accident. But when the business genuinely does something different, and that difference is why customers choose it, adopting a generic process means giving up the thing that made you competitive.

What off-the-shelf is genuinely good at

It is already built. Years of accumulated edge cases, already handled.

Someone else maintains it. Tax rule changes, security patches, new features arrive without a project.

There are people who know it. You can hire someone who has used it. With custom software, everyone learns it here.

Cost is predictable. A licence fee is a number you can plan around, which a development project is not.

It encodes good practice. For a business that has never had structured processes, that is a genuine benefit and not a compromise.

For finance, standard inventory, and standard purchasing, off-the-shelf is usually right. These are solved problems and your version is unlikely to be better.

Where it goes wrong here

Assumptions that do not hold. International ERP assumes a fiscal year that is probably not Bikram Sambat, an address format that resolves to a postcode, tax rules for another jurisdiction, and business practices that may not match. Some of that is configurable. Some is baked in.

The customisation trap. Each individual change is possible. Twenty of them produce a system that is expensive to maintain, breaks on every upgrade, and is understood by nobody. This is the most common expensive failure — not choosing the wrong product, but bending the right one past its design.

Support distance. When something breaks at month end and the vendor is in another country and timezone, with your account as a small line item, the response time is what it is. For a system the business runs on, that gap is the whole risk.

Cost that scales the wrong way. Per-user licensing means growth costs more, and it means you ration access to the system that is supposed to be the single source of truth.

Paying for what you do not use. Manufacturing modules for a trading company, multi-currency consolidation for a domestic business.

Where custom is genuinely right

Your process is your advantage. If how you handle orders, pricing or fulfilment is why customers choose you, standardising it into a product’s default is giving that away.

Nothing fits the domain. Nepali courier and cargo operations are the clearest example — COD custody chains, franchise branch settlement, landmark addressing. No international ERP models any of it, and configuring one to do so is a bigger project than building.

Integration is the requirement. If the system’s job is mostly to connect things you already run, a product with its own opinions about data is a hindrance.

You have outgrown the product’s ceiling. Some businesses genuinely exceed what a mid-market product handles, in volume or complexity.

The honest middle

Most businesses do not need either extreme. What usually works:

Standard product for standard functions, custom for the differentiator. Off-the-shelf accounting; custom for the operational core that is actually specific. Integrated properly, this gets the maintenance benefit where it matters and the fit where it matters.

Custom on a solid foundation. Not built from nothing — built on established frameworks, standard databases, well-understood patterns. This is what most good custom software actually is, and it is much closer to configuration than the phrase “custom build” suggests.

Configured product, then extended. Start standard, live with it, and build only what proves genuinely necessary after real use. Most of the customisations specified up front turn out to be habits rather than requirements.

Questions that decide it

Before choosing, answer these honestly:

1. What do we do differently, and does it matter to customers? If nothing, take the product. If something, protect it.
2. How much of our process is deliberate and how much is accident? Accidental process should be replaced, not encoded.
3. What has to integrate, and how well does each option do it?
4. Who supports it when it breaks at month end, and how fast?
5. What does year three cost? Licences and users for a product; changes and maintenance for a build. Compare over years, not at purchase.
6. Can we leave? Where is our data, in what format, and how hard is it to move?

Question six matters more than it appears. Both options can trap you: a product through data formats and licence dependency, a build through code nobody else understands. Ownership of the code and exportability of the data are the things to insist on either way.

The failure that is neither

The most common bad outcome is not picking wrongly. It is picking, implementing badly, and running parallel spreadsheets forever — which happens when scope was too large, migration was underestimated, or nobody in the business owned the change.

That failure is indifferent to which option you chose. Phasing the rollout matters more than the build-versus-buy decision, which is why it is worth reading rolling out an ERP in stages before committing to either.

We build ERP software for businesses in Nepal, and we are equally willing to say when a standard product would serve you better — it is a cheaper conversation than a failed implementation. Talk to us.