This guide is for owners and managers in Nepal who have outgrown spreadsheets, notebooks and WhatsApp groups, and now face a choice: buy a ready-made system, or have one built? Both can be the right answer. The aim here is to help you decide on your own facts, and to know what to ask whichever way you go.

The short version

  • Buy off-the-shelf when your process is common, a good product already fits most of it, and you can adapt the rest of your work to the tool.
  • Build custom when the way you work is your advantage, when no product handles your local needs, or when you’d otherwise pay for and fight several tools that don’t talk to each other.
  • Go hybrid more often than you think: use standard tools for standard jobs, and build only the part that makes you different.

Seven criteria that actually decide it

1. Process fit

List the ten things your team does every day, step by step. Then test a product against your list, not its demo. If a product covers eight of the ten and the other two can change without hurting customers, that’s a strong fit. If the missing two are exactly what customers pay you for, it isn’t.

Watch for “we’ll customise it for you” from product vendors. Heavy customisation of someone else’s product can combine the downsides of both options.

2. Local payments and messaging

Many international products assume card payments and email. Your customers may expect to pay by eSewa, Khalti or a Fonepay QR, and to get updates by SMS or a messaging app. eSewa and Khalti publish developer documentation for connecting their checkout to a website or app, so a custom system can build this in. With a ready-made product, check whether it supports Nepal’s payment options today, not “on the roadmap”.

Also ask how the system handles bills and tax records. Nepal’s Inland Revenue Department runs a Central Billing Monitoring System (CBMS) and publishes technical documentation for software developers connecting billing systems to it. If electronic billing rules apply to your business, confirm that any system you choose meets them. Check with the IRD or your tax adviser rather than taking a vendor’s word for it.

3. Language and local conventions

Consider whether your staff or customers need Nepali (Devanagari) screens, receipts or messages. Consider whether you work with Bikram Sambat dates alongside Gregorian ones, and whether amounts appear in the formats your customers are used to. Small mismatches here create daily friction and training costs.

4. Offline and poor-connection use

Power cuts and weak mobile data are real in many places. Ask what happens when the internet drops in the middle of a sale or a check-in. Does the system queue the work and sync later, or does everything stop? Web applications can be designed to handle poor connections, and a desktop application can work fully offline and sync when it can. Many ready-made cloud products need a steady connection, so test this before you commit.

5. Data ownership and privacy

Your customer list, order history and records are business assets. Ask any vendor:

  • Can we export all our data in a usable format, at any time?
  • Where is the data stored, and who at the vendor can see it?
  • What happens to our data if we stop paying or the vendor closes?

If you hold personal information about customers, patients or students, remember that Nepal has a Privacy Act, 2075 (2018), which covers personal information. Take advice on what it means for how you collect and store that information.

6. Integration with what you already use

Most businesses already have an accounting package, a website, a Facebook page, a bank account and perhaps a booking channel. The real cost of software often comes from re-typing data between systems. Check what connects out of the box, and what would need custom work either way.

7. Total effort, not just the price tag

Fees and quotes vary too much to compare here. Compare effort instead:

Off-the-shelf Custom
Time to start Days to weeks Weeks to months, usually in stages
Fit to your process You adapt to the tool The tool adapts to you
Ongoing changes Vendor decides; you request You decide; you pay for changes
Local payments, language, offline Depends on the product Built in where you need them
Data control Per vendor terms Yours, if the contract says so
Risk Vendor changes prices, features or shuts down Poor build quality or an absent developer
Staff training Generic material may exist Must be planned as part of the project

Hybrid options that often win

  • Standard core, custom edges. Keep your accounting package and build a small web application for the part that is unique, such as job tracking, bookings or a customer portal, with a connection between the two.
  • Custom front, standard back. A customer-facing site or app built for you, using proven services behind it for payments, messaging and hosting.
  • Automation in between. Sometimes the answer is neither new software nor a new product, but automation that moves data between tools you already have, sends reminders, or drafts routine replies for a person to check.
  • Start small, then decide. Run a ready-made tool for a few months and write down every workaround. That list becomes the specification for a custom system if you need one.

Questions to ask any vendor or developer

For a product vendor:

  • Can we trial it with our real data and our real process?
  • Does it support eSewa, Khalti or Fonepay, Nepali language and Bikram Sambat dates today?
  • What works when the internet is down?
  • How do we export everything if we leave?
  • Who supports us locally, and in which hours?

For a custom developer:

  • Who owns the source code and the data when the project ends?
  • Will we get working software in stages, or only at the end?
  • How will it be tested before our staff rely on it?
  • Where will it be hosted, who has access, and how is it backed up?
  • What happens when we need a change a year from now?
  • Is there documentation another developer could use?

If a vendor or developer is vague on ownership, backups or exporting your data, treat that as a warning, whatever the price.

Red flags on either side

  • A demo that never uses your example
  • “Everything is possible” with no written scope
  • No clear answer on who can access your data
  • A plan where your staff learn the system on launch day

Where we fit

We build custom web applications and desktop software, and connect them to the tools you already use. We’ll also tell you when a ready-made product is the better choice for you.

Sources