What should you agree with a software subcontractor before a tender?

Start with the work package

Begin with the tender, not the subcontractor. Read what the buyer wants, then mark the part you would hand to a software developer. Describe it in plain language: a prototype, a particular application, an integration, testing or ongoing support. Say what is included, what is not, and who is responsible on each side of every handover.

Here is a made-up example. For a bid to build an internal tool, the lead supplier manages the buyer relationship, project management and acceptance testing. The developer builds an agreed application, writes deployment notes and fixes defects for a set period after launch. That is one possible split, not a standard one. The tender may need something different.

Agree the bid-stage roles

The work starts well before anyone writes code. Decide who reads the specification, who asks the buyer clarification questions, who prepares the estimates and who drafts or reviews each part of the response. Agree who has the final say on what is submitted, and who can make commitments on behalf of each party.

If a working concept would help explain the approach, agree what it should demonstrate, how much time goes into it and who may show it. Label it as a concept. A working screen helps people discuss an idea. It does not prove that every requirement, integration or security control is done.

Check what the tender asks of a subcontractor

Most public procurements in England, Wales and Northern Ireland that began on or after 24 February 2025 follow the Procurement Act 2023. Under it, a subcontractor can matter to a bid in two ways.

Every intended subcontractor. The buyer must ask for details of all the subcontractors a supplier intends to use, and check each one against the government’s debarment list. It may also check whether they are excluded or excludable for other reasons. If a subcontractor causes a problem, the supplier must be given the chance to replace them before being excluded. The government’s exclusions guidance explains the process.

A subcontractor you rely on to qualify. If the lead supplier needs the subcontractor’s capability or experience to meet the conditions of participation, the subcontractor becomes an “associated person”. The buyer must be satisfied that the two parties will enter into legally binding arrangements, and the associated person is named in the contract award notice. Tender documents may also ask associated persons to register on the Central Digital Platform and share their core supplier information before the deadline. See the conditions of participation guidance.

That second case changes what you need from each other. An early conversation can be exploratory, but if the bid depends on a subcontractor’s evidence, both parties need to commit to that before submission.

Not every procurement follows these rules. Ones that began before 24 February 2025, including call-offs from frameworks set up under the old rules, continue under the previous regulations, and Scottish devolved bodies have their own regime. Read the tender documents and check which rules apply.

Be precise about evidence

Read the conditions of participation and the tender questions together. List what the lead supplier will provide, what the subcontractor is expected to provide and what is still missing.

Be exact about whose experience each example shows and what it proves. A personal or commercial project can show how someone builds software and approaches a problem. It is not evidence of a completed public-sector contract unless it was one. Don’t include anyone’s name, project or capability in a response until they have checked the facts and agreed how it will be described.

Make the delivery plan realistic

Agree the availability the work needs and when decisions, access and other inputs are required. Who approves the design? Who provides a test environment or access to the buyer’s systems? What happens if an integration is late or a requirement needs clarifying?

Decide how progress and problems reach the lead supplier, and how often. A useful plan names dependencies and decision points, not only milestones. Neither party should promise a date, capacity or support arrangement the other hasn’t confirmed.

Settle information, security and ownership

Work out what information the subcontractor needs before the bid and, separately, during delivery. Use sample or redacted data for early demonstrations. Agree who may see tender documents, code, accounts and data, and check the tender for confidentiality, security clearance or data protection requirements.

Then agree who owns or may use what is created at each stage: a pre-bid concept, existing code the developer brings, new code, designs and documentation. If the bid fails, can either party reuse the demonstration? If it succeeds, what rights does the buyer expect, and what handover will the contract need? Settle this for each opportunity before the work starts.

Agree payment and support

Decide whether bid-stage work is paid, who pays for it and what happens if the bid does not go ahead. For delivery, agree the price or rate, payment milestones, expenses, how changes in scope are handled and how disagreements are resolved.

For contracts under the Procurement Act, section 73 implies payment terms into most subcontracts that help deliver a public contract: undisputed invoices are paid within 30 days. The parties can agree faster payment, but not slower.

Software needs looking after once it is live. Decide who handles hosting, updates, backups, incidents, support requests and the final handover, and what happens if the developer becomes unavailable. These jobs can be shared. They should not be left unassigned.

Write it down before you submit

As the bid takes shape, record the agreed role, the open questions and any assumptions the response relies on. Before submission, check whether the buyer expects named subcontractors, supporting evidence or a signed commitment, and make sure both parties agree on what the lead supplier may say about the other.

This guide is a checklist for the conversation, not legal advice. Take advice on the agreement itself for the specific bid.

A useful next step

If I were the developer in that conversation, I would want to start with the specification and a short description of the part that needs a software partner. From there we could talk honestly about fit, evidence and a realistic split of responsibilities before either of us commits.

If you are considering a software project or tender and would like to talk it through, email me.