The questions we are actually asked, answered directly. If yours is not here, ask us — we would rather have the conversation than have you guess.
Operational systems for businesses in Nepal: logistics and courier management, cargo and freight, eCommerce platforms, and ERP covering accounting, inventory, HR and payroll. The common thread is software a business runs on daily rather than marketing sites — dispatch screens, billing counters, stock control and the ledger behind them.
No. Most of our clients are here, and that is where our domain knowledge is deepest, but we also work with clients abroad. Nepal is UTC+5:45, which gives a full working-day overlap with Europe and substantial overlap with Australia and Southeast Asia.
Yes, and we usually recommend it. A four-to-six week piece of real work tells both sides more than any evaluation process, and it costs a fraction of what a bad engagement costs. Most of our long-term client relationships started that way.
Yes. The code is yours, it lives in your repository, and you have access from the first day of development rather than at handover. We think a client who cannot take their code elsewhere has no leverage in any future conversation, which is bad for them and eventually bad for us.
Our own team, in Kathmandu. You will talk to the developers building your system rather than to an account manager relaying questions — which is usually the difference between a same-day answer and a week.
It depends on scope, and quotes for the same brief routinely differ by a factor of five because a vague brief is a different project to each person reading it. The real cost drivers are the number of distinct user roles, the number of external integrations, workflow complexity, and data migration. We wrote a full breakdown in our post on what drives the cost of custom software in Nepal.
Both, depending on how well the scope is understood. Fixed price works when a phase is genuinely well defined; time and materials works when it will evolve, which is most real projects. A common arrangement is a fixed price for a well-defined first phase, then time and materials once both sides know each other.
A focused first phase is typically a matter of weeks; a full platform is months. The largest source of delay is rarely development — it is data migration and decisions waiting on the client side. Projects with one empowered decision-maker move roughly twice as fast as projects without one.
Hosting, any third-party services such as SMS or payment processing, maintenance including security and dependency updates, support, and changes. Every system in active use needs continuous small changes; a build with no ongoing budget becomes a system nobody can change, which is how businesses end up rebuilding in three years.
You contact us and reach a person who has worked on your system, during your working hours, in your language. For systems where an outage stops the business — a billing counter, a dispatch screen — that matters more than any feature comparison, because the response time is what determines the cost of the outage.
Yes. The systems we build stay ours to maintain. A new report, an extra field or a process that has changed is a change to software we own, not a support ticket with a vendor abroad who has your account as a small line item.
Sometimes. It depends on the state of the code, whether it uses mainstream technology, and whether documentation and access exist. We will look at it and tell you honestly whether taking it over or rebuilding is the better use of your money — those conversations frequently end with us recommending against a rebuild.
Yes, and it is the part that matters most in this market. The system models the COD amount separately from the delivery charge and from what was actually collected, tracks the custody chain from rider to branch to bank to merchant, applies each merchant's rate card automatically, and maintains a running merchant ledger — so settlement can be daily rather than weekly.
Yes. Branches and franchise partners are modelled separately, with data isolation so a franchise sees only their own consignments and settlements. Consignments move between branches as bagged, manifested transfers with custody recorded at each handover, and inter-branch revenue splits are computed by the system rather than reconciled by hand.
Yes. Cargo is not simply larger courier — it needs chargeable weight by mode, piece-level tracking, consolidation under master airway bills or bills of lading, and document generation for commercial invoices, packing lists and customs paperwork. Operators running both domestic courier and international cargo can run them on one platform with a shared customer record and ledger.
Yes to both. Riders lose signal regularly, so the app captures deliveries, proof of delivery photographs, signatures and cash amounts locally and syncs when connectivity returns. Capture time and sync time are stored separately, so a record captured at 14:20 and synced at 18:05 is never presented as though it happened at 18:05.
The domestic options in common use — wallets such as eSewa and Khalti, Fonepay, ConnectIPS for direct bank transfer — as well as card processing where you need it. In practice most sellers here need cash on delivery plus one or two wallets; each additional integration is code that has to keep working, so we add them because a customer segment needs them rather than for completeness.
Yes, where the courier has a usable API. A working integration pushes the consignment and gets a tracking number back, returns a printable label, pulls delivery status to update the order and notify the customer, and reconciles COD settlement against orders. We build the systems on the courier side of that integration too, which tends to help.
Yes, and most successful sellers do. The important part is that both channels draw on one stock pool, one product catalogue and one order queue — otherwise you oversell, your product data diverges, and someone spends their week reconciling channels by hand.
It produces tax and abbreviated invoices in the required format with sales and purchase registers that reconcile against the ledger, because they are the same data viewed two ways rather than separately maintained. Invoice formats are configurable rather than hard-coded, so a change in requirements is a data change, not a software release. Your auditor remains the authority on current requirements.
Yes — read-only access with their own login, scoped to the entity and periods in scope, with the ability to run any report and drill into any transaction but no ability to post, edit or delete. Combined with a complete change history and period locking, this is what turns an audit from a reconstruction into a review.
Yes. Salary structures are component-based with effective dating, statutory rates are configurable and effective-dated so last year's payroll still recomputes correctly, and the system works in both Bikram Sambat and Gregorian calendars — using BS where the business and the regulator do, for fiscal year boundaries, leave years and payroll periods.
No, and we would advise against it. We phase rollouts so each stage is useful on its own — typically starting with whatever is costing the most manual work rather than with the general ledger. If the project stopped after a phase, the business should still be better off than before it.
We migrate master data and opening balances as at the cutover date, and usually recommend keeping the old system read-only for historical transactions rather than migrating years of history — it is expensive, it is where most migration errors originate, and the benefit is rarely worth it. Nothing goes live until stock values, customer balances and supplier balances reconcile exactly against the old system.
Most of what we build starts with a conversation about how a business actually operates rather than about software. If you want to have that conversation, get in touch. There is also more detail on specific topics onour blog.