Custom software helps some Nepali businesses and wastes money for others. An honest look at build vs buy, real costs, and how to decide which you need.
Most business owners do not wake up wanting custom software. They wake up frustrated.
The stock ledger says one thing and the shelf says another. The accountant asks for a sales export that takes two hours to assemble by hand. A customer calls about an order and three people have to be phoned before anyone can answer. Somewhere in that daily friction, a question forms: could we just build something that fits us?
That question deserves a serious answer, not a sales pitch. Custom software is genuinely transformative for some businesses and an expensive mistake for others. The difference is rarely about company size or budget. It is about whether the problem you are solving is actually yours, or whether you have simply not looked hard enough at what already exists.
What "custom" really means
A custom system is software built around one organisation's way of working rather than the average of ten thousand organisations. That is the whole definition, and it is less exotic than it sounds.
Off-the-shelf products carry a hidden assumption: that your business resembles the businesses the vendor studied when designing the product. Often it does. A small firm's payroll is not meaningfully different from any other small firm's payroll, and paying a monthly fee for someone else's well-tested payroll module is the sensible choice.
But the assumption breaks in specific places. A Kathmandu distributor who sells on credit to shopkeepers, collects in cash on a weekly route, and reconciles against consignment returns is not doing anything a standard accounting package anticipated. The distributor can force the process into the software, which means training staff to do something unnatural forever, or they can shape software around the process that already works.
Here is the part that gets missed. The value of custom software is not the features. It is the removal of translation work — the daily mental effort of converting how you actually operate into what the software expects. That translation cost is invisible on any invoice, which is exactly why it goes unexamined for years.
The efficiency argument, examined honestly
Automation is the most cited reason to build, and it is real. Software that generates a report, updates stock levels, calculates a commission, and messages a customer removes work that a person was doing with a keyboard and a mental checklist.
What that argument usually skips is where the savings come from. Automation does not primarily save time. It saves variance. A person preparing a monthly VAT summary will get it right most months. The cost of the exception — the month a figure is transposed, the quarter a return is filed late — is far larger than the hours saved. When we look at what actually justified an automation project after the fact, the recovered hours are usually a smaller number than the avoided mistakes.
This has a practical consequence for anyone scoping a build. Automate the processes where errors are expensive, not the processes that feel tedious. Those are different lists, and business owners almost always hand over the tedious one first.
Integration: the reason most builds pay off
Ask a business what software it uses and you will get a short answer. Audit it and you will get a longer one. There is a point-of-sale system and an accounting package. There is also a spreadsheet the manager maintains privately, a WhatsApp group functioning as an order queue, and a payment gateway dashboard nobody logs into except at month end.
The international data on this is stark. CloudZero's 2025 roundup of software spending research, drawing partly on Zylo's analysis of roughly $40 billion in SaaS spend, reports companies averaging 7.6 duplicate subscriptions with around half of provisioned licences going unused (CloudZero). Nepali SMEs run far smaller portfolios, but the pattern of overlapping tools that do not speak to each other repeats at every scale.
Disconnected systems create a specific tax: the same fact gets typed more than once. An order becomes a stock movement, a ledger entry, a delivery task, and a customer message — four systems, four keystrokes, four chances to diverge. When those figures disagree, someone spends an afternoon deciding which one to believe.
A custom layer that connects existing systems is frequently better value than a custom system that replaces them. This is the recommendation clients least expect and the one that most often proves right. You keep the accounting software your bookkeeper knows, you keep the payment gateway that already clears, and you build the connective tissue between them. Smaller scope, faster delivery, and far less risk than a full replacement.
Nepal makes this easier than it was five years ago. NepalQR, the unified standard set by Nepal Rastra Bank, is built on the same EMVCo QR specification behind Indonesia's QRIS and Singapore's SGQR, and is interoperable by design (NepalQR Standardization Framework and Guidelines, NRB). QR transaction value rose from Rs 20.28 billion in FY 2020/21 to Rs 958.38 billion in FY 2024/25 (New Business Age), and NRB figures put merchant QR codes issued at roughly 2.3 million by early 2024 (NRB Payment Oversight Report). A business building today inherits payment rails that a business building in 2019 would have had to negotiate one bank at a time.
Scalability, and a caution about it
Custom software grows with you. That claim is true, and it is also the most abused sentence in software sales.
Systems grow well when they were designed with clear boundaries between parts. They grow badly when every new feature is bolted onto whatever was convenient at the time. Two systems described identically in a proposal can diverge completely by year three, and the difference is architectural discipline you cannot see in a demo.
There is a related trap worth naming. Businesses often ask for tomorrow's features today — the loyalty programme, the multi-branch support, the analytics dashboard — before they have proven the core. Building for imagined scale is how a three-month project becomes a fourteen-month one that launches into a market that has moved. Build the smallest version that solves a real problem, run it, and let actual usage tell you what comes next. The Standish Group's project data consistently shows small projects succeeding at dramatically higher rates than large ones (CHAOS Report summary).
Treat those figures with some caution, incidentally. Standish's dataset is proprietary, and Eveleens and Verhoef argued in IEEE Software that the published figures cannot be independently verified. The directional finding — smaller scope, better outcomes — matches what practitioners see. The precise percentages should not be quoted as settled fact.
Security is a design decision, not a feature
Custom systems can be built with authentication, role-based access, encryption, backups, and activity logging suited to the actual risk a business carries. A clinic holding patient records and a hardware shop tracking stock face different threats and should not receive the same security posture.
The uncomfortable truth is that custom does not mean secure. A bespoke system inherits exactly the security its developers chose to give it, and there is no vendor pushing patches when a vulnerability appears in a dependency. Established off-the-shelf products have been attacked by more people and hardened accordingly.
So the security case for building is conditional. It holds when you have a specific requirement a product cannot meet — data that must stay on local infrastructure, access rules that mirror an unusual organisational structure, an audit trail a regulator expects. It does not hold as a general principle. Any developer who tells you custom is inherently safer is telling you something they have not thought through.
The cost conversation nobody has early enough
Custom software costs more upfront. Every honest discussion starts there. The argument for it rests on the years after launch: fewer subscriptions, fewer manual hours, fewer errors, a system that changes when the business changes rather than forcing the business to change.
That argument is sound and incomplete. The line item that surprises people is maintenance. Industry estimates — largely from consultancies rather than peer-reviewed research, so treat them as directional — place ongoing maintenance at somewhere between 50% and 80% of a system's total lifetime cost. Galorath's own published figure is around 75% of total ownership cost, and a widely repeated estimate attributed to Gartner holds that organisations spend 55–80% of IT budgets maintaining what they already run (Galorath, ScienceSoft). A common budgeting rule of thumb puts annual maintenance at 15–25% of the original development cost.
No two of those figures agree, which tells you something. The precise percentage is unknowable in advance and depends heavily on how complex the system is and where it runs. But the shape of the finding is consistent enough to plan around: the build is the smaller half of what you will spend.
This reframes the decision. The right question is not "can we afford to build this?" It is "can we afford to keep this alive for five years?" A business that budgets only for delivery ends up with software that slowly decays. Unpatched, unloved, and eventually abandoned in favour of the spreadsheet it was meant to replace. That outcome is common, and entirely preventable at the planning stage.
Where custom work tends to justify itself
Some sectors show the pattern more clearly than others. Retail and distribution benefit where inventory logic is unusual — consignment, credit cycles, multi-location stock that moves between branches. Clinics and small hospitals benefit around scheduling, patient records, and billing, because the workflow between reception, consultation, and pharmacy is specific to each practice. Schools and colleges gain most where fee structures are complex, since fee logic is where standard student systems break first in Nepal. Hospitality benefits when reservations, table management, kitchen orders, and billing need to behave as one flow rather than four.
Notice what these have in common. In each case the custom element sits at a junction — the point where two processes meet and standard software assumes a handoff that does not exist. That is the most reliable signal that building is worth considering. Where your operation is ordinary, buy. Where it is genuinely distinctive, build, and be honest with yourself about which is which.
Choosing who builds it
Technical skill is necessary and insufficient. The projects that fail rarely fail on code quality. They fail on requirements — incomplete at the start, changing throughout, with the client insufficiently involved. Standish's own analysis names user involvement, executive support, and clear requirements as the top predictors of success, and their absence as the top predictors of failure (CHAOS Report).
Read that carefully, because it puts real responsibility on the buyer. A development partner cannot rescue a project that the business owner has delegated and stopped attending.
When evaluating a partner, look for relevant experience over general experience. Ask to speak to a past client rather than only viewing a portfolio. Get the support arrangement in writing before work begins, not after launch. And ask what happens if you want to move to a different developer in two years — the answer reveals whether you are buying software or a dependency. At Webpal we push clients toward smaller first phases for exactly this reason: a short project that ships gives both sides real evidence before anyone commits to a larger build.
A reasonable way to decide
Spend a week documenting how work actually flows through your business, including the spreadsheets and messaging groups nobody counts as systems. Identify the three places where information gets re-entered or where errors are most expensive. Then ask whether an existing product handles those three things, and whether the reason it does not is genuinely about your business or merely about habit.
If a product fits, buy it. If nothing fits at the junctions where your operation is distinctive, build there and only there. Keep the first version small enough to launch within a few months and budget for the years afterward as seriously as for the build itself.
Custom software is a commitment to maintaining something, not a purchase that ends. Businesses that understand this before they start tend to get their money back. Those that discover it in year two tend not to.
Thinking through whether a custom build makes sense for your operation? Talk to Webpal — we would rather tell you honestly that an existing product fits than sell you something you do not need.
Photo by Mohammad Rahmani on Unsplash