Government Digitization RFP Guide (Nepal)

Most government digitization projects in Nepal end up locked to whichever vendor won the original tender. Not because the procurement officers wanted that — almost universally they didn’t — but because the RFP didn’t specify the terms that would have kept options open. The vendor wrote terms that suited the vendor. The terms got copy-pasted. Five years later the agency is paying licensing fees for software it can’t extend, export, or replace.

This is fixable at the RFP stage. Here’s the language and the clauses we recommend any Nepal government agency include before going to tender.

The five questions every Nepal government RFP should answer upfront

Before writing a single technical requirement, the RFP should answer:

Where does the data live? In-country, on agency infrastructure, on cloud, or on vendor-controlled servers?
Who owns the data? The agency, full stop — not the vendor, not “joint.”
Can the agency export the data? When, in what format, and at what cost?
Can the agency replace the vendor? Without rebuilding from scratch?
Can the agency extend the system in-house? Without breaching contract?

Most legacy RFPs leave these implicit. The vendor fills in the gap with terms favorable to lock-in. Spell out the answers in the RFP itself.

Data residency: the clause to write

Nepal’s public-sector data should be stored in Nepal, or in jurisdictions explicitly approved by the agency. Cloud is fine — but the cloud region matters. The clause we recommend:

Vendor shall host all production data and backups in [agency-approved region(s)]. Migration of data outside approved regions, including for backup, replication, or disaster recovery, requires written approval. Vendor shall provide a quarterly attestation of data residency.

This is one paragraph. It saves you a lot.

Open standards over proprietary formats

Every data structure, every API, and every report should be in a documented, open standard. The clause:

All data structures shall be documented with field-level schemas. All APIs shall conform to OpenAPI 3.x. All data exports shall be available in at least one open format (CSV, JSON, Parquet, or SQL dump). Proprietary binary formats are permissible only for internal storage and shall be re-exportable to open formats on request.

If the vendor pushes back on this, you’ve learned something useful about how they intend to charge you in three years.

Source-code escrow and exit clauses

Any custom-built system should have a source-code escrow clause: if the vendor goes bankrupt, exits the market, or breaches contract, the agency gets the source code. The clause:

Vendor shall deposit a complete, buildable copy of the source code, build scripts, and deployment documentation with an agreed escrow agent at the end of each major release. Source code shall be released to the agency upon: (a) vendor bankruptcy or dissolution; (b) material breach of contract not cured within 30 days; (c) vendor cessation of maintenance for the system.

For procurement under EGTC or via public tender, this clause does not need to scare vendors who actually intend to deliver. It scares the ones who don’t.

Total cost of ownership, not just licensing

RFPs that score on initial price reward vendors who quote low and charge for everything later. The RFP should require a 5-year TCO breakdown:

Year 1 build / implementation
Annual licensing (with caps on year-over-year increases)
Annual maintenance and support
Per-user / per-record / per-transaction fees
Customization and integration fees
Data extraction fees (which should be zero)
Training and onboarding

Score on 5-year TCO. Otherwise the cheapest year-1 quote will be the most expensive year-5 reality.

Integration surface, not isolated silos

Most government agencies operate in a landscape — National ID, voter rolls, tax records, land records, citizenship records. A digitization project that ignores the landscape produces another silo. The RFP should require:

A documented integration plan with at least 3 existing government systems.
Use of REST APIs or, where compelled, file-based bridges with documented schemas.
Compliance with any inter-ministerial data standards the agency has adopted.

This isn’t optional. The whole point of government digitization is reducing the citizen’s reconciliation burden.

AI and automation: a clause for the next five years

If the system stores structured operational data, the next decade will see pressure to apply AI on top of it — for case prioritization, fraud detection, citizen-service triage, document classification. The RFP doesn’t need to specify AI features today, but it should not lock them out tomorrow. The clause:

Vendor shall not restrict the agency’s right to deploy analytics, machine learning, or AI implementation systems against data stored in or exported from the system, whether built in-house or by third parties.

Without this, the vendor can plausibly argue that any AI feature built on top “competes with their roadmap” and must be sourced from them. Don’t give them that argument.

Accessibility, language, and the digital divide

Nepal’s government services have to work in Nepali and on basic devices. The RFP should specify:

Full Devanagari script support, including search and reporting.
WCAG 2.1 AA accessibility for any citizen-facing interface.
Mobile-first design for citizen portals, with fallbacks for SMS or USSD where applicable.
A documented offline / degraded-connectivity mode for rural deployments.

If the vendor’s demo only works on a 1080p screen with stable broadband, they’re not building for Nepal.

The non-technical clauses that matter most

Three clauses we never see in poorly written RFPs but should be standard:

Right to audit. The agency can audit the vendor’s security, data handling, and code at any time, on reasonable notice.

Right to second-source. The agency may bring in a third party to maintain, extend, or audit the system at any time, and the vendor will cooperate (not stonewall).

Right to portability. The agency may move the system to different infrastructure (cloud, on-prem, hybrid) without vendor approval, provided the move complies with security and residency clauses.

These three together convert a vendor relationship into a service contract, instead of a hostage situation.

The procurement reality

Public tendering in Nepal has constraints — minimum vendor experience, financial thresholds, technical evaluation criteria from the Public Procurement Act. Most of the clauses above fit cleanly into the technical specification section without conflicting with procurement rules. The agency just has to write them in.

The vendors who don’t like these clauses will self-deselect. That’s the point.

If you’re scoping a digitization project for a Nepali government agency and want a second pair of eyes on the RFP before it goes to tender, we can help. Talk to us about Government Digitization in Nepal or share your draft RFP and we’ll flag what would lock you in.