Custom Software or SaaS? A Practical Test for Nepali Businesses

The buy-versus-build argument is usually conducted at the wrong level. It is not a decision about your company. It is a decision per capability, and most businesses should be doing both — a product where the problem is universal, a build where it is not.

Here is a way to decide that does not depend on which vendor you spoke to most recently.

The test: is this how we compete?

For each capability, ask whether the way you do it is a reason customers choose you.

Email, accounting, payroll, document storage, video calls. Nobody chooses a supplier because of their email system. These are universal problems, solved well by products, and building your own is spending money to end up with something worse.

The operational core. For a courier, that is how consignments and cash move. For a manufacturer, how production is planned. For a distributor, how pricing and credit work per customer. If this is where you are better than competitors, a product that standardises it removes exactly the thing that made you better.

Most businesses have one or two capabilities in the second category and everything else in the first. The mistake in both directions is treating the whole business as one answer.

Where SaaS wins clearly

It exists now. Available today, versus months of building.

Someone else maintains it. Security patches, new features, compliance updates arrive without a project.

Costs are predictable and start small. A subscription is a number you can plan around, and you can stop.

It has been tested by thousands of businesses. Every edge case you have not thought of has already been hit by someone else.

You can leave. Usually. Check this before assuming it.

Where SaaS costs more than it looks

Per-user pricing punishes growth. It also encourages rationing access to the system that is supposed to be everyone’s source of truth. Businesses end up with staff sharing logins, which breaks the audit trail entirely.

The gap between “supports” and “supports well”. Most international products technically support multiple currencies, custom fields and workflow rules. Whether they support your specific case acceptably is a different question, answerable only by testing with your real data.

Local fit. A product built for another market may not handle the Bikram Sambat fiscal year, VAT treatment here, landmark-based addressing, or a cash-on-delivery order lifecycle. Some of this is workable around. Some is not.

Integration limits. You can only connect what their API exposes. If the thing you need is not in it, there is no route.

Support distance and priority. A small customer in a small market gets the response time that implies. For a system your operations depend on, that is the real risk.

Price changes. The subscription is set by someone else and can rise. Once your business runs on it, your negotiating position is weak.

Where custom wins clearly

No product fits the domain. Nepali courier and cargo operations are a clean example — COD custody chains, franchise branch settlement, landmark addressing. No international product models them, and configuring one to do so is a larger project than building.

Integration is the requirement. If the job is mostly connecting systems you already run, a product with its own opinions about data is an obstacle.

The process is the advantage. Covered above; the important case.

Economics at scale. Above a certain headcount, per-user subscriptions across several products can exceed the amortised cost of a build. Do this arithmetic over three to five years rather than at signup.

Where custom costs more than it looks

You maintain it forever. Dependency updates, security patches, browser changes, hosting migrations. Software that is not maintained degrades.

Key-person risk. If one developer understands it and leaves, you have a problem. Mitigated by documentation, code ownership and choosing mainstream technology — but never eliminated.

No community. You cannot search for how someone else solved it. Every question is answered by your team.

It only does what you asked for. A product improves without you doing anything. Custom software improves only when you fund it.

The hybrid most businesses need

In practice the arrangement that works:

• Product for the universal: accounting, email, storage, HR administration
• Custom for the operational core: the thing that is actually yours
• Integrated between them, so data is entered once

The integration is the part that gets skipped and the part that determines whether the arrangement works. Without it you have two systems and someone re-typing between them, which costs more than either decision saved.

A decision procedure

Per capability:

1. Is how we do this a reason customers choose us? If yes, lean custom.
2. Does a product genuinely handle our cases? Test with real data, not a demo.
3. What does it cost over five years, both ways, including maintenance and integration?
4. What happens if the vendor raises prices, is acquired, or shuts down?
5. Can we get our data out, in a usable format?
6. Who supports it when it breaks at month end?

Question two is where most decisions are actually made and where most are made badly, because demos are run on clean sample data and your data is not clean.

Start with a product, usually

For a business that is not sure, the pragmatic path is to start with a product, use it properly for a year, and let it show you where it does not fit.

You will end up with a specification grounded in real friction rather than in guesses — and a fair chance that the friction you expected was not the friction you got. Nearly every over-specified custom build we have seen was designed by someone who had not first tried the simple thing.

We build custom software for businesses in Nepal and will say plainly when a subscription product would serve you better. Talk to us.