Nguyen Manh Thang
Chief Executive Officer, AgileTech Vietnam
- Published
- Read time
- 15 min
In short
The most expensive mistakes in a software development contract are not exotic. They are a scope written as a wish list instead of a specification, acceptance criteria that do not exist so nothing is ever formally done or not done, intellectual property that stays with the vendor because the assignment clause is missing or conditional on final payment, a fixed price attached to a scope that was never fixed, no change order process so every change becomes an argument, milestone payments tied to dates instead of delivered increments, no source code and environment access for the buyer, a liability cap that is either absent or set at a trivial number, no termination for convenience so a failing engagement cannot be ended, no transition assistance so leaving is impossible in practice, warranty and support periods left undefined, and confidentiality and data protection terms that ignore where the data actually lives. Each has a standard fix, and most of them fit in a single well-drafted clause. A buyer who checks these twelve before signing will avoid the majority of disputes that end up in mediation.
Most software development contracts are signed by people who are not lawyers, on a timeline set by a business need, using a template one side has used before. That is fine; the alternative is not signing. But it means the same dozen mistakes appear in contract after contract, and they surface months later at exactly the moment when the relationship is already strained: a scope argument at a milestone, a discovery that the code belongs to the vendor, a vendor who will not hand over the environments, a project that cannot be ended without paying for work that was never done.
This article lists the twelve mistakes that cost buyers the most, in roughly the order they appear in a contract, and pairs each with the clause or practice that closes it. It is written for founders, product leaders, and engineering managers on the buying side, and it is not legal advice; it is the checklist a good lawyer will be glad you brought to the meeting, so the expensive hour is spent on the hard questions rather than the standard ones. Vendors reading it will recognize the same list from the other side, and the best vendors already propose most of these terms themselves.
The context is any software engagement with an external team, whether a local agency, a nearshore partner, or an offshore development center, and the guidance applies to all of them. Where the engagement is offshore, two of the twelve (data protection and governing law) carry extra weight, and the article says so. The economics of choosing an external team are covered in the guide to software outsourcing in Vietnam; this piece assumes that choice is made and the contract is on the table.
Key takeaways
- Scope is the contract. If the statement of work cannot be tested against, every downstream clause about price, acceptance, and delay is unenforceable in practice.
- Acceptance criteria and a defined acceptance window are what turn delivered into accepted. Without them, the buyer has no leverage and the vendor has no finish line.
- Intellectual property should assign to the buyer as work is paid for, with a license-back to the vendor for its pre-existing tools, and it should never be conditional on the final invoice alone.
- Fixed price without fixed scope is the most common contract failure. Choose a pricing model that matches how well the scope is actually known.
- The change order process is not bureaucracy; it is the mechanism that keeps a fixed-price project from becoming a dispute. Define it before the first change.
- Termination for convenience with a notice period, plus a transition assistance clause, is what makes the relationship a choice rather than a trap.
Mistakes 1 and 2: a scope that cannot be tested and acceptance that never happens
The first mistake is a statement of work written as a description of hopes. "A mobile app for customers to order and track deliveries, with an admin dashboard" is a product vision, not a scope; it says nothing about which platforms, which payment methods, what tracking means, how many admin roles, what happens offline, or which of the two hundred decisions implied by that sentence are in and which are out. Every argument about price, delay, and quality later in the project traces back to a sentence like this one, because neither side can point to the document and say what was agreed. The fix is a scope with a testable boundary: user stories or feature lists with acceptance criteria, explicit exclusions, named integrations, target platforms and versions, and non-functional requirements (performance, security, accessibility) stated as numbers where possible.
The second mistake follows from the first. Acceptance is the moment a deliverable stops being the vendor's problem and becomes the buyer's asset, and it should trigger payment. In contracts that omit it, deliverables are handed over, the buyer looks at them for a while, raises issues informally, the vendor fixes some, and nobody can say whether the milestone is done. The fix is an acceptance clause with three parts: the criteria a deliverable must meet (which the scope already defines), a window in which the buyer must test and either accept or reject in writing with specific defects listed, and a deemed acceptance rule so that silence after the window counts as acceptance. The window is typically five to ten business days; the deemed acceptance rule protects the vendor from a buyer who never gets around to testing, and the written defect list protects the buyer from a vendor who declares things done.
Between these two sits a practice that is cheap and almost always skipped: a definition of done shared by both sides before the first sprint. Does done include automated tests, documentation, deployment to a staging environment, a demo? A one-page definition attached to the statement of work removes a whole category of milestone arguments. Teams that follow a disciplined software development process will already have one; the contract should reference it.
Contract habits that protect buyers, and the ones that expose them
Do this
- Feature lists with acceptance criteriaEach item states what a tester would do and what they would see. If it cannot be tested, it is not scope.
- Explicit exclusionsA short list of adjacent things that are out (native tablet layout, admin analytics, third language) prevents the assumption that they are in.
- Numbers for non-functionalsPage load under two seconds on a mid-range device; 99.5 percent monthly availability; WCAG 2.2 AA. Not fast, reliable, and accessible.
- Acceptance window with deemed acceptanceTen business days to accept or list defects in writing; silence is acceptance. Both sides are protected.
Not this
- Vision statements as scopeA customer app with a dashboard describes a category of products, not a deliverable.
- Best efforts and industry standardUndefinable terms that shift the dispute to what the words mean.
- Acceptance by useIf the buyer deploying the software counts as accepting it, the buyer loses the right to reject defects found in production.
- Open-ended reviewNo window means the vendor is never paid and the buyer never has to decide.
Mistakes 3 and 4: intellectual property that never transfers, and code the buyer cannot reach
Under the default rules of most jurisdictions, the party that writes code owns the copyright in it unless a contract says otherwise. Buyers are routinely surprised to discover, usually during a fundraise or an acquisition when a lawyer asks for the chain of title, that the contract with their development partner never assigned the intellectual property, or assigned it only on final payment of a final invoice that was disputed, or assigned it in a clause so narrow that the underlying libraries, designs, and documentation were excluded. The fix is a present assignment clause: the vendor hereby assigns to the buyer all intellectual property in the deliverables, the assignment taking effect as each deliverable is paid for, with a covenant to sign any further documents needed to perfect it. Assignment tied to payment of each invoice is fair to both sides; assignment tied only to the final invoice gives the vendor a hostage.
Two refinements make the clause work in practice. First, vendors legitimately bring pre-existing tools, frameworks, and libraries to a project, and they should keep those; the clause should carve out vendor background IP and grant the buyer a perpetual, irrevocable, royalty-free license to use it as embedded in the deliverables. Second, open source components carry their own licenses, and the contract should require the vendor to disclose them and to avoid licenses (strong copyleft, for instance) that the buyer has not approved for its use case. A software bill of materials at each release is now a reasonable ask.
The fourth mistake is practical rather than legal: the buyer owns the code on paper but cannot reach it. The repository is in the vendor's account, the cloud environments are billed to the vendor, the domain and app store listings are registered by the vendor, and the deployment pipeline runs on credentials only the vendor holds. When the relationship sours, ownership becomes theoretical. The fix is a clause requiring that repositories, cloud accounts, app store accounts, domains, and third-party service accounts be created in the buyer's name from day one, with the vendor granted access, and that all credentials be held in a vault the buyer controls. Where the vendor must host during development, the contract should require continuous mirroring to a buyer-owned repository and a written handover of environments at each milestone.
The ownership checklist to run before the kickoff, not the breakup
- Present assignment, per paid deliverableHereby assigns, effective as each invoice is paid. Not will assign, not on final payment.
- Background IP carve-out with a license-backThe vendor keeps its tools; the buyer gets a perpetual license to them as embedded.
- Open source disclosure and approvalA bill of materials per release and a list of licenses the buyer will not accept.
- Accounts in the buyer's nameRepos, cloud, app stores, domains, analytics, email providers. Vendor has access, buyer has ownership.
- Credentials in a buyer-controlled vaultRotate on any staffing change; the buyer can revoke everything in an hour.
- Moral rights and waivers where applicableIn some jurisdictions authors retain rights that survive assignment; get the waiver.
Mistakes 5 and 6: fixed price on unfixed scope, and no change order process
The fifth mistake is the most common and the most expensive: a fixed price attached to a scope that is not actually fixed. Buyers like fixed price because it feels like certainty; vendors accept it because they want the work; both are then surprised when the first ambiguity in the scope becomes a negotiation over whether it is included. The vendor, having priced to a thin margin, argues every gray area is out of scope; the buyer, having been promised a price, argues every gray area is in. Quality is the usual casualty, because the vendor makes the number work by cutting what the buyer cannot see: tests, documentation, refactoring. The fix is to match the pricing model to how well the scope is known. A fixed price is right for a tightly specified, short deliverable. Time and materials with a cap and a detailed estimate is right for a product that will evolve. A dedicated team at a monthly rate, the model behind a dedicated development team, is right for a long engagement where the buyer directs the work. Hybrids, such as a fixed-price discovery phase followed by an estimated build, are often the honest answer.
The sixth mistake is the absence of a change order process, and it turns every fixed-price project into a slow-motion dispute. Change is not a failure; a project that ends with the scope it started with was probably not learning anything. The failure is having no agreed way to handle it, so each change is an argument about whether it is a change at all. The fix is a clause that defines the process: either party may propose a change in writing; the vendor responds within a set number of days with the effect on price, schedule, and other work; no change is started until the buyer approves in writing; and small changes below a threshold can be absorbed against a contingency pool so the process does not stall the project. The clause should also state what happens to the schedule when the buyer is late with inputs, because buyer-caused delay is the most frequent change of all.
A related practice worth writing down is the contingency itself. Fixed-price projects should carry an explicit contingency (ten to twenty percent is typical) controlled by the buyer, drawn on by approved change orders, and returned if unused. It converts the vendor's hidden padding into visible money the buyer directs, and it gives both sides a way to say yes to small changes without a ceremony. The offshore development rate guide covers what the underlying day rates look like by region; the contract question is how those rates attach to scope.
Which pricing model fits the scope
Which pricing model matches the scope you actually have?
-
Tight specification, under three months, low uncertainty
Fixed price with an explicit contingency and a change order clause
Both sides can price it; the contingency absorbs the small surprises.
-
Product will evolve; requirements known at the epic level
Time and materials with a not-to-exceed cap and a detailed estimate
Pays for what is built; the cap and estimate give the buyer a budget frame.
-
Long engagement; buyer wants to direct priorities weekly
Dedicated team at a monthly rate with defined roles and replacement terms
Predictable spend, maximum flexibility on what is built; the team is the deliverable.
-
Nobody can honestly estimate yet
Fixed-price discovery, then an estimated build under one of the above
Two to six weeks of paid discovery produces the scope the build contract needs.
Mistakes 7 and 8: milestones tied to dates, and a liability cap that is missing or meaningless
The seventh mistake is a payment schedule tied to calendar dates rather than delivered increments. It looks like a plan; in fact it decouples money from progress, so a vendor who is behind is paid anyway and a buyer who is slow with inputs is invoiced anyway. The fix is milestones defined by accepted deliverables, each with a payment attached, using the acceptance clause from mistake two to decide when each is reached. A modest mobilization payment at signing is reasonable; the bulk should follow acceptance. Retention, holding back a small percentage until the end of the warranty period, is common in construction and sensible in software, though vendors will resist it and it should be small enough not to strain them.
The other half of this mistake is invoicing that does not match the pricing model. Time and materials engagements need timesheets or work logs at a granularity the buyer can audit, an approval step before invoicing, and a monthly cap notification when spend approaches the not-to-exceed. Dedicated team engagements need the roster invoiced, not hours, with a clear rule for partial months and replacements. Fixed-price engagements should invoice only against milestones. When the invoice mechanism and the pricing model disagree, the invoice mechanism wins in practice, and the buyer pays for the mismatch.
The eighth mistake is the liability clause, which buyers either do not read or read and ignore. Vendor templates typically cap liability at the fees paid in the preceding few months and exclude all indirect and consequential loss, which sounds reasonable until a data breach caused by the vendor's negligence costs the buyer a regulator's fine and a year of customer trust. The fix is not unlimited liability, which no vendor will accept and which is unfair; it is a cap that is proportionate (fees paid or payable under the whole statement of work is a common midpoint), with carve-outs from the cap for the things that matter: breach of confidentiality, breach of data protection obligations, infringement of third-party intellectual property, and willful misconduct. The buyer should also check that the vendor carries professional indemnity and cyber insurance at a level that makes the cap collectible.
Where the liability clause usually lands, and where a buyer should push
| Term | Vendor template position | Reasonable buyer position | Why it matters |
|---|---|---|---|
| General cap | Fees paid in the last 3 to 6 months | Fees paid or payable under the SOW | A three-month cap on a two-year project is a small fraction of the risk |
| Indirect and consequential loss | Fully excluded | Excluded, except in the carve-outs | Data loss and downtime are consequential; some must be recoverable |
| Confidentiality breach | Under the general cap | Carved out, or a separate higher cap | A leaked roadmap or customer list is not a three-month problem |
| Data protection breach | Under the general cap | Carved out, or a separate higher cap | Regulator fines and notification costs can exceed the whole contract |
| Third-party IP infringement | Limited or absent | Vendor indemnifies the buyer, uncapped or high cap | The buyer ships the code; the vendor chose the components |
| Insurance | Not mentioned | Professional indemnity and cyber cover at a stated minimum | A cap is only worth what the vendor can pay |
Typical positions in a mid-size development engagement. The carve-outs matter more than the headline cap.
Mistakes 9 and 10: no way to end it, and no way to leave
The ninth mistake is a contract that can only be terminated for cause. Cause means material breach, which means proving in a dispute that the vendor failed to meet an obligation the scope (mistake one) probably never defined clearly. The result is a buyer stuck in a failing engagement, paying to the end because the exit is a lawsuit. The fix is termination for convenience: either party may end the engagement on written notice, typically thirty to ninety days depending on team size, with the buyer paying for work accepted and work in progress to the notice date, and nothing else. Vendors sometimes ask for an early termination fee to cover ramp-up and bench costs; a modest one, declining over the first months, is a fair trade for the buyer's right to leave.
Termination for cause still belongs in the contract, with a cure period (fifteen to thirty days to fix a notified breach) and a list of breaches that need no cure, such as insolvency, breach of confidentiality, or assignment of the contract without consent. Both kinds of termination should state what survives: confidentiality, the IP assignment, warranty on accepted work, and the transition obligations in the next paragraph. A contract that is silent on survival invites the argument that everything ended when the engagement did.
The tenth mistake is the absence of transition assistance, and it is what turns a theoretical right to leave into a practical inability. On termination for any reason, the vendor should be obliged to deliver all work in progress, source code, documentation, and credentials; to hand over environments and accounts (which mistake four should have put in the buyer's name already); to provide knowledge transfer sessions to the buyer or its new vendor for a defined period at the standard rate; and to cooperate in good faith with the successor. Without this clause a vendor who has been terminated has every incentive to make leaving as painful as possible, and a buyer who knows that will not exercise the right. With it, both sides behave better throughout the engagement, because the exit is always available and always orderly.
What an orderly exit looks like when the contract has planned for it
-
NoticeDay 0
Written notice under the termination for convenience clause. Notice period starts; the vendor keeps working on agreed priorities.
-
Freeze and inventoryWeek 1
Scope is frozen to in-flight work. Both sides agree the inventory of deliverables, environments, accounts, and documents to hand over.
-
Handover of assetsWeeks 1 to 3
Repositories confirmed in buyer ownership, credentials rotated to the buyer's vault, environments and third-party accounts transferred, documentation delivered.
-
Knowledge transferWeeks 2 to 6
Recorded walkthroughs of architecture, deployment, known issues, and backlog with the successor team, at the standard rate.
-
Final acceptance and paymentEnd of notice
Work in progress accepted or listed as incomplete; final invoice covers accepted work and transition time only.
-
SurvivalOngoing
Confidentiality, IP assignment, and warranty on accepted work continue under the clause that says they do.
Mistakes 11 and 12: warranty and support left vague, and data terms that ignore geography
The eleventh mistake is a warranty that is either absent or a single sentence promising the software will conform to the specification, without saying for how long, what conformance means, or what the remedy is. The fix has four parts: a warranty period after acceptance (sixty to ninety days is common, and the number should be written down); a definition of a defect that references the acceptance criteria; a remedy, which is normally repair at no charge within a response time set by severity; and an exclusion for defects caused by buyer changes or third-party systems. Beyond the warranty period the contract should either include or expressly exclude ongoing support and maintenance, with a separate schedule of severity levels, response and resolution targets, and monthly or hourly pricing if included. Buyers who assume support is included and vendors who assume it is not have the same argument in month four.
The twelfth mistake is confidentiality and data protection drafted without asking where the data will actually be. Development teams, and offshore development teams in particular, handle production data more often than anyone plans: for debugging, for migration, for realistic testing. If the team is in another country, that data has crossed a border, and the buyer's obligations under its own data protection regime (GDPR, the various US state laws, PDPA in Singapore, Vietnam's Decree 13, and others) follow it. The fix is a data protection addendum that names the categories of data the vendor may access, requires anonymized or synthetic data for development and testing wherever possible, specifies the security controls the vendor must maintain, records where data may be stored and processed, includes the transfer mechanism the buyer's regime requires, and defines breach notification within a stated number of hours. For an offshore development center engagement, this addendum is not optional paperwork; it is the document the buyer's own regulator will ask for.
Two smaller clauses belong here because they are so often wrong. Governing law and dispute resolution should be chosen deliberately: a buyer in one country and a vendor in another should agree on a neutral law and a forum or arbitration seat that both can realistically use, and should include an escalation ladder (project leads, then executives, then mediation) before anyone files anything. And non-solicitation should run both ways with a reasonable term; a buyer that hires away the vendor's lead engineer mid-project and a vendor that recruits from the buyer's team are both breaches of trust the contract can price in advance.
How to negotiate all twelve without poisoning the relationship
A buyer who arrives with these twelve points can come across as adversarial, which is a poor start to a relationship that depends on trust. The framing that works is that every one of these clauses protects both parties: acceptance criteria give the vendor a finish line, change orders let the vendor be paid for changes, present assignment per invoice gives the vendor leverage over unpaid work, termination for convenience with a fee compensates the vendor's ramp-up, and transition assistance is paid work. Good vendors know this and often propose most of it themselves; a vendor who resists all of it is telling the buyer something.
Order matters. Negotiate the commercial shape first (pricing model, team, timeline, and the scope document), because the legal terms follow from it; a fixed-price contract needs a different change and acceptance structure from a dedicated team agreement. Then agree the master services agreement, the document that governs the relationship and rarely changes, and keep statements of work short and specific, one per phase or product, each referencing the master agreement. This structure lets the parties add work without renegotiating the legal terms every time, and it means a dispute on one statement of work does not put the whole relationship at risk.
Finally, use the lawyer well. The hour is expensive; spend it on the liability carve-outs, the IP clause, the data protection addendum, and governing law, which are the places where drafting quality changes outcomes. The scope, acceptance, change order, and milestone terms are product management, not law, and the buyer's own team should write them. A contract that the buyer's product lead cannot explain is a contract the buyer will not be able to enforce. The comparison of in-house and outsourced teams covers the strategic choice; the contract is where that choice either works or does not.
Which clauses matter most under each engagement model
| Fixed price | Time and materials | Dedicated team | |
|---|---|---|---|
| Testable scope and acceptance | Yes | Partial | Partial |
| Change order process | Yes | Partial | No |
| Milestone payments | Yes | No | No |
| Timesheets and cap notices | No | Yes | Partial |
| Roles, replacement, and retention terms | No | Partial | Yes |
| Termination and transition | Partial | Yes | Yes |
| IP assignment per invoice | Yes | Yes | Yes |
| Data protection addendum | Yes | Yes | Yes |
Filled means the clause is load-bearing under that model; partial means it matters but has less to do; empty means it is rarely the problem.
Conclusion: the contract is the project's first design document
A software development contract is not a formality that precedes the real work; it is the first design document of the project, the one that decides how scope is defined, how change is handled, who owns what, and how the engagement ends. The twelve mistakes in this article all come from treating it as paperwork. The fixes are not complicated, and most of them protect the vendor as much as the buyer. A buyer who insists on them is not being difficult; they are being the kind of client that good vendors want, because the rules are clear and the money follows the work.
The practical step is to take this list into the next negotiation, use it to structure the statement of work before the lawyer sees anything, and spend the legal budget on the four clauses where drafting changes outcomes. Nothing here is legal advice, and jurisdictions differ; the point is to arrive at the lawyer's office with the right questions already asked.
- Scope you can test. If a tester cannot check it, it is not in the contract, whatever the document says.
- Money follows acceptance. Milestones by delivered increment, acceptance windows with deemed acceptance, IP assigned per paid invoice.
- Change has a process. Written proposals, priced responses, buyer approval, a contingency for the small stuff.
- The exit is always open. Termination for convenience, transition assistance, and accounts in the buyer's name make leaving orderly, which makes staying a choice.
Frequently asked questions
What should a software development contract include?
At minimum: a testable scope with acceptance criteria and exclusions; an acceptance process with a window and deemed acceptance; a pricing model matched to scope certainty, with a change order process and a contingency; milestone payments tied to accepted deliverables; present assignment of intellectual property per paid invoice with a background IP carve-out; accounts and repositories in the buyer's name; a proportionate liability cap with carve-outs for confidentiality, data protection, and IP infringement; termination for convenience and for cause, with transition assistance and survival terms; a defined warranty and support schedule; a data protection addendum; and governing law with an escalation ladder.
Who owns the code in an outsourced software project?
By default, in most jurisdictions, the party that wrote it, which is the vendor, unless the contract assigns it. Buyers should insist on a present assignment clause that transfers intellectual property as each invoice is paid, a carve-out for the vendor's pre-existing tools with a perpetual license back to the buyer, disclosure of open source components, and repositories and cloud accounts created in the buyer's name from the start so that ownership is practical as well as legal.
Is fixed price or time and materials better for software development?
Neither is better in general; each matches a different level of scope certainty. Fixed price works for short, tightly specified deliverables and needs a change order process and a contingency to survive contact with reality. Time and materials with a not-to-exceed cap suits evolving products where requirements are known at the epic level. A dedicated team at a monthly rate suits long engagements the buyer wants to direct. When nobody can estimate honestly, a fixed-price discovery phase followed by an estimated build is the candid answer.
What is a reasonable liability cap in a software contract?
Vendor templates often cap liability at fees paid in the preceding three to six months, which is low for a long project. A common midpoint is fees paid or payable under the statement of work. More important than the headline number are carve-outs from the cap for breach of confidentiality, breach of data protection obligations, third-party intellectual property infringement (which the vendor should indemnify), and willful misconduct, plus a requirement that the vendor carry professional indemnity and cyber insurance at a stated minimum so the cap is collectible.
How do you exit a software development contract that is not working?
If the contract has a termination for convenience clause, serve written notice, pay for accepted work and work in progress to the notice date, and invoke the transition assistance clause to receive code, documentation, credentials, environments, and knowledge transfer. If the contract only allows termination for cause, the buyer must prove material breach, which is hard when scope was vague, so negotiation is usually the practical route. This is why termination for convenience and transition assistance should be negotiated before signing, when both sides expect to never need them.
What data protection terms are needed when outsourcing offshore?
A data protection addendum that names the categories of data the vendor may access, requires anonymized or synthetic data for development and testing by default, specifies security controls, records where data may be stored and processed, includes the transfer mechanism the buyer's regime requires (standard contractual clauses under GDPR, for example), sets breach notification within a stated number of hours, and gives the buyer audit rights. Production data copied to a developer's machine in another country is a cross-border transfer whether or not anyone planned it.
For buyers who want the contract terms in this article proposed rather than negotiated, AgileTech is an AI native software development company in Vietnam that assigns IP per invoice and keeps every account in the client's name.
