Software Requirements Hidden in Tenders and Donor Contracts

The short answer

The requirements that sink a donor-funded or government software project are rarely in the section headed "requirements". They are in the annexes, the general conditions and the grant agreement the client signed with somebody else two years earlier.

Read those before you price the work. Clauses on data residency, source code ownership, audit rights and accessibility change the architecture, and finding them after you have built is how a profitable project becomes a loss.

Where to look

Tender documents are not written by one person. The technical specification is written by someone who understands the work; the general conditions are boilerplate from procurement; the annexes are whatever the funder requires. They do not always agree with each other.

Read all three, and when they conflict, ask in writing during the clarification window. A contradiction you raised is the client's problem. The same contradiction discovered after signing is yours.

The clauses that change the build

• Data residency. "Data shall be stored within Nepal" removes most cloud options and changes your hosting, your backups and your cost. See hosting in Nepal or abroad.
• Source code and licensing. Many donor contracts require the deliverable to be handed over, and some require it to be released under an open licence. That affects what third-party components you can use.
• Audit and retention. A right to audit means records have to survive and be exportable, which usually means append-only logs rather than editable rows.
• Accessibility. International funders increasingly reference WCAG. Retrofitting is far more expensive than building to it. See accessibility basics.
• Personal data. If beneficiary data is involved, the funder's own obligations flow down to you, sometimes including rules written in another jurisdiction.

The practical traps

Offline operation is assumed, not stated

Field data collection in districts with no reliable connection is a standard expectation in development work and is frequently absent from the written spec. Ask directly. Building it in from the start is ordinary; adding it later means rewriting how the application handles data entirely. Our note on offline-first design covers why.

Indicators change between funding rounds

A system whose database schema hard-codes this year's indicator set will need rebuilding when the logframe changes, which it will. Model indicators as data rather than as columns.

Reporting formats are non-negotiable

The funder wants a specific template. Get an actual example file during the clarification window, not a description of one. The gap between a described format and a real one is where the last two weeks of a project disappear.

Acceptance may involve someone who is not the client

Sign-off sometimes requires a funder representative who was not in any of the meetings. Find out early who signs, because their expectations are the ones that matter at the end.

Pricing honestly

If the annexes impose residency, audit logging, offline capability and accessibility, that is a substantially different system from the one described in the technical section, and it should be priced as one. Bidding the cheap reading and absorbing the difference later serves nobody.

Where the documents are genuinely ambiguous, say so in the bid and state your assumption. Our note on contracts covers how to make that stick.

Frequently asked questions

Where are the hidden requirements usually found?

In the annexes and general conditions rather than the technical specification, and sometimes in the funder's grant agreement with the client. Ask for all of it.

What if the tender documents contradict each other?

Ask in writing during the clarification period and keep the answer. An unresolved contradiction defaults to whoever has more leverage later.

Does donor funding require open source?

Some do, some require handover without an open licence, many say nothing. It changes which components you may use, so check before choosing a stack.

Why does offline matter so much in these projects?

Because the data is collected where the connection is not. It is an architectural decision, not a feature, and it cannot be added cheaply afterwards.

Should I bid if the requirements are unclear?

Yes, with your assumptions written into the bid. A bid that states what it has assumed is more professional than one that quietly guesses low.