Building software for the way Nepal works
The best local software pays attention to how people already work, then removes the friction that gets in their way.
When I sit with a team before building anything, I ask them to show me the work as it happens. I want to see the register on the desk, the spreadsheet that everyone trusts, the phone call that settles a question, and the signature that cannot be skipped. A process diagram gives me a starting point. The working day gives me the product.
In Nepal, those details carry context that a generic template misses. A municipality may keep a record in Nepali while another office reads the same information in English. An organization may use a fiscal year that does not match the dates a new system puts at the top of a report. A field team may have an unreliable connection and still need to record an important visit. These conditions are part of the brief. They are not unusual cases to push into a backlog.
The first decision I make is usually a small one. Which part of the process causes the most repeated work? Which record gets copied from one place to another? Which person has to remember a rule that the system should explain? I start there. A single clear form can remove more friction than a large dashboard if it carries the right decision and leaves the rest of the workflow familiar.
Language matters in the same way. Translation is not only a button that changes English labels into Nepali labels. It affects names, dates, search, printed records, and the confidence a person has when they submit something important. If the office uses one set of words, the system should not make the staff learn a second set just to complete a form. Labels should follow the work.
The same applies to identity and access. A small organization may have one person who receives a request, another who checks it, and a manager who approves it. The system needs to show those responsibilities without turning the process into a maze of technical permissions. Good access control makes the next action clear. It also keeps a useful record of who changed what.
I have found that local context often appears in the edges of a project. The main workflow looks familiar. The edge contains the real requirement: a document that must print correctly, a date that needs a second calendar, a name that has several accepted spellings, or a report that has to travel from a local office to a central one. I look for those edges early because they decide whether a system feels natural after launch.
This way of working does not mean building a different product for every office. It means separating the stable parts from the local decisions. Records, roles, search, backups, and reporting can follow clear patterns. The language, approval path, and document shape can respect the organization that uses them. That balance keeps a system maintainable without asking people to work around it.
The useful question is simple: what does this team already understand, and where does the current process make them spend time without adding value? The answer gives me a better starting point than a list of fashionable features.
Software should meet people where the work is. If a workflow is worth improving, I want to understand its real shape before I draw the first screen.
