What an eCommerce Website Actually Costs in Nepal

Ask three companies in Kathmandu to quote for an online store and the numbers will differ by a factor of ten. That is not because two of them are dishonest. It is because “an eCommerce website” describes anything from a themed template with a contact form to a platform that runs a warehouse.

The useful question is not what it costs. It is what you are buying at each level, and which parts you will end up paying for later regardless.

The four levels, and what separates them

A storefront on an existing platform. A hosted platform with a theme, your products loaded, payment and delivery configured. Cheapest and fastest. You are renting software, so it does what it does and no more. Right for a first store, a small catalogue, and a business testing whether online selling works at all.

A customised platform build. The same foundation, but with meaningful changes: a checkout flow that suits how you actually sell, custom shipping rules, integrations with your accounting or courier. Cost rises with the number of things that have to behave differently from default.

A custom storefront on a headless backend. The front end is built specifically for you; the commerce engine behind it may be off-the-shelf. Justified when the buying experience is a competitive advantage, or when you need the same catalogue driving a website, an app and a marketplace feed.

A full custom platform. Everything built, because the business does something no product supports — complex B2B pricing, dealer hierarchies, made-to-order configuration, or integration into an existing ERP that will not move.

Most businesses in Nepal need the second level and get quoted for the first or the fourth.

What actually moves the price

Within any level, these are the real cost drivers:

Catalogue complexity. Fifty simple products is a different job from five thousand with variants, bundles, and per-variant stock. Variants in particular multiply everything — images, stock records, pricing rules.

Payment methods. Cash on delivery plus one wallet is simple. Multiple wallets, cards, bank transfer and partial payments each add integration, testing and failure handling.

Delivery logic. Flat rate is free. Zone-based pricing, weight-based pricing, free-shipping thresholds, different couriers for different districts, and same-day within the valley all add real work.

Integrations. Every external system — accounting, ERP, courier, marketplace, SMS — is a project of its own. Two integrations is not twice one; it is more, because failures now have to be handled across systems.

Content and product data. The most consistently underestimated item. Photographing, writing and structuring a thousand products is weeks of work, and it is usually assumed to be free by both sides until launch approaches.

Design. A theme with your colours costs almost nothing. A designed experience is a separate discipline with its own timeline.

The costs that arrive after launch

Quotes usually cover the build. The recurring costs are what determine whether the store is affordable in year two:

• Hosting, which scales with traffic and catalogue size
• Domain and SSL — small, but they lapse and take the site down when they do
• Payment gateway fees, per transaction, which are a permanent percentage of revenue
• SMS credits for order confirmations and delivery updates
• Maintenance and security updates, which are not optional
• Changes — every store needs them, monthly at first

That last one is the honest one. A store that never changes after launch is a store nobody is running. Budget for continuous small changes rather than treating the build as finished.

Where cheap becomes expensive

Three failure patterns account for most of the rebuilds we see:

A theme customised past what it was built for. Themes are cheap because they assume defaults. Push twenty changes into one and you have a fragile system that breaks on every platform update, and it costs more to maintain than a proper build would have cost outright.

No integration with anything. A store that does not talk to your stock or your accounting means someone re-enters every order. That person’s time is a permanent cost, and it grows exactly as fast as the business does.

Nobody can change it. Built by someone unreachable, on a stack nobody local knows. The site works until it needs to change, and then the only option is to rebuild.

Questions that produce comparable quotes

Vendors quote differently because briefs are vague. These make the numbers comparable:

1. How many products, and how many variants each?
2. Which payment methods, specifically?
3. What are the delivery rules, exactly — zones, weights, thresholds?
4. Which systems must it integrate with, and in which direction does data flow?
5. Who produces product content and images?
6. What is included in support after launch, for how long, and what is the response time?
7. Who owns the code and where does it live?
8. What does a typical change cost after launch?

Question seven is the one to insist on. If you do not own the code and cannot move it, every future quote from that vendor is effectively unchallengeable.

A reasonable sequencing

For most businesses starting out, the cheapest route to a working store is not the cheapest quote:

1. Launch on a customised platform with a real payment method and one courier integration
2. Get to a few hundred orders and learn what actually breaks
3. Invest in the specific problem the data reveals — usually inventory sync or delivery cost
4. Only then consider a custom front end

Building the fourth-level platform before you have order volume means building for guesses. Nearly every expensive rebuild we see started as an over-specified first version.

We build eCommerce software for online sellers in Nepal, from customised storefronts to platforms integrated with logistics and accounting. If you are comparing quotes and they are not comparable, talk to us — we are happy to tell you which level you actually need.