
A practical guide to hiring a web development company in Nepal — what to ask about ownership, contracts, payments and maintenance before you sign.
Most businesses do not choose a web development company badly. They choose one quickly, and the difference only shows up much later.
The decision usually happens over two or three meetings. Everyone is polite, the quote looks reasonable, the portfolio looks fine on a phone screen, and the site goes live roughly on time. The problems arrive eighteen months on, when someone wants to change the pricing page and nobody can log in, or when the hosting invoice goes unpaid and the site quietly disappears for a week.
So this guide is organized around the way regret actually happens, rather than around a checklist of features. If you are hiring in Kathmandu, Pokhara, Biratnagar or anywhere else in Nepal, the questions below are the ones worth spending your energy on.
Nearly every difficult project starts the same way: the client asked for a website when what they needed was a specific business outcome.
There is a real difference between "we need an online presence" and "we lose thirty enquiry calls a week because people can't find our price list after 6pm." The first brief invites a vendor to sell you whatever they build most often. The second tells them what success looks like, which means you can hold them to it later.
Write down the single thing the site must do in its first year. Book appointments. Take orders. Reduce phone enquiries. Convince a foreign buyer that your manufacturing operation is credible. Then write down how you would know whether it worked. This takes an afternoon and it changes the quality of every proposal you receive.
Here is an unpopular opinion from the buying side: an agency that cheerfully agrees to every feature you mention is not being helpful. If you list a booking system, a blog, a member login, a multi-language toggle and a chat widget, and the response is an enthusiastic yes with a price attached, you are talking to an order-taker. Good firms argue with the brief. They will tell you the login is unnecessary and the blog will be abandoned by month four, because they have watched it happen.
Portfolios are curated, which is fair enough. The trick is to interrogate them rather than admire them.
Ask which sites are still live and open two or three on your own phone, on mobile data rather than office wifi. Look at how long the homepage takes before you can read something. Check whether the design survives on a small screen or whether the text has been squeezed into an unreadable column. A surprising number of portfolios contain work that has since been redesigned by somebody else, which tells you something about how those relationships ended.
Then ask a harder question: which of these did you build from scratch, and which were assembled from a purchased theme? Neither answer is wrong. A well-chosen WordPress theme is a perfectly sensible foundation for a restaurant or a clinic, and pretending otherwise wastes your money. But you should know which one you are paying for, because the price of a themed build and the price of a custom build differ by a factor of several, and some firms are not eager to volunteer the distinction.
Relevance beats prestige. A company that has built four clinic sites understands why your reception staff need appointment data in a format they can actually use. A firm with a glossy bank project and no experience of your sector will be learning on your budget.
Most buyers try to evaluate technical skill by asking which technologies a firm uses. The honest answer is that the framework matters far less than people assume. React, Laravel, WordPress, Shopify — each is capable of producing an excellent site and an unmaintainable disaster, and the deciding factor is discipline, not the tool.
What actually separates competent teams is narrower and easier to test.
Ask how the site will be hosted and where. Latency to Nepali visitors is a genuine consideration, and so is who holds the hosting account. Ask what happens to performance when the homepage carries twelve unoptimised photographs, which is where most Nepali business sites lose their speed. Ask how they handle backups, and specifically whether backups are stored somewhere other than the server being backed up.
If your site takes payments, this is where technical skill stops being abstract. Nepal's Electronic Commerce Act, 2081 requires sellers to use payment gateways or methods licensed by Nepal Rastra Bank, and NRB publishes the current list of licensed payment service providers and operators. Any developer proposing a payment flow should know that list exists. There is also a specific implementation failure worth naming, because it is common: after a customer pays, the wallet redirects them back to your site, and a careless developer treats that redirect as proof of payment. It is not. It has to be verified server-side against the provider, or you will eventually ship orders that nobody paid for.
Practical payment advice for most Nepali businesses: start with the wallets your customers already use, keep the integration to one or two providers rather than all of them, and treat bank-network QR as a separate conversation with your acquiring bank, since that route runs through a bank rather than an instant online signup.
Everyone shows you an attractive homepage mockup. Very few firms can explain the reasoning behind it.
Ask why the primary button is where it is. Ask what they expect a first-time visitor to do within eight seconds of landing. Ask to see the design of a page that is not the homepage — a product detail page, a form, an error state — because that is where careless work hides. Homepages get all the attention and almost none of the traffic that matters.
The pattern worth being alert to is design by committee inside your own organization. A common way projects derail in Nepal is that the brief expands informally through WhatsApp messages from three different people, none of whom is formally the decision-maker. Name one approver at the start. It will save you more money than any negotiation over the quote.
A great deal of nonsense is sold under the heading of SEO, so be precise about what you are buying.
Some things are simply build quality and should be included without an extra line item: sensible page titles, descriptive URLs, compressed images, working internal links, a site that does not shift around while it loads. Google's Core Web Vitals thresholds — largest contentful paint at or under 2.5 seconds, interaction to next paint at or under 200 milliseconds, cumulative layout shift at or under 0.1, measured at the 75th percentile — have been stable since March 2024 and give you a concrete standard to hold a developer to.
But be careful with the promises attached to them. Google is unusually direct on this point, stating that there is no single page experience signal, that good Core Web Vitals do not guarantee good rankings, and that trying to get a perfect score "just for SEO reasons may not be the best use of your time." Any agency selling speed optimization as a ranking guarantee is overselling.
If local search matters to you, spend some of your budget on your Google Business Profile rather than only on the website. Google's own documentation describes local ranking as a combination of relevance, distance and prominence, and confirms that review count and rating feed into local results. It also warns that padding your business name with keywords or a city can lead to suspension of the profile. That warning is easy to ignore, and the risk is real.
This is the section most buyers skip. It is also the one that decides how much bargaining power you have in two years.
Four things need to be written down, not assumed.
Ownership of the code and design files. State plainly that on final payment, all source code, design files and content belong to you. Without this, you may find that a redesign means starting over.
Control of the accounts. The domain, hosting, DNS, analytics and payment gateway credentials should be registered in your business's name with your email as the primary contact, even if the agency manages them day to day. This is one of the most common ways Nepali businesses get trapped. A .np domain is registered through Mercantile and is issued free of charge, tied to your citizenship or company registration documents — so there is no cost argument for anyone else holding it. Ask for administrative access and confirm you can log in before the final invoice is paid.
What handover means. Define it as a list: repository access, a written record of where things are hosted, a short document explaining how to update content, and a working staging environment if one exists. "We'll send the files" is not a handover.
Revisions and scope. Two rounds of revision at each stage is a reasonable standard to ask for. Unlimited revisions sounds generous and produces projects that never end.
While you are in legal territory, note that the E-Commerce Act, 2081 obliges online sellers to list on the Department of Commerce e-commerce portal and display that listing number, alongside registration and PAN or VAT details, a grievance contact, and clear delivery, cancellation, return and refund terms — and to acknowledge complaints and decide them within about fifteen days. Those are pages on your website. If a proposal for an online store does not mention them, the vendor has not read the law.
Launch feels like the finish line. It is closer to the halfway point.
An unmaintained site does not fail dramatically. It decays. A plugin goes out of date, then another, then a vulnerability in one of them gets exploited by an automated scanner that has never heard of your business and does not care what it does. Most compromises of small business sites are not targeted attacks. They are automated, and they succeed because nobody applied an update for a year.
Ask what a maintenance plan actually includes, in hours and in scope. "Support" is a word, not a commitment. Does it cover core and plugin updates, backup verification, uptime monitoring, and a defined response time? Are content changes included, and how many? Is there a documented escalation path when the site goes down at 9pm before a festival sale?
Then ask the awkward question: what does it cost to leave? A firm confident in its work will answer plainly.
Use this to compare shortlisted firms side by side. Score each from 1 to 5 and pay attention to the low numbers rather than the total.
| What to check | What good looks like | Warning sign |
|---|---|---|
| Brief handling | Challenges your assumptions, narrows scope | Agrees to everything |
| Portfolio | Live, relevant, still theirs | Screenshots only, sector mismatch |
| Build approach | States clearly whether theme or custom | Vague about the distinction |
| Hosting | Named provider, account in your name | "We'll handle it" |
| Payments | Knows NRB licensing, verifies server-side | Treats redirect as confirmation |
| SEO claims | Explains what is included in the build | Guarantees rankings or positions |
| Ownership | Written transfer of code and files on payment | Silent or ambiguous |
| Accounts | Domain and DNS in your business's name | Registered under the agency |
| Revisions | Defined rounds per stage | "Unlimited" |
| Maintenance | Scope, hours, response time in writing | The word "support" alone |
| Exit | Clear handover and exit terms | Evasive |
The cheapest quote is usually cheap for a discoverable reason, and it is worth discovering it before signing rather than after. Often the saving comes from a theme rather than a custom build, from skipping testing, or from excluding maintenance that will be quoted separately later.
That said, the reflexive advice to avoid the lowest bidder is also lazy. For a small retailer who needs six pages and a contact form, a modest, competently executed themed build is the correct answer, and paying four times as much for a custom application is a waste. Match the spend to the job. The failure mode is not cheapness — it is a mismatch between what you paid for and what you assumed you were getting.
Compare quotes only when they cover the same scope. If they do not, ask each firm to re-quote against a written list of the same deliverables. Half of them will not bother, which is itself useful information.
If you take one thing from all of this, make it the ownership question. Skill can be replaced and design can be redone, but a business that does not control its own domain, hosting and code has handed over a piece of itself without noticing.
At Webpal we spend a fair amount of the first meeting on exactly these questions, partly because clarity early prevents disputes later, and partly because the projects that go well are almost always the ones where the client knew what they were buying.
Ask the hard questions before you sign. A firm worth hiring will not mind them.
Thinking through a website project and want a second opinion on the scope before you commit? Talk to the team at Webpal — bring your brief, or just the problem you are trying to solve.