Teaming agreement vs. subcontract for software delivery

Most software teaming goes wrong in one of two ways. Either the partners sign a teaming agreement, win, and then discover the agreement did not actually commit anyone to anything. Or they paper the relationship carefully and leave the data rights question for later, and the government ends up with less than it needed, or the developer ends up with less than it expected.

A teaming agreement usually organizes pursuit of an award; a subcontract specifies the work and terms of performance. Neither label alone tells you whether a particular promise is enforceable. For software, agree scope, acceptance, intellectual property, and handover before the proposal creates expectations.

Compare the actual documents, including conditions and order of precedence. Have counsel assess enforceability under the governing law.

What is a contractor team arrangement?

FAR Subpart 9.6 recognizes two forms. The first is a partnership or joint venture where two or more companies act together as the potential prime. The second is a prime contractor and subcontractor agreeing to work together on a specific contract or program.

FAR 9.6 tells the government how to treat these arrangements. It does not make them enforceable between the parties. Whether your teaming agreement binds anyone is a question of state contract law, under whichever state's law your agreement names.

Does a teaming agreement actually guarantee work?

Not automatically. A commitment to negotiate a later subcontract can leave the actual scope and work share unresolved. Confidentiality, exclusivity, or other provisions may still create obligations. Read each promise and its conditions rather than treating the entire document as either binding or meaningless.

Give counsel definite terms to review rather than relying on the document's title:

• A specific statement of work for the subcontractor, not a general description of capability
• A defined work share, expressed as a percentage or named CLINs
• A pricing method, even if actual rates follow later
• "Shall award" language rather than "intends to negotiate"
• Exclusivity, if you want it, with a stated duration and scope
• A clear termination trigger, usually non-award or a fixed date

Treat it as what it is: a pre-award instrument that allocates bid responsibilities and protects proposal information. The subcontract is the document that governs performance. Negotiate the material terms of the subcontract before you submit, and attach it. A term sheet agreed under deadline pressure after award is negotiated from a much weaker position, because the work has to start regardless.

When does a joint venture make more sense?

A joint venture is the right structure when neither firm can credibly prime alone and both want their past performance to count. The trade is complexity: a JV is a separate entity with its own agreement, accounting and compliance obligations.

For small business set-asides, the SBA mentor-protege program is usually the reason to consider one, because an approved mentor-protege JV can compete for a set-aside the protege could not otherwise pursue without triggering affiliation. The SBA's contracting assistance programs page is the starting point, but this is an area where the agreement needs specialist review. The rules on JV performance of work and on what the protege must do itself are specific, and getting them wrong invalidates the eligibility the structure was built to create.

For most single-award software scopes, a prime and subcontractor relationship is simpler and sufficient.

How much work can the subcontractor actually take?

If the prime contract is a small business set-aside, this is constrained by regulation, not preference. Under FAR 52.219-14, a small business prime on a services contract cannot pay more than 50 percent of what the government pays it to subcontractors that are not similarly situated entities.

There is a second, independent risk. Even within the spending cap, a prime can be found affiliated with a subcontractor that performs the primary and vital requirements of the contract or on which the prime is unusually reliant. That is the ostensible subcontractor rule at 13 CFR 121.103(h), and the consequence is that SBA treats the two firms as one for size purposes.

For software work this deserves attention, because "primary and vital" tends to mean the engineering. A small business prime that holds the contract while a larger partner writes all the code is the fact pattern the rule exists to catch. The mechanics, including the 2023 safe harbor, are covered in small business subcontracting credit: what actually counts.

Structure the work share so the prime genuinely performs core engineering, and document it.

Who owns the software at the end?

Separate ownership from license rights. Decide who owns new code between the prime and subcontractor, identify pre-existing code, and separately determine what rights the government receives. Delivering source code or granting the government unlimited rights does not, by itself, answer who owns the copyright.

For covered DoD noncommercial software, DFARS 252.227-7014 describes government license rights; the contractor retains rights not granted. Its general funding framework is below. Software documentation, SBIR/STTR data, commercial software, and negotiated rights require their own clause analysis.

Three consequences for a teaming conversation:

Know what you are bringing. Software developed at private expense before the contract keeps its character if you identify and mark it correctly. Software you fail to assert rights in can end up delivered with broader rights than you intended. Build the assertions list before award, not at delivery.

The five-year clock is negotiable. The government purpose rights period can be extended, and the DFARS contemplates longer periods where five years is not enough to commercialize, including to recognize a subcontractor's interests in software it developed. Ask.

Clauses flow down. A subcontractor's rights in its own software are established in the subcontract. A subcontract that silently incorporates every prime contract clause without addressing the subcontractor's pre-existing software is a problem that surfaces at delivery.

Open source adds a parallel question. Agree the license policy, the approval process and the bill of materials expectation up front, because an agency that discovers a copyleft dependency during a security review will ask who authorized it.

Turn the software scope into an acceptance example

Consider an illustrative scheduling increment: an authorized operator assigns a qualified crew to an available aircraft. Define which service checks conflicts, how the interface reports a rejected assignment, what an audit record contains, and which tests the prime will review. Assign responsibility for the identity integration and test data before pricing the increment.

This example draws its domain from Rainier's published Vennli scheduling portal subcontract, which covered a Python backend and a React interface over twelve months. The example is a proposed acceptance pattern, not a quotation from that subcontract or a claim about its legal terms.

Use our software subcontractor acceptance checklist to specify the review evidence, and compare the software scopes Rainier can deliver with the work you intend to retain.

What else belongs in the subcontract?

Beyond scope, price and schedule:

• Flow-downs, listed explicitly. FAR 52.219-8 on utilization of small business concerns, Section 889 representations under FAR 52.204-25, and on defense work the cybersecurity clauses including DFARS 252.204-7012 and any CMMC level required by the data the subcontractor will touch.
• Key personnel, named, with substitution consent. The most common performance complaint about subcontractors is that the engineers who appeared in the proposal never appeared on the project.
• Acceptance criteria that describe working software. Define done at the increment level, not at the end.
• Payment terms tied to something observable. Accepted increments, not elapsed time.
• Security and incident obligations, including the 72-hour cyber incident reporting that DFARS 252.204-7012 imposes, flowed down with real contact points.
• Accessibility responsibility. Decide who produces the Accessibility Conformance Report and who remediates findings. Section 508 obligations do not disappear because the work was subcontracted.
• Transition and handover. Repository access, documentation standard, and what happens to credentials and infrastructure at the end.
• Dispute resolution that does not stop delivery. Escalation first, with work continuing while it runs.

The short version

A teaming agreement sets intent and protects the bid. A subcontract governs performance, but work-share certainty depends on the actual promises, conditions, and ordering terms. Agree the material terms of both before the proposal goes in, settle data rights while you still have leverage, and size the work share so the prime genuinely performs the core engineering.

Rainier Software Solutions works both sides of this arrangement, as a prime and as a software subcontractor to other primes. Our contracting and teaming information identifies available buying routes and the inputs needed for a scope discussion. Bring work share, rights, and acceptance questions to that discussion before proposal commitments harden.

Discuss a teaming arrangement→