What a government department should ask before approving a software tender

A tender document usually runs to many pages on what the software must do and a paragraph or two on what happens after it is delivered. That is the wrong proportion. Feature lists are the easy part, and vendors are good at agreeing to them. The clauses that decide whether the system is still working in year three are almost always the thin ones.

These are the questions worth putting in the document itself, rather than discovering the answers afterwards.

Ownership

**Who owns the source code when the project ends?**

This has a correct answer and it is "the department". If the vendor retains ownership, then every future change — including changes forced on you by a rule that did not exist when the system was built — has exactly one possible supplier, at whatever price they name.

Write it explicitly. "Source code will be delivered to the department" is not the same clause as "the department will have a licence to use the software", and the difference is worth a great deal of money over ten years.

**What form is the handover in?**

Source code delivered as a zip file on a pen drive at the closing meeting satisfies the letter of a clause and nothing else. Ask for:

• The complete source, in a version control repository with its history
• The database schema and a working export of the data
• Deployment documentation good enough for a different vendor to follow
• Any credentials, certificates and third-party account details the system depends on

Specify that a successful handover means a third party can deploy the system from the delivered materials without contacting the original vendor. That single sentence is worth more than a page of feature specification.

Data

**Where does the data live, and can you get it out?**

Ask for the export format in the tender. A system whose data can only be read through its own interface is a system you cannot leave, regardless of what the ownership clause says.

**What happens to citizen data if the contract ends?**

This should be written down before it is relevant, not during a dispute. Retention, deletion and the timeline for both.

**Who can see what?**

Role-based access and an audit trail of who viewed and changed each record are not advanced features. For anything holding citizen data they are the baseline, and they have to be designed in — retrofitting an audit trail means rewriting the parts of the system that assumed there was not one.

Support

**What exactly is covered after go-live, and for how long?**

"One year of support" means very little on its own. Get the specifics:

• What counts as a bug, fixed free, versus a change request, billed
• Response times, separated by severity — a system that is completely down is a different situation from a report that formats badly
• Who is on the other end of the phone, and during what hours
• What the renewal costs, stated in the original contract rather than negotiated later from a position of no alternatives

**What happens when the platform underneath changes?**

The server's operating system, the language runtime and the framework all reach end of life on schedules nobody controls. A system that is never updated becomes a security liability on a predictable timeline. Establish who is responsible for those updates and whether it is included.

Delivery

**What will you see, and when?**

The failure pattern in public software projects is a long silence followed by a delivery that does not match what anyone expected. The defence is scheduled, working demonstrations — not slide decks and not screenshots, but a build that officers can open and use.

Specify the interval. Every two or three weeks is reasonable. The point is not to micromanage the vendor; it is that six months of silence gives everyone six months to build different assumptions.

**Who from the department is available, and how often?**

This is the question departments forget to ask themselves. A software project needs decisions from people who know the process, and those people already have full-time jobs. A vendor cannot compensate for the absence of that access, and a project without it drifts regardless of who built it.

Name the officers and the time commitment in the document.

Cost

**What is the total over five years?**

Compare bids on five-year cost, not delivery cost. A low delivery price with an unstated annual maintenance figure is not a low price; it is a deferred one.

Ask each bidder for:

• Delivery cost
• Annual maintenance, years two to five
• Hosting and infrastructure, per year
• Day rate for changes outside the scope
• Cost of a data export and handover if the contract ends early

That last line is worth including precisely because vendors who intend to make leaving difficult will price it unusually.

The test that catches most of it

If this vendor disappeared tomorrow, could another one take over the system? Ask each bidder to answer that in writing, in their own words.

The answer tells you a great deal. A vendor building something maintainable will describe the documentation, the standard technology choices and the handover materials. A vendor building a dependency will be vague, or will explain why the question does not really apply to their approach.

None of this requires technical knowledge to evaluate. It requires only that the questions are asked before the contract is signed rather than after the system stops working.