Software Outsourcing Pitfalls: 5 Low-Price Traps and Contract Clauses

Projects that go wrong in software outsourcing rarely do so because the vendor cannot code. Far more often the price looked excellent at signing, costs started climbing halfway through, and at handover the source code, deployment documentation and account credentials turned out to be outside the contract. What these failures share is timing: the trap was set during the quotation stage, when it was hardest to see. That is why a guide to software outsourcing pitfalls focuses less on comparing prices than on reading how a quote is built.

At Juhui Software we have delivered projects and also been called in to rescue stalled ones. The five traps below are the most common, followed by a contract checklist you can verify without any technical background.

1. Trap one: the quote with holes in it

The method is simple. Leave necessary work out of the priced scope so the total looks twenty or thirty percent below competitors. Typical omissions are requirements analysis, UI design, testing, deployment, data migration, third-party integration and user documentation. When the project reaches that stage, the work returns as a change order.

How to catch it: map every line of the quote against your own feature list and look for a missing category of work. Then ask directly whether design, testing, deployment and documentation are included. A vendor comfortable answering has usually priced them.

2. Trap two: cheap day rates and open-ended hours

Charging by person-day is legitimate. The problem is at both ends: an extremely low rate staffed with junior people, and hours that have no ceiling because the project runs as long as it runs. A headline rate of 800 yuan per person-day looks attractive until doubled hours produce a larger total than the fixed-price bid.

The subtler version is a day rate with no defined scope. The contract contains a rate and a rough feature description, but no effort cap and no rule for what happens when work exceeds it. Once the timeline slips, the two sides disagree about whether the extra work was ever in scope.

Two countermeasures: state both the day rate and an effort cap, or preferably a ceiling price, with anything beyond it requiring a written change order; and require the seniority mix of the assigned team, since the ratio of senior to junior staff drives delivery quality.

3. Trap three: source code and IP held hostage

The contract says "deliver the system" but not who owns the code. After launch, when the client wants a second team for maintenance or wants to hire in-house, there is no compilable codebase: a zip file without dependencies, build instructions or commit history. At that point the original vendor holds all the leverage.

What needs stating is not only that the client owns the source, but the mechanics: the full repository including commit history, reproducible build instructions that work from a clean environment, database schema and seed scripts, transfer of third-party accounts and keys, and revocation of the vendor's own access after handover. Adding these at signing costs almost nothing; adding them after delivery is expensive.

4. Trap four: maintenance pushed downstream

Another route to a low quote is separating out post-launch costs. Servers and cloud resources are excluded, third-party service activation is excluded, and no defect-fix period is agreed. When a blocking bug appears in week one, the client discovers the contract is silent on who fixes it for free.

Common industry practice is a warranty period after acceptance, typically three to six months, covering defect fixes, followed by an annual maintenance fee usually in the range of 15 to 20 percent of the build cost. Both should be settled before signing, not negotiated under pressure later.

5. Trap five: no rule for pricing change

No software project avoids change entirely. What decides whether it spirals is not whether change happens but how change is priced. Without a rule, adding one field and adding one module can attract similar quotes, or repeated verbal approvals leave no trace at all.

A workable approach writes the process into the contract: changes are raised as written change orders, each listing affected modules, added duration and added cost, effective on both signatures, with the acceptance checklist and payment milestones adjusted accordingly. The process feels heavy, but it is the only mechanism that keeps a budget controllable.

6. Nine clauses to confirm before signing

1. Scope list: features itemised as an annex, including an explicit statement of what is out of scope;
2. Deliverables: source code, repository, deployment documentation, database scripts, API documentation and user manual, listed individually;
3. Acceptance criteria: pass conditions, defect severity definitions, review period, and what happens if acceptance fails;
4. Payment milestones: tied to checkpoints such as signing, prototype approval, development completion and acceptance, avoiding an oversized upfront payment;
5. Change rules: written change order, impact assessment, effective only on both signatures;
6. Intellectual property: ownership of code and documentation, licence disclosure for third-party components, and destruction of production data after handover;
7. Warranty and maintenance: warranty length, response times, and the scope and rate of annual maintenance afterwards;
8. Confidentiality and data security: data usage limits, personnel obligations, disposal of data at project end;
9. Default and termination: liability for delay, termination conditions, settlement for completed work and the obligation to hand over source code on termination.

Clauses four and nine are the ones most often skipped. An unbalanced payment schedule removes your leverage over delivery pace; the absence of a termination clause leaves no exit when one party stops cooperating.

7. Judging whether a low quote is credible

Read the five traps backwards and you get three actions, and they are the practical core of avoiding software outsourcing pitfalls. First, demand a quote broken down by module and by page rather than a single number. Second, ask what the price excludes, and trust the vendor who names exclusions over the one who claims to cover everything. Third, insist that scope, acceptance, change rules and code ownership appear in the contract annex.

Low price is not the enemy. It is a perfectly good outcome when it corresponds to a narrower, explicitly stated scope. The dangerous case is identical scope at a visibly lower price, because the gap returns as change orders, delay or defects. Avoiding pitfalls in software outsourcing is not about choosing the cheapest or the most expensive bid. It is about putting the boundaries in writing. Juhui Software signs the feature list, deliverable list and change rules as contract annexes, not to add process for its own sake but to settle in advance the points where disputes usually start.