A guide, not a pitch
How to choose an IT company in Kathmandu.
There are several hundred IT companies in Kathmandu, and the lists that rank them are mostly ranked by who paid to be on the list. That is not much help when you are the one who has to pick.
So this is the other thing — the questions we would ask if we were buying rather than selling, including the ones that are awkward for us. We are an IT company in Kathmandu and we would obviously like the work. You should still judge us against what follows.
Eight questions worth asking.
Do they look before they quote?
A fixed price offered before anyone has seen your environment is a guess, and guesses get corrected later — on the invoice.
Any provider worth hiring will want to walk through what you have first. If a quote arrives before a walkthrough, ask what it assumes.
Who owns the documentation?
This is the single most revealing question you can ask, and it costs nothing.
Ask what happens to your network diagrams, configuration, passwords and licence records if you leave. If the answer is vague, the arrangement is designed to be difficult to exit. A good provider hands it over because they expect to keep you on the work, not on the lock-in.
Can they cover the whole environment?
Businesses rarely have a pure networking problem or a pure software problem. The expensive faults sit between systems — the application that will not authenticate, the backup that stopped when the storage moved.
A provider who only does one slice will hand you back the parts that are not theirs. Check that support, cloud, security and development are genuinely under one roof rather than subcontracted on the quiet.
Is security part of the service or an upsell?
Multi-factor authentication, patching, access reviews and leaver processes are not a premium tier. They are the baseline, and they should be in the standard arrangement.
If security appears only as a separate proposal, you are being sold the fix for a gap the provider is leaving open.
Do they work the Nepali week?
The working week here runs Sunday to Friday. Saturday is the weekend.
A provider aligned to a Monday-to-Friday calendar is unavailable on your busiest start-of-week day and staffed on your quietest. It sounds small until the Sunday morning something breaks.
Can they attend in person, realistically?
Remote support solves most faults faster. But some work needs hands on the hardware, and Kathmandu traffic turns a ten-minute journey into forty.
Ask where their engineers are based and what on-site response actually looks like on a bad day, not a good one.
Will they explain it without jargon?
You should be able to repeat the explanation to your own team. If you cannot, you have no way to judge whether the recommendation is right, and no way to hold anyone to it.
Technical complexity is real. Deliberate obscurity is a choice.
What happens after go-live?
Plenty of projects are technically correct and still fail, because nobody was there six months later when the business changed.
Ask what support looks like after handover, and whether you will be re-explaining your setup to a new person each time.
Warning signs.
- A price quoted before anyone has seen your systems.
- Reluctance to say who owns the documentation and credentials.
- Security offered as a separate premium tier rather than the baseline.
- Recommendations that always resolve to buying new hardware.
- No written scope, so "that was not included" can arrive later.
- A single individual with no cover when they are unavailable.
- Admin passwords to your systems that you are not given.
Where we stand on all that.
We look before we quote — the walkthrough comes before the proposal, and the scope comes before the work. If something changes along the way, you hear about it before it reaches the invoice.
Everything we build is documented, and the documentation is yours. Your systems, your configuration, your network information. If you ever move on, you leave with what you need. Most of our clients stay anyway.
We work across the whole environment rather than one slice of it — support, cloud, security, automation and development — because the faults that cost the most sit between systems. Security is part of the baseline, not a premium tier.
And we run Sunday to Friday, like the rest of the country, with remote support for the faults that are faster solved from a screen and on-site attendance across Kathmandu for the ones that are not.
IT Support
Someone to call. Someone who already knows your setup.
Cloud
Take your business beyond the server room.
Cybersecurity
The best time to find a weakness is before someone else does.
Web & App Development
Digital experiences designed around real people and real workflows.
Automation
Less repetition. More time for the work that matters.
Common questions.
How much does IT support cost in Kathmandu?
Managed support is usually priced per user or per device per month, and the honest answer is that the range is wide because the scope varies enormously — a plan that covers only the helpdesk is a different product from one that includes security, patching, monitoring and backup.
What matters more than the headline rate is what falls outside it. Ask specifically what counts as an extra, what on-site attendance costs, and whether project work is billed separately.
Should we hire an internal IT person instead?
Sometimes you should, and a provider who will not say so is not being straight with you. Past a certain size, or with specialised systems, an internal hire is the better answer.
Below that, one person carries a problem: they take leave, they get ill, they eventually leave, and they cannot be expert in networking, cloud, security and development at once. Many businesses end up with both — an internal person for the day to day, a provider for depth and cover.
What is the difference between an IT company and a managed service provider?
In practice the terms overlap. The distinction worth caring about is break-fix versus managed: break-fix means you call when something is broken and pay per incident, managed means someone is responsible for keeping it working.
Break-fix is cheaper per month and more expensive per year, because nothing gets prevented.
Can an IT company work alongside the provider we already have?
Yes, provided responsibilities are written down clearly enough that nothing falls between the two. Shared environments fail at the boundaries.
If you are considering changing provider, the first step is simply establishing what you have and who holds the keys to it.
Do we need a contract?
Not necessarily. Plenty of good work is project-based — an office setup, a Microsoft 365 migration, a security review.
Be wary of long minimum terms agreed before either side knows how the relationship works in practice.
Ask us the eight questions.
EIT Nepal is based in Kathmandu. Tell us what you are working with and we will tell you what makes sense from there — including when the answer is that you do not need us.