Building Software for Nepal: Problems Developers Should Be Solving

A lot of software built in Nepal is a copy of something built for San Francisco, with the same assumptions about fast internet, English-speaking users and card payments. The interesting problems here are the ones those assumptions hide.

I'm based in Nepal, Asia, and most of what I've worked on has users in Nepal: restaurants, small businesses, farmers, learners. Over time I've noticed the same gaps showing up again and again. Not missing apps, exactly. Missing care for how people here actually use software.

This is a list of problems I think more Nepali developers should take seriously. Some I've worked on directly. Some I just keep running into.

Networks that come and go

Connectivity in cities has improved a lot, but it's still uneven. Mobile data drops between buildings. Rural areas are patchy. Plenty of people buy small data packs and are careful about what they spend them on. And anyone who lived through load shedding remembers when "the internet is down" was a daily schedule, not an outage.

Most web apps still treat a network request as something that just works. They show a spinner forever, lose form input on failure, or need several megabytes of JavaScript before the first useful pixel.

What I think we should build by default:

• Offline-capable core flows. In NovaRestro, waiters can keep taking orders when the connection drops, and the orders sync when it returns. A restaurant can't stop serving because the router rebooted.
• Small first loads. Server-render what you can, lazy-load the rest, and actually test on a throttled connection.
• Forms that survive failure. If a submit fails, the data should still be there. Ideally it queues and retries.
• Clear network states. Tell people when they're offline and what will happen to their work.

Nepali language support that isn't an afterthought

A surprising number of apps aimed at Nepali users are English-only, or have a Nepali toggle that translates half the screens. For a big part of the population, especially outside the cities and among older users, that's a wall.

Real Nepali support means more than translating strings. It means testing Devanagari rendering in every component, handling longer labels, choosing whether to show Nepali or Latin digits, and letting people search in Nepali, in romanized Nepali, or in a mix. I wrote up the technical side in building a multilingual Next.js application, but the harder part is deciding early that Nepali is a first-class language, not a feature for later.

The calendar problem

Nepal runs on Bikram Sambat. Government documents, school calendars, a lot of business records and most people's sense of dates use BS. Almost every date picker, database and reporting tool assumes Gregorian.

This sounds like a small detail until you build a report and the owner asks for "Shrawan's sales" and your system only knows July and August. Good BS support means conversion you've actually tested, date pickers that show BS natively, and storing dates in a standard format while displaying them in whatever calendar the user thinks in. There are libraries for this. Fewer apps use them than should.

Payments that match how people pay

Cards are not how most people here pay online. eSewa and Khalti are, along with bank transfers, QR payments and plenty of cash on delivery. Integrating these wallets is well-trodden now, but the edge cases are where apps fall apart:

• Payment confirmed, callback lost. The user's wallet shows the money gone, your app shows the order unpaid. You need server-side verification and reconciliation, not just a redirect handler.
• Mixed payments. At a restaurant, one table might pay part in cash and part by QR. Split billing was one of the trickier parts of NovaRestro for exactly this reason.
• Cash as a real payment method. Not an afterthought checkbox. It needs the same audit trail as digital payments.

Small businesses with real operational problems

Nepal's economy runs on SMEs: restaurants, shops, clinics, small manufacturers, travel agencies. Many still run on paper, a Facebook page and a lot of phone calls. The software available to them is often either too basic or built for a much bigger company with an IT team.

What they need is boring and valuable: inventory that matches what's on the shelf, staff roles so the owner isn't the only person who can do anything, billing that the accountant can use, and reports in a form they understand. That's what pushed me toward building NovaRestro. Restaurants have complex operations, and the existing options didn't fit how restaurants here actually work.

The opportunity isn't a flashy app. It's taking a messy, real workflow that people already do every day and making it slightly less painful.

Agriculture and knowledge access

A large share of Nepal's population works in agriculture, and good information about crops, pests, seasons and practices is scattered across government sites, PDFs, radio programs and word of mouth. A lot of it isn't in Nepali, isn't searchable, or doesn't load on a weak connection.

I've been working on an agriculture knowledge platform with exactly these constraints in mind, and it's changed how I think about content-heavy apps. When your user might be standing in a field with one bar of signal, every design decision changes.

Public services and forms

Anyone who has dealt with government paperwork here knows the pattern: a PDF to download, print, fill by hand, and submit in person, sometimes after a long trip. Digital versions exist for some services, but they're often hard to use on a phone, break on slow connections, or don't save progress.

You don't need a government contract to help. Clear guides, checklist tools, document preparation helpers and better-designed interfaces on top of public information are all things developers can build.

Accessibility and low-end devices

The phones people actually use here are often budget Android devices, sometimes a few years old, with limited storage and RAM. A web app that's smooth on my MacBook can be unusable on those.

Practical habits:

• Test on a cheap Android phone. Keep one around. Emulators lie about performance.
• Respect storage. A 150MB app is a hard sell when the phone is already full of photos and WhatsApp media.
• Readable type and contrast. Bright sunlight, small screens and older eyes all punish low-contrast, small text.
• Simple flows. Fewer steps, fewer choices per screen, clear primary actions.

Trust and data

People are rightly cautious about giving their data to apps. Too many local apps ask for permissions they don't need, store passwords badly or leak customer data through careless APIs. If we want people to trust Nepali software, we have to earn it: proper auth, permission checks on the backend, minimal data collection, and being clear about what we store.

What I'd tell you

If you're a developer in Nepal looking for something worth building, don't start from "what's popular abroad that doesn't exist here yet." Start from a real workflow that's painful for real people near you, then design for the conditions they actually live in: shaky networks, Nepali language, BS dates, wallet and cash payments, cheap phones.

Those constraints aren't obstacles to good software. Solving them well is the good software. And the developers who get good at it will build things that work better everywhere, not just here.