Has Your Software Project Been Subcontracted? Five Warning Signs and Three Contract Clauses

Halfway through a project, the client notices that the people on the calls have changed, the names in the code commits do not match anyone introduced, and answers to questions take longer every week. One common explanation is that the work has moved to another company or another group of people. Subcontracting is not automatically deception; legitimate delegation is common in this industry. But it changes one thing concretely: who is accountable when something breaks.

At Juhui Software we have taken over projects that clients discovered had been passed on, and we have also worked as a disclosed subcontractor on compliant projects. In software subcontracting the decisive question is not whether a third party is involved. It is whether the client knows, and whether someone still carries the responsibility. Here are the signals you can check, how to tell the cases apart, and how to write the clauses.

1. Three different arrangements, three different consequences

Full subcontracting means the contractor hands over all or the substantial part of the work and no longer performs it, keeping only a management layer or simply passing invoices. Many contracts prohibit this outright, and clients usually gain a right to terminate, because the vendor was selected on the strength of its capability, references and team.

Partial delegation means the contractor gives non-core, non-critical portions to third parties, for example UI design, a specific third-party integration or hardware firmware, while keeping the main build in house. This is normally lawful and sensible, provided the contract allows it and the client is told in advance.

Borrowed staff means engineers are brought in temporarily to work inside the contractor's own team, managed and delivered by the contractor. The risks here are continuity and confidentiality rather than accountability.

The test fits in one sentence: is the substantial work still performed, managed and warranted by the party that signed? If yes, this is delegation or borrowed staff. If no, it is subcontracting.

2. Five checkable signals

Signal one: the named team does not match reality. A proper quote and contract lists the team: who is the project manager, product owner, designer, front end, back end, tester, and for how long. Once work starts, compare actual participants against that list. Normal turnover is expected, but wholesale replacement, or a key role that never appears, deserves a direct question.

Signal two: code commits do not match the claimed team. If the repository sits somewhere the client can access, which it should, the author names, commit frequency and timestamps tell the story. Typical anomalies are commits clustering at a fixed hour late at night, author names that are meaningless strings, or many commits pushed by one account on behalf of others. No technical background is needed; read-only repository access is enough.

Signal three: the communication chain gets longer. The person who used to answer technical questions directly starts saying they will check and revert. Change impact assessments go from one day to three. Nobody in the meeting can commit to an implementation approach. That is what information looks like when it has to travel through an intermediary.

Signal four: site visits and attendance are deflected. A request to visit the development site once, or to have key people attend a review in person, keeps being postponed. Remote development is perfectly normal, so this signal is not about requiring an office. It is about whether the vendor will give a definite answer to the question of who is doing the work.

Signal five: ownership records point elsewhere. Server accounts in deployment documents, the organisation name on the code repository, the applicant entity for payment, SMS and mapping services, and the registrant of the software copyright all leave traces of who actually executed the work. Where those entities differ from the contracting party, an explanation is due.

3. If you find it, assess before you act

Responses differ sharply by situation, and discovering third-party involvement is not by itself a reason to terminate.

Where a non-core portion was delegated and quality and schedule are holding, the practical move is to require written disclosure: name the third party, define its scope, add confidentiality obligations and data boundaries to the contract annex, and confirm that the contractor remains fully liable for the whole delivery. That preserves continuity and puts accountability back where it belongs.

Where the main build was handed over and the contractor can no longer answer on technical approach, the risk is material: nobody assesses changes, defect fixes wait on someone else's queue, and the completeness of source code and documentation cannot be assured. The first action then is not argument but inventory. Secure repository access, server and database credentials, third-party service accounts and delivered documents in the client's own hands before discussing liability. Without the assets in hand, there is no leverage.

Where a large advance has been paid and deliverables are missing, handle it under the breach clauses and keep the communication record. Whether the contract prohibited subcontracting and granted a termination right determines what you can actually do at that point.

4. Three software subcontracting clause types worth more than post-hoc blame

Performance and disclosure. State that the substantial work must be performed by the vendor; that any third-party involvement in non-core areas requires prior written notice and client consent; that third parties sign confidentiality agreements; and that the vendor remains fully liable for their output. The last half of that sentence is the important part. Delegation is allowed, liability does not move.

People and assets. State that key roles are named and changes are notified in advance; that code is committed to a repository the client can access with read-only rights, with commit history serving as performance evidence; and that server, database and third-party service accounts are applied for in the client's name and transferred at delivery. This clause covers both detection and asset security.

Breach and termination. State that unauthorised subcontracting of substantial work entitles the client to require remediation, withhold the corresponding amount, or terminate, along with how completed work is settled and how source code and documentation must be handed over. A prohibition with no consequence attached has almost no force.

5. The step before all of this: qualify properly

Subcontracting has room to exist largely because prices get pushed below what the real work costs. A quote well under the market band leaves the vendor either funding the gap itself or passing the work on, and the second is more common. So the most effective protection is not a clause but two things at quotation stage: require the quote to list person-days by role and cross-check the total against the timeline; and require two or three contactable past clients, with enough detail to show the vendor knows the technical specifics.

A vendor that can explain which parts of your project it will build itself and which it will source externally is more trustworthy than one that insists everything stays in house but cannot produce a person-day table. With software subcontracting, what matters is where accountability sits, not how the org chart is drawn. Put the responsibility in the contract and the assets in your hands, and the project stays under your control.