BOFU Contract Negotiation Guide · 2026

Software Development Contract Redlines: What Founders Miss

The clauses founders should actually redline before signing a custom software contract. IP ownership, change orders, liability caps, source code, indemnity, warranties, exit terms — and the language that turns a fair contract into a trap.

By Bill Beltz, founder of QUANT LAB USA INC · Published May 12, 2026

Quick answer: which clauses must I redline?

Eight clauses every founder should redline: 1) IP ownership (split custom work vs pre-existing IP). 2) Change order process (defined timeline, locked rates). 3) Payment milestones (no 100% upfront, no 100% on delivery). 4) Liability cap with carve-outs for IP infringement and breaches. 5) Mutual indemnification. 6) Non-solicit with buyout. 7) Warranty period (30 to 90 days, defined defect criteria). 8) Exit and transition assistance. The contract should be 15 to 25 pages MSA + 5 to 10 page SOW — anything substantially shorter or longer is a flag.

Software development contracts are where projects go sideways. The RFP and the proposal create alignment; the contract creates the rails. When something breaks downstream — scope creep, missed milestone, ownership dispute — the contract is what you have. Most founders sign too quickly and discover the bad language only after they need it.

We sit on both sides of these contracts. We negotiate as a vendor with mid-market and enterprise clients, and we review draft contracts for founders evaluating us against competitors. This is what we flag. Pair with our RFP template for the front-end of the procurement process.

The MSA + SOW structure

Most modern software development contracts split into two documents:

Master Services Agreement (MSA): The legal framework — IP, liability, indemnity, confidentiality, non-solicit, governing law, termination. Signed once.
Statement of Work (SOW): The specific engagement — scope, deliverables, timeline, pricing, milestones, acceptance criteria. Signed per project.

Negotiate the MSA carefully because it controls every future SOW. Reasonable SOWs do not save you from an unreasonable MSA.

Clause 1: IP ownership

The default vendor template usually says one of:

Work-for-hire to client upon final payment. All IP created flows to the client. Simple but blunt — vendor cannot reuse anything.
License from vendor. Vendor retains ownership; client gets a perpetual license. Cheap-looking but you do not actually own your software.
Hybrid (recommended). Client owns custom business logic and bespoke UI. Vendor retains pre-existing IP and generally reusable utilities, licensed to client perpetually, irrevocably, royalty-free, and worldwide.

Push for hybrid. Define 'pre-existing IP' precisely in an exhibit — usually open-source components, the vendor's internal libraries, and design system components. If a vendor refuses to disclose pre-existing IP, that is its own red flag.

Clause 2: Change order process

Every custom build will have changes. The contract should define the process:

How a change is requested (written, via project management tool, etc.)
Vendor response time (5 business days is common)
Pricing methodology (T&M rates locked at MSA signing, not at change order time)
Approval authority on each side
Threshold below which informal acceptance is fine ($5K to $10K)
What happens if the change order is rejected

Most contract disputes we have seen trace back to a poorly defined change order process — either scope creep ate the budget or scope freeze killed the project.

Clause 3: Payment milestones

Bad patterns:

100% upfront. You lose all leverage. Avoid.
100% on delivery. Vendor takes too much risk; only the desperate will sign. Quality suffers.
Calendar-based milestones (Day 30 = X%, Day 60 = Y%). Detaches payment from progress.

Good pattern: 10 to 25% on signing, 40 to 60% across delivery milestones tied to outcomes, 15 to 25% on final acceptance, with the final tranche tied to a 30 to 60 day warranty period.

Clause 4: Liability cap and carve-outs

Vendor templates typically cap total liability at fees paid in the prior 12 months. Push back where it matters:

Carve out IP infringement. If vendor's deliverable infringes a third-party patent, the cap should not apply.
Carve out confidentiality breaches. Especially for PHI, PCI, or other regulated data.
Carve out gross negligence and willful misconduct. Standard ask, usually granted.
Negotiate a higher floor. "Greater of 12 months fees or $500K" instead of "12 months fees."
Mutual cap. The cap should apply to both sides, not just the vendor.

Clause 5: Indemnification

Mutual indemnification is standard:

Vendor indemnifies client for IP infringement claims arising from deliverables.
Client indemnifies vendor for misuse of deliverables and content client provided.

Tighten the vendor's IP indemnification: cover both direct infringement claims and reasonable defense costs. Add a procurement clause: if a third party claims infringement, the vendor must (at their option and cost) replace the infringing component, secure the right to continue use, or refund proportionally.

Clause 6: Non-solicit and buyout

Mutual 12-month non-solicit clauses are standard. They protect both sides from talent poaching. Enforceability varies by state, but most disputes settle commercially.

Negotiate a buyout clause: a defined liquidated damages amount ($50K to $250K depending on engagement size) if you hire one of the vendor's engineers during or after the term. This converts a hostile situation into a transaction and clears the air.

Clause 7: Warranty

A 30 to 90 day post-acceptance warranty is standard. The vendor fixes material defects free of charge during the period. Define 'material defect' precisely:

A function fails to perform in accordance with the SOW.
The system fails to meet a stated performance target.
A security vulnerability above a defined CVSS threshold is discovered in the vendor's code.

What is not a material defect: cosmetic issues, browser-specific bugs in unsupported browsers, third-party API changes. Without precise definitions, the warranty becomes a debate.

Clause 8: Exit and transition assistance

How the relationship ends is as important as how it starts. Three sub-clauses:

Termination for convenience: Either side may terminate with 30 to 60 day notice. Vendor delivers what is complete; client pays pro-rated fees.
Termination for cause: Material breach with cure rights (typically 30 days to remedy after notice).
Transition assistance: Vendor commits to deliver source code, documentation, deployment instructions, and reasonable handoff support within a defined window (60 to 90 days). Bill at agreed rates if transition exceeds defined hours.

Common contract anti-patterns

Anti-pattern	Why it's bad
Auto-renew with short notice window	Locks you in to a vendor that may underperform
Vendor governing law in a friendly jurisdiction	Disputes resolve far from you
Source code delivered "on request"	Should be delivered continuously to your repo
Vendor reuse rights without disclosure	Your competitive logic could ship to competitors
"Best efforts" without defined outcomes	No teeth on quality
100% upfront payment	All risk on you
Indemnification one-sided in vendor's favor	Mutual is standard

When to walk away

Some contract postures are not redlinable. If a vendor refuses to budge on any of the following, find another vendor:

Refuses any form of IP ownership transfer.
Refuses to share source code during the engagement.
Refuses mutual liability caps.
Refuses any termination for convenience.
Will not name the engineers who will work on the project.
Demands 100% upfront for a multi-month engagement.

FAQ

Should I have a lawyer review a software development contract?

Yes, for any contract above $50K. The right lawyer pays for themselves on the first ambiguous IP clause they catch. Look for tech-focused commercial lawyers; general practitioners often miss the patterns that matter (work-for-hire vs license, change order economics, source code escrow). Expect to pay $1,500 to $5,000 for a clean review on a mid-market MSA + SOW.

Who owns the code in a custom software contract?

The default in most vendor templates is 'work-for-hire to client upon final payment.' That is reasonable for client-specific business logic but a trap for general tooling, libraries, and design system components. Negotiate a hybrid: client owns custom business logic and bespoke UI; vendor retains ownership of pre-existing IP and generally reusable utilities, licensed to client under a perpetual, irrevocable, royalty-free license.

What is a change order and why does it matter?

A change order amends the original SOW when scope shifts. The contract should define: how change orders are requested, the timeline for vendor response (typically 5 business days), how pricing is calculated (T&M rates locked in advance), approval thresholds, and what happens if you reject the change order (status quo or scope drop). Without a clean change order process, you get either scope creep eating the budget or scope freeze blocking real progress.

What is the difference between fixed fee and time and materials?

Fixed fee bills a defined scope at a defined price; you absorb the risk of underestimation and the vendor absorbs the risk of overrun. T&M bills actual hours at agreed rates; you absorb the overrun risk and the vendor absorbs the underestimation risk. Hybrid models (fixed price per milestone with T&M for change orders) are most common for custom builds. Pure T&M without a cap is risky for buyers.

What is source code escrow?

Source code escrow is an arrangement where a third party holds a copy of the source code and releases it to the buyer under defined trigger conditions (vendor bankruptcy, sustained non-performance, refusal to support). Useful for buyers who depend on a SaaS vendor for ongoing operations. For custom build work where you already get the source code on each deploy, escrow is usually unnecessary.

What liability cap should I negotiate?

Vendor templates typically cap liability at fees paid in the prior 12 months. Push for the greater of 12 months fees or a fixed floor ($250K to $1M) for material breaches. Carve out from the cap: confidentiality breaches, IP infringement, gross negligence, willful misconduct. Anything related to a data breach should usually be uncapped or higher-capped.

Do I need indemnification clauses?

Yes — mutual indemnification is standard. The vendor indemnifies you for IP infringement claims arising from their deliverables. You indemnify the vendor for misuse of the deliverables and for content you provide. Tighten the IP indemnification to cover both direct infringement and reasonable defense costs. Add a procurement clause: if a third party claims infringement, the vendor must replace, rework, or refund.

What is a non-solicit clause and is it enforceable?

A non-solicit prevents you from hiring the vendor's employees (and vice versa). Mutual 12-month non-solicit clauses are standard. Enforceability varies by state — in California, employee non-solicits are largely unenforceable; in Georgia, they are enforceable if narrowly tailored. Most disputes resolve commercially before litigation. Negotiate a buyout clause: $X paid as liquidated damages if you hire their engineer.

Should I require a SOC 2 or pentest report from my vendor?

If the vendor will touch production data, yes. SOC 2 Type II report under NDA, or an equivalent attestation. If the vendor is small and pre-SOC-2, ask for their most recent pentest report and security policy documents. Build the security review into the procurement process before signing.

What is the right payment milestone structure?

Avoid 100% up front (you lose all leverage) and avoid 100% on delivery (the vendor takes all the risk). Standard milestones: 10 to 25% on signing, 40 to 60% across delivery milestones, 15 to 25% on final acceptance, with the final tranche tied to a 30 to 60 day warranty period. Tie milestones to outcomes, not calendar dates.

How do I write a clean exit clause?

Three things must be in writing: 1) Termination for convenience with 30 to 60 day notice and pro-rated fees. 2) Termination for cause with cure rights (typically 30 days). 3) Transition assistance — the vendor commits to deliver source code, documentation, and reasonable handoff effort within a defined window after termination. Without transition assistance, you can end up locked out of your own systems.

What should the warranty period look like?

30 to 90 days post-acceptance is standard. The vendor fixes material defects free of charge during the warranty period. After warranty, defects fall under a separately-priced support agreement. Define 'material defect' precisely — a function fails to perform per spec vs cosmetic issue. Otherwise, the warranty becomes a debate about what is in scope.

Need a contract gut-check?

Free 30-minute MSA + SOW review. Send us your draft and we will mark up the clauses we would fight on. Not legal advice — but it is the engineering perspective on what to negotiate.

Or call Bill at (770) 652-1282