A Government Should Govern Digital Nepal, Not Become Nepal’s Software Vendor
A Software Company Founder’s Perspective on Nepal’s Proposed Government Software Development Center
The reported plan to establish a dedicated Software Development and Operation Center under the Prime Minister’s Office deserves much more scrutiny than it is currently receiving.
According to reports, the government is preparing to create an in-house software center that would develop and operate software for government agencies, replacing at least part of the current practice of purchasing software and services from private companies. The reported rationale is straightforward: government agencies are said to spend more than Rs. 20 billion annually on software, while officials estimate that developing systems internally could reduce the cost to approximately Rs. 2 billion. The proposed center is expected to operate under the E-Governance Board, which sits under the Prime Minister’s Office. (myRepublica)
I strongly disagree with this direction.
Not because the government should not use technology. Quite the opposite.
Nepal urgently needs better digital government.
But the government becoming a large-scale software developer and operator is the wrong institutional response to Nepal’s digital challenges.
The government should build the digital ecosystem, standards, architecture, governance and market conditions that allow capable Nepali companies to build world-class solutions.
It should not attempt to become Nepal’s largest software company.
Nepal Does Not Have a Software Problem. Nepal Has a Digital-Governance Problem.
The distinction is important.
Nepal already has software developers.
We have software companies, startups, freelancers, product companies, outsourcing companies, system integrators, cybersecurity professionals, cloud engineers, data professionals and thousands of young developers working for international clients.
Nepal’s IT services sector has grown to a scale that policymakers can no longer treat as a small domestic industry.
Industry estimates indicate that Nepal’s IT service exports reached approximately US$1 billion in 2025, equivalent to roughly Rs. 145 billion annually. The estimate is based on industry assessments because Nepal still does not have a comprehensive official mechanism for measuring the sector. (Fiscal Nepal)
Official balance-of-payments statistics tell a much smaller story: telecommunications, computer and information services generated approximately Rs. 22.33 billion in exports in FY 2024/25. Industry representatives argue that this significantly understates the actual IT export economy because income earned by freelancers and software companies is often recorded through other channels, including remittances and international payment platforms. (Kathmandu Post)
Whatever number we use, the underlying direction is obvious:
Nepal already has a growing software and digital-services industry.
The strategic question should therefore be:
How do we turn this industry into a US$5 billion, US$10 billion or larger export engine?
Not:
How do we make the government itself one of the country’s biggest software development companies?
The Rs. 20 Billion Argument Needs More Scrutiny
The most powerful argument being presented in favour of the proposed center is cost reduction.
The reported government position is that public agencies spend more than Rs. 20 billion per year purchasing software from private companies, and that the same work could potentially be performed internally for around Rs. 2 billion. (myRepublica)
At first glance, that sounds like an extraordinary saving.
But software economics cannot be evaluated simply by comparing:
vendor invoice vs. government payroll.
That is not the total cost of software.
A serious software business case must include:
product discovery
requirements engineering
UX research
architecture
software development
testing and quality assurance
cybersecurity
cloud and infrastructure
licenses and third-party services
DevOps and deployment
monitoring
technical support
upgrades
maintenance
disaster recovery
documentation
knowledge transfer
employee turnover
project management
procurement and administration
system integration
long-term modernization
And most importantly:
the opportunity cost of building and operating a permanent government software organization.
A government department may look cheaper because many of its costs are hidden inside the public payroll, infrastructure, pension obligations, procurement structures and administrative budgets.
That does not automatically make the software cheaper.
It may simply make the cost less visible.
Government Software Is Not “Build Once and Forget”
This is another fundamental misunderstanding.
Software is not a road.
You do not construct it once and then consider the project finished.
Government software is a continuously changing operating environment.
Tax regulations change.
Citizens’ needs change.
Cyber threats change.
APIs change.
Cloud infrastructure changes.
Operating systems change.
Browsers change.
AI changes.
Identity standards change.
Payment systems change.
Data-protection requirements change.
Government structures change.
Ministries change.
Federal, provincial and local responsibilities change.
That means a government system developed today will require continuous engineering tomorrow, next year and five years from now.
A government software center therefore does not merely mean hiring developers.
It means creating and maintaining a permanent software organization.
That requires leadership, engineering management, product management, security teams, DevOps teams, QA teams, data engineers, architects, designers, support teams and technical governance.
And once the organization becomes sufficiently large, another question emerges:
Who will ensure that the government team remains competitive with the rapidly changing private technology market?
The Talent Problem Will Be Even Bigger Than the Budget Problem
Nepal’s strongest advantage in software is its people.
But the best developers increasingly have opportunities beyond the domestic government market.
They can work for Nepali outsourcing companies.
They can join startups.
They can build products.
They can work remotely for international companies.
They can freelance globally.
They can migrate.
They can build companies of their own.
Nepal’s IT sector is already generating substantial foreign income, and industry representatives estimate that the sector has been growing rapidly. (Fiscal Nepal)
Now imagine the government deciding to create a major centralized software organization under the Prime Minister’s Office.
It will have to compete for the exact same engineers, architects, cybersecurity specialists and technical leaders that private companies need to build export businesses.
That creates a strange policy contradiction.
On one hand, Nepal says it wants to grow IT exports and create technology-based employment.
On the other hand, the state is considering becoming a major employer competing directly for the same scarce technical talent.
We should be asking how to create 1,000 new software companies and export teams—not how to create one giant government software company.
This Is Especially Problematic Under the Prime Minister’s Office
The institutional location makes the proposal even more concerning.
Software development is already a highly specialized discipline.
Putting a software-development organization under the Prime Minister’s Office risks turning technology implementation into a centralized administrative function rather than treating it as a professional engineering and product discipline.
The Prime Minister’s Office should be concerned with national priorities, coordination, accountability and strategic execution.
It should not become the operational headquarters of software engineering.
Imagine the logical separation:
Prime Minister’s Office
→ national strategic leadership
Digital governance institution
→ standards, architecture, policy, interoperability, data governance and oversight
Private sector / technology companies
→ products, platforms, implementation, integration, innovation and service delivery
Academic institutions
→ talent development, research and innovation
That is a much healthier ecosystem.
The Government’s Own Digital Strategy Points in a Different Direction
Interestingly, Nepal’s evolving digital-policy architecture increasingly recognises the importance of an ecosystem rather than simply technology procurement.
The draft Digital Nepal Framework 2.0 emphasizes strategic digital foundations, industry-relevant IT education, collaboration between academia and the IT sector, practical learning and internships, and a broader digital ecosystem capable of supporting Nepal’s transformation. (Giwmscdntwo)
The government’s 2026–27 policies and programmes have also explicitly prioritised software, digital services, cloud services, cybersecurity, green computing and artificial intelligence exports, alongside digital infrastructure, research and innovation. The stated ambition is to position Nepal as a technology hub and shift the economy toward higher-value digital exports. (Kathmandu Post)
These objectives point toward a fundamental policy principle:
The state should enable the industry that can create technology at scale.
It should not unnecessarily replace that industry.
What Happens to Nepal’s Software Companies?
This is the question that needs to be asked more seriously.
Suppose a government ministry requires:
a citizen-service portal
an enterprise management system
a mobile application
a GIS platform
an e-payment system
an HR system
a document-management system
an AI-based government service
a data integration platform
There are Nepali companies capable of designing, developing, deploying and maintaining many of these systems.
When government becomes the developer, those businesses lose a significant portion of their domestic market.
That does not only affect company revenue.
It affects:
jobs → training → internships → technical leadership → R&D → company growth → exports.
A government IT project can therefore have an economic multiplier beyond the immediate contract.
When a Nepali company receives a large project, it may hire developers, train junior engineers, build internal capabilities, develop reusable technology, establish industry expertise and eventually use that experience to win clients abroad.
The economic value is not simply the value of the government contract.
It is the capability created around it.
Government Procurement Is Not Perfect. Fix Procurement—Do Not Eliminate the Market.
There is a legitimate problem behind the government’s frustration.
Public procurement can be slow, difficult and inefficient.
The World Bank has reported that Nepal’s procurement process has significant bottlenecks. For World Bank-financed contracts awarded between 2018 and 2024, Nepal averaged 231 business days across procurement-processing stages—the highest average in South Asia in that comparison. (World Bank)
That is a serious problem.
But the conclusion should not be:
“Private companies are the problem. Let’s build everything ourselves.”
The conclusion should be:
“Our digital procurement system is broken. Let’s fix it.”
The solution should include better:
Technical specifications
Government agencies should be able to define what a system must accomplish without artificially prescribing outdated technology.
Outcome-based procurement
Pay for measurable outcomes, uptime, security, performance and service quality—not merely lines of code or lowest upfront price.
Professional evaluation
IT procurement should be evaluated by people who understand software architecture, cybersecurity, scalability, product design and lifecycle costs.
Competitive procurement
Nepal’s own competition law emphasizes a market-oriented and competitive economy, including protection against unnecessary market intervention and anti-competitive practices. (Law Commission Repository)
Lifecycle costing
Government should compare the total cost of ownership, not merely the initial contract amount.
Vendor accountability
Poor-performing vendors should face meaningful consequences.
Open standards
Government systems should not be locked into a single vendor.
Interoperability
Different government systems should communicate through common APIs and standards.
These reforms attack the actual problem.
Government Should Own the Architecture, Not Necessarily the Code
This is where Nepal needs a much more mature conversation.
There are areas where government absolutely must maintain strong control.
For example:
Digital identity
Data governance
Cybersecurity standards
National interoperability standards
Government data exchange
Open API standards
Data classification
Privacy requirements
Digital signatures
Authentication standards
Cloud and infrastructure standards
Technology procurement standards
Reference architectures
AI governance
These are legitimate public responsibilities.
But owning the standards does not require owning every line of source code.
A government can define:
This is the national API standard.
This is the security framework.
This is the identity protocol.
This is the data model.
This is the interoperability requirement.
This is the minimum service level.
This is how citizens’ data must be protected.
Then let qualified companies compete to build the systems.
The Better Model: Government as Platform Owner and Regulator
Nepal should consider a model closer to:
Government → sets rules and architecture
Private sector → builds and operates competitive solutions
Academia → develops talent and research
Citizens → consume services
This does not mean government should blindly outsource everything.
There are exceptional situations where direct government technical capacity is necessary.
For example, government should maintain a strong internal team capable of:
setting architecture
reviewing vendors
conducting security audits
validating source code
managing APIs
owning data governance
supervising critical infrastructure
managing digital identity and national platforms
ensuring vendor independence
That is fundamentally different from creating a giant government software company.
A government needs technical capability. It does not necessarily need a government software factory.
That distinction is critical.
There Is Another Risk: Technology Obsolescence
Private technology companies survive through competition.
A software company that stops learning eventually loses clients.
A startup that builds a poor product loses users.
A technology company that cannot adopt new platforms loses market share.
This market pressure forces continuous innovation.
Government organizations do not operate under exactly the same competitive pressure.
That creates a structural risk.
A government software center established today could be technically competent for several years and then gradually become dependent on legacy systems, outdated frameworks and internal processes.
We have seen versions of this problem across the public sector worldwide.
The issue is not whether government engineers are talented.
Nepal has excellent engineers.
The issue is whether a large permanent public software organization has the incentives, speed and competitive pressure required for continuous software innovation.
That is a completely different question.
What If the Government Really Can Build Software for Rs. 2 Billion?
Then there is an interesting challenge for the private sector.
Let us take the government’s reported numbers at face value for the sake of argument.
If government agencies currently spend more than Rs. 20 billion and the same work can genuinely be delivered for Rs. 2 billion, then something is seriously wrong.
But that raises the question:
Why is the government paying ten times more than the true cost?
There are only a few possible explanations:
Software procurement is inefficient.
Requirements are poorly defined.
Projects are unnecessarily complex.
Vendors are overcharging.
Government procurement favours unsuitable vendors.
Projects repeatedly fail and must be rebuilt.
Maintenance and support are badly managed.
Internal administrative overhead is enormous.
The Rs. 20 billion figure includes categories far beyond pure software development.
The Rs. 2 billion estimate excludes significant lifecycle costs.
Any of these possibilities deserves investigation.
But none automatically justifies creating a government software monopoly.
If the private market is inefficient, improve the market.
Nepal Cannot Become a Technology Export Powerhouse by Shrinking Its Domestic Technology Industry
This may be the most important economic point.
Nepal has very few globally scalable export industries.
IT services are one of the rare sectors where Nepal can sell globally without building physical factories, importing massive raw materials or constructing ports and highways.
A laptop, internet connection, skills and a good team can create foreign currency income from Nepal.
That is a tremendous strategic advantage.
Industry estimates put Nepal’s annual IT service exports at around US$1 billion, while the country’s official statistics significantly undercount the sector. (Fiscal Nepal)
The government’s own 2026–27 policy programme says Nepal wants to promote software, digital services, cloud services, cybersecurity and AI exports and position the country as a technology hub. (Kathmandu Post)
Then our policy should be brutally simple:
Grow the industry.
Create more companies.
Create better companies.
Create export-ready companies.
Create product companies.
Create AI companies.
Create cybersecurity companies.
Create cloud companies.
Create 100,000 new technology jobs.
Create global clients.
Create intellectual property.
Create products from Nepal.
That should be the national mission.
Government Should Buy Better, Not Build Everything
There is a false choice in this debate:
Option A: Government develops software itself.
Option B: Government becomes dependent on private companies.
There is a much better Option C:
Build a world-class government digital procurement and governance system.
Government can maintain strong technical teams to:
define requirements
establish architecture
inspect systems
conduct security assessments
monitor vendors
enforce SLAs
own government data
maintain system documentation
ensure interoperability
prevent vendor lock-in
Then private companies compete to build and maintain the actual solutions.
This creates accountability on both sides.
The state remains technologically capable without trying to become a commercial software vendor.
What Nepal Actually Needs Instead
Instead of creating a centralized government software factory under the Prime Minister’s Office, I would recommend a different institutional model.
1. A National Digital Architecture Authority
Its responsibility would be to define:
national digital architecture
interoperability standards
API standards
cybersecurity baselines
identity standards
data standards
cloud standards
AI governance
open-source policy
technology procurement frameworks
Not build every application.
2. A Professional Government Digital Product Management Function
Government needs people who understand products, not just procurement.
Every major digital service should have:
a product owner
user research
measurable KPIs
service standards
architecture oversight
security governance
lifecycle planning
3. A Specialized Digital Procurement Framework
Software procurement should be fundamentally different from buying chairs, vehicles or construction materials.
Evaluation should consider:
technical capability + security + architecture + scalability + lifecycle cost + delivery record + support + innovation.
Lowest price should not automatically win.
4. Open Standards and Modular Architecture
Government should own the architecture and standards so that multiple companies can build components around the same ecosystem.
That reduces vendor lock-in and increases competition.
5. A Strong Government Technical Audit Team
Government should be capable of independently auditing the software it purchases.
That solves one of the biggest weaknesses of outsourcing:
information asymmetry.
The government should not have to trust a vendor blindly.
6. Industry–Government–Academia Collaboration
The draft Digital Nepal Framework 2.0 itself recognises the importance of collaboration between academia and the IT sector, including internships and industry-aligned education. (Giwmscdntwo)
That is the direction Nepal should be scaling.
Not isolating government engineering teams from the ecosystem.
What About Sensitive Government Systems?
Critics may reasonably ask:
“What about national security, citizen data and highly sensitive systems?”
This is a legitimate concern.
But sensitive data does not necessarily require government employees to write every line of code.
Government can use:
strict security requirements
secure development standards
source-code escrow
independent security audits
penetration testing
zero-trust architecture
encryption
privileged-access controls
sovereign hosting requirements where appropriate
contractual ownership of intellectual property
independent code review
incident-response requirements
multi-vendor architecture
The important principle is:
Control the risk, not necessarily every activity.
The Government Should Not Fear Its Own Software Industry
There is also a philosophical issue here.
Nepali software companies should not be treated as an unavoidable cost to government.
They should be treated as a strategic national economic asset.
When a Nepali software company develops a payroll system, GIS platform, financial application or citizen-service platform for a government agency, it develops knowledge.
That knowledge can later become:
a product → a platform → an export → a global company.
This is how ecosystems grow.
Silicon Valley did not become Silicon Valley because the US government decided to become the biggest software development company.
India did not build its IT services industry by making government the dominant software vendor.
Technology ecosystems grow when governments create:
talent + infrastructure + predictable regulation + capital + market access + competition.
Nepal needs to create those conditions.
The Real Question Is Bigger Than This One Software Center
This debate should not be reduced to whether one government project is good or bad.
The larger question is:
What role should the Nepali state play in the digital economy?
There are two possible models.
Model One: Government as Developer
Government hires developers.
Government builds applications.
Government operates software.
Government becomes a technology employer.
Government competes with technology companies.
Government carries the maintenance burden.
Government carries the innovation burden.
Government owns the failure when systems become outdated.
Model Two: Government as Ecosystem Builder
Government establishes standards.
Government protects data.
Government ensures cybersecurity.
Government improves procurement.
Government creates interoperability.
Government develops digital infrastructure.
Government invests in research.
Government supports education.
Government enables exports.
Private companies build products.
Private companies compete.
Private companies innovate.
Private companies create jobs.
Private companies sell globally.
For Nepal, I strongly believe Model Two is strategically superior.
A Final Challenge to Policymakers
Before approving a government software development center, policymakers should answer five simple questions publicly:
1. Is the reported Rs. 20 billion annual software expenditure independently audited and clearly defined?
What exactly is included in that number?
Software licenses?
Hardware?
Cloud?
Maintenance?
Consultancy?
Telecom?
Data centers?
Support?
System integration?
Without a precise definition, the comparison is meaningless.
2. Does the Rs. 2 billion estimate include the full lifecycle cost?
Recruitment?
Salary?
Infrastructure?
Security?
Maintenance?
Upgrades?
Pensions?
Management?
Training?
Cloud?
Disaster recovery?
Technology replacement?
If not, the saving may be illusory.
3. What will happen to Nepal’s private software industry?
How many companies and jobs could be displaced?
How much domestic demand will disappear?
How will this affect innovation and exports?
4. Why should the Prime Minister’s Office become involved in software production?
What strategic government function actually requires this institutional structure?
5. Could the same money produce a larger national economic return if spent on digital infrastructure, education, standards, export incentives, cybersecurity and R&D?
These questions deserve serious answers.
My Position as a Software Company Founder
I am not arguing that government should stay away from technology.
That would be absurd.
Government must become more technically capable, not less.
I am arguing for a clear separation of roles.
Government should govern technology.
Government should regulate technology.
Government should set standards.
Government should protect citizens’ data.
Government should build national digital infrastructure.
Government should fix procurement.
Government should ensure interoperability.
Government should create the environment for technology companies to thrive.
But government should be extremely cautious about becoming a commercial software developer itself.
Nepal does not need another state-owned software company.
Nepal needs 1,000 stronger private technology companies.
It needs more export companies.
It needs more products.
It needs more startups.
It needs more engineers earning foreign currency from Nepal.
It needs stronger universities.
It needs better digital infrastructure.
It needs predictable policy.
It needs intelligent procurement.
It needs government agencies that can manage technology professionally.
And above all, it needs a government that understands the difference between having technical capability and becoming the technology industry.
The government should not ask:
“How can we build the software ourselves?”
The better question is:
“How can we build a system in which Nepal’s best software companies can build better software for Nepal—and eventually for the world?”
That is the policy question that matters.
Government should build the rules of the game, not become one of the players in the software business.
And if Nepal genuinely wants to build a digital economy, this distinction is not ideological—it is economic strategy. Company Founder’s Perspective on Nepal’s Proposed Government Software Development Center
The reported plan to establish a dedicated Software Development and Operation Center under the Prime Minister’s Office deserves much more scrutiny than it is currently receiving.
According to reports, the government is preparing to create an in-house software center that would develop and operate software for government agencies, replacing at least part of the current practice of purchasing software and services from private companies. The reported rationale is straightforward: government agencies are said to spend more than Rs. 20 billion annually on software, while officials estimate that developing systems internally could reduce the cost to approximately Rs. 2 billion. The proposed center is expected to operate under the E-Governance Board, which sits under the Prime Minister’s Office. (myRepublica)
I strongly disagree with this direction.
Not because the government should not use technology. Quite the opposite.
Nepal urgently needs better digital government.
But the government becoming a large-scale software developer and operator is the wrong institutional response to Nepal’s digital challenges.
The government should build the digital ecosystem, standards, architecture, governance and market conditions that allow capable Nepali companies to build world-class solutions.
It should not attempt to become Nepal’s largest software company.
Nepal Does Not Have a Software Problem. Nepal Has a Digital-Governance Problem.
The distinction is important.
Nepal already has software developers.
We have software companies, startups, freelancers, product companies, outsourcing companies, system integrators, cybersecurity professionals, cloud engineers, data professionals and thousands of young developers working for international clients.
Nepal’s IT services sector has grown to a scale that policymakers can no longer treat as a small domestic industry.
Industry estimates indicate that Nepal’s IT service exports reached approximately US$1 billion in 2025, equivalent to roughly Rs. 145 billion annually. The estimate is based on industry assessments because Nepal still does not have a comprehensive official mechanism for measuring the sector. (Fiscal Nepal)
Official balance-of-payments statistics tell a much smaller story: telecommunications, computer and information services generated approximately Rs. 22.33 billion in exports in FY 2024/25. Industry representatives argue that this significantly understates the actual IT export economy because income earned by freelancers and software companies is often recorded through other channels, including remittances and international payment platforms. (Kathmandu Post)
Whatever number we use, the underlying direction is obvious:
Nepal already has a growing software and digital-services industry.
The strategic question should therefore be:
How do we turn this industry into a US$5 billion, US$10 billion or larger export engine?
Not:
How do we make the government itself one of the country’s biggest software development companies?
The Rs. 20 Billion Argument Needs More Scrutiny
The most powerful argument being presented in favour of the proposed center is cost reduction.
The reported government position is that public agencies spend more than Rs. 20 billion per year purchasing software from private companies, and that the same work could potentially be performed internally for around Rs. 2 billion. (myRepublica)
At first glance, that sounds like an extraordinary saving.
But software economics cannot be evaluated simply by comparing:
vendor invoice vs. government payroll.
That is not the total cost of software.
A serious software business case must include:
product discovery
requirements engineering
UX research
architecture
software development
testing and quality assurance
cybersecurity
cloud and infrastructure
licenses and third-party services
DevOps and deployment
monitoring
technical support
upgrades
maintenance
disaster recovery
documentation
knowledge transfer
employee turnover
project management
procurement and administration
system integration
long-term modernization
And most importantly:
the opportunity cost of building and operating a permanent government software organization.
A government department may look cheaper because many of its costs are hidden inside the public payroll, infrastructure, pension obligations, procurement structures and administrative budgets.
That does not automatically make the software cheaper.
It may simply make the cost less visible.
Government Software Is Not “Build Once and Forget”
This is another fundamental misunderstanding.
Software is not a road.
You do not construct it once and then consider the project finished.
Government software is a continuously changing operating environment.
Tax regulations change.
Citizens’ needs change.
Cyber threats change.
APIs change.
Cloud infrastructure changes.
Operating systems change.
Browsers change.
AI changes.
Identity standards change.
Payment systems change.
Data-protection requirements change.
Government structures change.
Ministries change.
Federal, provincial and local responsibilities change.
That means a government system developed today will require continuous engineering tomorrow, next year and five years from now.
A government software center therefore does not merely mean hiring developers.
It means creating and maintaining a permanent software organization.
That requires leadership, engineering management, product management, security teams, DevOps teams, QA teams, data engineers, architects, designers, support teams and technical governance.
And once the organization becomes sufficiently large, another question emerges:
Who will ensure that the government team remains competitive with the rapidly changing private technology market?
The Talent Problem Will Be Even Bigger Than the Budget Problem
Nepal’s strongest advantage in software is its people.
But the best developers increasingly have opportunities beyond the domestic government market.
They can work for Nepali outsourcing companies.
They can join startups.
They can build products.
They can work remotely for international companies.
They can freelance globally.
They can migrate.
They can build companies of their own.
Nepal’s IT sector is already generating substantial foreign income, and industry representatives estimate that the sector has been growing rapidly. (Fiscal Nepal)
Now imagine the government deciding to create a major centralized software organization under the Prime Minister’s Office.
It will have to compete for the exact same engineers, architects, cybersecurity specialists and technical leaders that private companies need to build export businesses.
That creates a strange policy contradiction.
On one hand, Nepal says it wants to grow IT exports and create technology-based employment.
On the other hand, the state is considering becoming a major employer competing directly for the same scarce technical talent.
We should be asking how to create 1,000 new software companies and export teams—not how to create one giant government software company.
This Is Especially Problematic Under the Prime Minister’s Office
The institutional location makes the proposal even more concerning.
Software development is already a highly specialized discipline.
Putting a software-development organization under the Prime Minister’s Office risks turning technology implementation into a centralized administrative function rather than treating it as a professional engineering and product discipline.
The Prime Minister’s Office should be concerned with national priorities, coordination, accountability and strategic execution.
It should not become the operational headquarters of software engineering.
Imagine the logical separation:
Prime Minister’s Office
→ national strategic leadership
Digital governance institution
→ standards, architecture, policy, interoperability, data governance and oversight
Private sector / technology companies
→ products, platforms, implementation, integration, innovation and service delivery
Academic institutions
→ talent development, research and innovation
That is a much healthier ecosystem.
The Government’s Own Digital Strategy Points in a Different Direction
Interestingly, Nepal’s evolving digital-policy architecture increasingly recognises the importance of an ecosystem rather than simply technology procurement.
The draft Digital Nepal Framework 2.0 emphasizes strategic digital foundations, industry-relevant IT education, collaboration between academia and the IT sector, practical learning and internships, and a broader digital ecosystem capable of supporting Nepal’s transformation. (Giwmscdntwo)
The government’s 2026–27 policies and programmes have also explicitly prioritised software, digital services, cloud services, cybersecurity, green computing and artificial intelligence exports, alongside digital infrastructure, research and innovation. The stated ambition is to position Nepal as a technology hub and shift the economy toward higher-value digital exports. (Kathmandu Post)
These objectives point toward a fundamental policy principle:
The state should enable the industry that can create technology at scale.
It should not unnecessarily replace that industry.
What Happens to Nepal’s Software Companies?
This is the question that needs to be asked more seriously.
Suppose a government ministry requires:
a citizen-service portal
an enterprise management system
a mobile application
a GIS platform
an e-payment system
an HR system
a document-management system
an AI-based government service
a data integration platform
There are Nepali companies capable of designing, developing, deploying and maintaining many of these systems.
When government becomes the developer, those businesses lose a significant portion of their domestic market.
That does not only affect company revenue.
It affects:
jobs → training → internships → technical leadership → R&D → company growth → exports.
A government IT project can therefore have an economic multiplier beyond the immediate contract.
When a Nepali company receives a large project, it may hire developers, train junior engineers, build internal capabilities, develop reusable technology, establish industry expertise and eventually use that experience to win clients abroad.
The economic value is not simply the value of the government contract.
It is the capability created around it.
Government Procurement Is Not Perfect. Fix Procurement—Do Not Eliminate the Market.
There is a legitimate problem behind the government’s frustration.
Public procurement can be slow, difficult and inefficient.
The World Bank has reported that Nepal’s procurement process has significant bottlenecks. For World Bank-financed contracts awarded between 2018 and 2024, Nepal averaged 231 business days across procurement-processing stages—the highest average in South Asia in that comparison. (World Bank)
That is a serious problem.
But the conclusion should not be:
“Private companies are the problem. Let’s build everything ourselves.”
The conclusion should be:
“Our digital procurement system is broken. Let’s fix it.”
The solution should include better:
Technical specifications
Government agencies should be able to define what a system must accomplish without artificially prescribing outdated technology.
Outcome-based procurement
Pay for measurable outcomes, uptime, security, performance and service quality—not merely lines of code or lowest upfront price.
Professional evaluation
IT procurement should be evaluated by people who understand software architecture, cybersecurity, scalability, product design and lifecycle costs.
Competitive procurement
Nepal’s own competition law emphasizes a market-oriented and competitive economy, including protection against unnecessary market intervention and anti-competitive practices. (Law Commission Repository)
Lifecycle costing
Government should compare the total cost of ownership, not merely the initial contract amount.
Vendor accountability
Poor-performing vendors should face meaningful consequences.
Open standards
Government systems should not be locked into a single vendor.
Interoperability
Different government systems should communicate through common APIs and standards.
These reforms attack the actual problem.
Government Should Own the Architecture, Not Necessarily the Code
This is where Nepal needs a much more mature conversation.
There are areas where government absolutely must maintain strong control.
For example:
Digital identity
Data governance
Cybersecurity standards
National interoperability standards
Government data exchange
Open API standards
Data classification
Privacy requirements
Digital signatures
Authentication standards
Cloud and infrastructure standards
Technology procurement standards
Reference architectures
AI governance
These are legitimate public responsibilities.
But owning the standards does not require owning every line of source code.
A government can define:
This is the national API standard.
This is the security framework.
This is the identity protocol.
This is the data model.
This is the interoperability requirement.
This is the minimum service level.
This is how citizens’ data must be protected.
Then let qualified companies compete to build the systems.
The Better Model: Government as Platform Owner and Regulator
Nepal should consider a model closer to:
Government → sets rules and architecture
Private sector → builds and operates competitive solutions
Academia → develops talent and research
Citizens → consume services
This does not mean government should blindly outsource everything.
There are exceptional situations where direct government technical capacity is necessary.
For example, government should maintain a strong internal team capable of:
setting architecture
reviewing vendors
conducting security audits
validating source code
managing APIs
owning data governance
supervising critical infrastructure
managing digital identity and national platforms
ensuring vendor independence
That is fundamentally different from creating a giant government software company.
A government needs technical capability. It does not necessarily need a government software factory.
That distinction is critical.
There Is Another Risk: Technology Obsolescence
Private technology companies survive through competition.
A software company that stops learning eventually loses clients.
A startup that builds a poor product loses users.
A technology company that cannot adopt new platforms loses market share.
This market pressure forces continuous innovation.
Government organizations do not operate under exactly the same competitive pressure.
That creates a structural risk.
A government software center established today could be technically competent for several years and then gradually become dependent on legacy systems, outdated frameworks and internal processes.
We have seen versions of this problem across the public sector worldwide.
The issue is not whether government engineers are talented.
Nepal has excellent engineers.
The issue is whether a large permanent public software organization has the incentives, speed and competitive pressure required for continuous software innovation.
That is a completely different question.
What If the Government Really Can Build Software for Rs. 2 Billion?
Then there is an interesting challenge for the private sector.
Let us take the government’s reported numbers at face value for the sake of argument.
If government agencies currently spend more than Rs. 20 billion and the same work can genuinely be delivered for Rs. 2 billion, then something is seriously wrong.
But that raises the question:
Why is the government paying ten times more than the true cost?
There are only a few possible explanations:
Software procurement is inefficient.
Requirements are poorly defined.
Projects are unnecessarily complex.
Vendors are overcharging.
Government procurement favours unsuitable vendors.
Projects repeatedly fail and must be rebuilt.
Maintenance and support are badly managed.
Internal administrative overhead is enormous.
The Rs. 20 billion figure includes categories far beyond pure software development.
The Rs. 2 billion estimate excludes significant lifecycle costs.
Any of these possibilities deserves investigation.
But none automatically justifies creating a government software monopoly.
If the private market is inefficient, improve the market.
Nepal Cannot Become a Technology Export Powerhouse by Shrinking Its Domestic Technology Industry
This may be the most important economic point.
Nepal has very few globally scalable export industries.
IT services are one of the rare sectors where Nepal can sell globally without building physical factories, importing massive raw materials or constructing ports and highways.
A laptop, internet connection, skills and a good team can create foreign currency income from Nepal.
That is a tremendous strategic advantage.
Industry estimates put Nepal’s annual IT service exports at around US$1 billion, while the country’s official statistics significantly undercount the sector. (Fiscal Nepal)
The government’s own 2026–27 policy programme says Nepal wants to promote software, digital services, cloud services, cybersecurity and AI exports and position the country as a technology hub. (Kathmandu Post)
Then our policy should be brutally simple:
Grow the industry.
Create more companies.
Create better companies.
Create export-ready companies.
Create product companies.
Create AI companies.
Create cybersecurity companies.
Create cloud companies.
Create 100,000 new technology jobs.
Create global clients.
Create intellectual property.
Create products from Nepal.
That should be the national mission.
Government Should Buy Better, Not Build Everything
There is a false choice in this debate:
Option A: Government develops software itself.
Option B: Government becomes dependent on private companies.
There is a much better Option C:
Build a world-class government digital procurement and governance system.
Government can maintain strong technical teams to:
define requirements
establish architecture
inspect systems
conduct security assessments
monitor vendors
enforce SLAs
own government data
maintain system documentation
ensure interoperability
prevent vendor lock-in
Then private companies compete to build and maintain the actual solutions.
This creates accountability on both sides.
The state remains technologically capable without trying to become a commercial software vendor.
What Nepal Actually Needs Instead
Instead of creating a centralized government software factory under the Prime Minister’s Office, I would recommend a different institutional model.
1. A National Digital Architecture Authority
Its responsibility would be to define:
national digital architecture
interoperability standards
API standards
cybersecurity baselines
identity standards
data standards
cloud standards
AI governance
open-source policy
technology procurement frameworks
Not build every application.
2. A Professional Government Digital Product Management Function
Government needs people who understand products, not just procurement.
Every major digital service should have:
a product owner
user research
measurable KPIs
service standards
architecture oversight
security governance
lifecycle planning
3. A Specialized Digital Procurement Framework
Software procurement should be fundamentally different from buying chairs, vehicles or construction materials.
Evaluation should consider:
technical capability + security + architecture + scalability + lifecycle cost + delivery record + support + innovation.
Lowest price should not automatically win.
4. Open Standards and Modular Architecture
Government should own the architecture and standards so that multiple companies can build components around the same ecosystem.
That reduces vendor lock-in and increases competition.
5. A Strong Government Technical Audit Team
Government should be capable of independently auditing the software it purchases.
That solves one of the biggest weaknesses of outsourcing:
information asymmetry.
The government should not have to trust a vendor blindly.
6. Industry–Government–Academia Collaboration
The draft Digital Nepal Framework 2.0 itself recognises the importance of collaboration between academia and the IT sector, including internships and industry-aligned education. (Giwmscdntwo)
That is the direction Nepal should be scaling.
Not isolating government engineering teams from the ecosystem.
What About Sensitive Government Systems?
Critics may reasonably ask:
“What about national security, citizen data and highly sensitive systems?”
This is a legitimate concern.
But sensitive data does not necessarily require government employees to write every line of code.
Government can use:
strict security requirements
secure development standards
source-code escrow
independent security audits
penetration testing
zero-trust architecture
encryption
privileged-access controls
sovereign hosting requirements where appropriate
contractual ownership of intellectual property
independent code review
incident-response requirements
multi-vendor architecture
The important principle is:
Control the risk, not necessarily every activity.
The Government Should Not Fear Its Own Software Industry
There is also a philosophical issue here.
Nepali software companies should not be treated as an unavoidable cost to government.
They should be treated as a strategic national economic asset.
When a Nepali software company develops a payroll system, GIS platform, financial application or citizen-service platform for a government agency, it develops knowledge.
That knowledge can later become:
a product → a platform → an export → a global company.
This is how ecosystems grow.
Silicon Valley did not become Silicon Valley because the US government decided to become the biggest software development company.
India did not build its IT services industry by making government the dominant software vendor.
Technology ecosystems grow when governments create:
talent + infrastructure + predictable regulation + capital + market access + competition.
Nepal needs to create those conditions.
The Real Question Is Bigger Than This One Software Center
This debate should not be reduced to whether one government project is good or bad.
The larger question is:
What role should the Nepali state play in the digital economy?
There are two possible models.
Model One: Government as Developer
Government hires developers.
Government builds applications.
Government operates software.
Government becomes a technology employer.
Government competes with technology companies.
Government carries the maintenance burden.
Government carries the innovation burden.
Government owns the failure when systems become outdated.
Model Two: Government as Ecosystem Builder
Government establishes standards.
Government protects data.
Government ensures cybersecurity.
Government improves procurement.
Government creates interoperability.
Government develops digital infrastructure.
Government invests in research.
Government supports education.
Government enables exports.
Private companies build products.
Private companies compete.
Private companies innovate.
Private companies create jobs.
Private companies sell globally.
For Nepal, I strongly believe Model Two is strategically superior.
A Final Challenge to Policymakers
Before approving a government software development center, policymakers should answer five simple questions publicly:
1. Is the reported Rs. 20 billion annual software expenditure independently audited and clearly defined?
What exactly is included in that number?
Software licenses?
Hardware?
Cloud?
Maintenance?
Consultancy?
Telecom?
Data centers?
Support?
System integration?
Without a precise definition, the comparison is meaningless.
2. Does the Rs. 2 billion estimate include the full lifecycle cost?
Recruitment?
Salary?
Infrastructure?
Security?
Maintenance?
Upgrades?
Pensions?
Management?
Training?
Cloud?
Disaster recovery?
Technology replacement?
If not, the saving may be illusory.
3. What will happen to Nepal’s private software industry?
How many companies and jobs could be displaced?
How much domestic demand will disappear?
How will this affect innovation and exports?
4. Why should the Prime Minister’s Office become involved in software production?
What strategic government function actually requires this institutional structure?
5. Could the same money produce a larger national economic return if spent on digital infrastructure, education, standards, export incentives, cybersecurity and R&D?
These questions deserve serious answers.
My Position as a Software Company Founder
I am not arguing that government should stay away from technology.
That would be absurd.
Government must become more technically capable, not less.
I am arguing for a clear separation of roles.
Government should govern technology.
Government should regulate technology.
Government should set standards.
Government should protect citizens’ data.
Government should build national digital infrastructure.
Government should fix procurement.
Government should ensure interoperability.
Government should create the environment for technology companies to thrive.
But government should be extremely cautious about becoming a commercial software developer itself.
Nepal does not need another state-owned software company.
Nepal needs 1,000 stronger private technology companies.
It needs more export companies.
It needs more products.
It needs more startups.
It needs more engineers earning foreign currency from Nepal.
It needs stronger universities.
It needs better digital infrastructure.
It needs predictable policy.
It needs intelligent procurement.
It needs government agencies that can manage technology professionally.
And above all, it needs a government that understands the difference between having technical capability and becoming the technology industry.
The government should not ask:
“How can we build the software ourselves?”
The better question is:
“How can we build a system in which Nepal’s best software companies can build better software for Nepal—and eventually for the world?”
That is the policy question that matters.
Government should build the rules of the game, not become one of the players in the software business.
And if Nepal genuinely wants to build a digital economy, this distinction is not ideological—it is economic strategy.