Insights · 11 min read
The clauses that decide who owns the code, who carries the risk, and when you actually pay. A plain-English guide to software development contracts and SOWs.
By GGP Editorial
Most outsourcing problems are not really engineering problems. They are contract problems. A project that runs months late, a bill that doubles, or a product you paid for but cannot get the source code for: each one traces back to a clause nobody read, or a clause that was never there. The contract is the last moment to fix the relationship before money moves, and most people skim it.
This guide covers the clauses that decide who owns the code, who carries the risk, and when you actually pay. It is general guidance, not legal advice. For the IP, liability, and jurisdiction terms, have a lawyer review the final draft before you sign.
A software development contract is the agreement that turns a proposal into an obligation. It sets out what gets built, who owns the result, how and when you pay, and who is responsible when something goes wrong. It goes by a few names: software development agreement, software development services agreement, master services agreement (MSA). They all do the same job.
Most custom and offshore builds are structured as two documents. The MSA holds the standing terms that apply to every project: IP ownership, confidentiality, liability, termination. The statement of work (SOW) holds the specifics of this project: scope, deliverables, milestones, price, timeline. One MSA can sit over many SOWs, which is why the SOW is the part to read line by line each time.
| Document | What it covers |
|---|---|
| Master services agreement | IP ownership, confidentiality, warranties, liability cap, termination, dispute resolution |
| Statement of work | Scope, out-of-scope items, deliverables, acceptance criteria, milestones, price, timeline |
This is the clause people skim and regret later. Paying for software does not automatically make it yours. Ownership does not pass just because you wrote a check. If the contract is silent on IP, the developer usually keeps it, which means you cannot modify, sell, or even legally move the code without their permission.
A good contract does two things. First, it includes a work-made-for-hire provision, stating the code is created for you from the start. Second, and more important, it includes an explicit assignment: the developer irrevocably assigns all right, title, and interest in the deliverables to you, usually on full payment. The assignment is what holds up, because "work made for hire" is narrower under US law than people assume.
Then separate the three kinds of code so nothing is ambiguous:
If a vendor hesitates on any of this, treat it as a serious warning. Source code ownership is a settled, standard term, the kind of thing to confirm before you hire a software development company, not negotiate after you have already paid.
Most contract fights are really scope fights. The scope of work is where you define the product in enough detail that completion is a matter of checking, not arguing. If the scope says "a complete platform," you and the vendor will both be right and both be angry by the end.
A usable scope lists features screen by screen, names the integrations, states the platforms, and says what is out of scope. The out-of-scope list is not pedantry. It is the line that decides what costs extra later. If you already have a requirements document, paste its feature list into the SOW. If you ran a formal procurement, your RFP already forced most of this into writing.
Then add change control. Requirements will move during the build, and that is normal. The problem is when they move verbally and the invoice moves with them. A change-control clause says every scope change goes through a written change order: what changes, what it costs, what it does to the timeline, and both parties sign before work starts. No signed change order, no new work, no new charge.
How you pay is how you control risk. The safest structure is milestone-based, where each payment is released against a deliverable you have accepted, not against a date on the calendar.
Here is a common pattern for a mid-sized build. The percentages are negotiable; the shape matters more than the numbers.
| Milestone | Deliverable | Acceptance test | Typical payment |
|---|---|---|---|
| Kickoff | Signed SOW, environment access, project plan | Plan reviewed and approved | 10–15% |
| Milestone 1 | Core backend, auth, data model | Features live on staging, tests passing | 25% |
| Milestone 2 | Full feature set, integrations | Demo against acceptance checklist | 30% |
| Final delivery | QA-passed build, source code, docs | UAT sign-off, defects triaged | 20–25% |
| Warranty release | End of defect-fix period | No open critical or high defects | 5–10% holdback |
The details that make this work are the acceptance criteria and the review window. Acceptance criteria are the objective test that says "this is done": which tests pass, which screens work, what the data model looks like. The review window is how long you have to test a milestone and either accept it or send back a written list of defects, usually around ten business days, with a rule for what happens if you go silent. Deemed acceptance keeps the project moving, but you should not rely on it as a way to avoid testing.
The holdback is worth insisting on. A final 5–10% held until the warranty period closes is what keeps the last defects on the vendor's list after launch.
The contract should also name the pricing model, because it changes how you read everything else. Fixed price versus time and materials is a real decision, not boilerplate. Fixed price suits a small, well-defined scope where you can freeze requirements. Time and materials suits a product that will evolve. A dedicated team suits a long roadmap with an evolving backlog.
Beyond the model, get the mechanics in writing: currency, invoice terms (Net 15 or Net 30 is standard), what happens on late payment, and whether the vendor can suspend work. Make sure the termination clause says you pay for work completed and accepted to date, not a penalty for leaving. A clean exit clause is what lets you walk away from a failing vendor without losing the code you already paid for.
Three clauses round out the protection, and they are easy to get wrong by ignoring them.
A warranty period is a defined window after launch, typically 30 to 90 days, where the vendor fixes defects at no charge. Put it in writing, along with the path from there into ongoing maintenance.
A confidentiality clause should cover your idea, your business data, and your customers' information, and it should survive the end of the contract. If you are sharing anything sensitive before signing, ask for an NDA up front. That is a standard request for any serious vendor.
Liability is where you read carefully. A limitation of liability clause caps each side's financial exposure, usually at some multiple of the fees paid. That is normal and reasonable. What is not reasonable is unlimited liability on your side, or an indemnification clause that makes you responsible for the vendor's IP infringement. Make the cap mutual and make the vendor responsible for code they claim is original.
Some clauses should stop you outright. When you see more than one of these, slow down.
None of this is fatal on its own, but they compound. A contract that is vague about the code, the money, and the exit is vague for a reason.
Before you sign, the SOW should answer these questions without you having to ask:
If the SOW answers all eight, most of the relationship risk is already handled. If it answers four, you are negotiating at the wrong stage.
The goal is not to squeeze the vendor. The goal is to remove the ambiguities that turn a good team into an adversary.
Put numbers on anything vague. "Reasonable support" becomes a response time. "Regular updates" becomes a weekly demo and a milestone cadence. Ambiguity that sounds friendly on a sales call is expensive in a dispute.
Let the vendor draft, but read their draft against this list and mark the gaps. Run the IP, liability, and jurisdiction terms past your own lawyer. That is money well spent relative to the size of the build. If you asked the right discovery questions before proposals, the contract should be a formality, not a fight.
Not automatically. Ownership passes only through a written assignment, ideally backed by a work-made-for-hire provision. If the contract is silent, the developer usually keeps the IP. Confirm the assignment clause in writing before you sign.
The MSA holds the standing terms: IP, confidentiality, liability, termination. The SOW holds the specifics of one project: scope, deliverables, milestones, price. One MSA can cover many SOWs.
A final holdback of 5–10% until the warranty period closes is common and worth insisting on. It keeps the last defects on the vendor's list after launch. The exact number is negotiable.
Either works, as long as you read the vendor's template against this list and mark every gap. The vendor's template is a starting point, not the final word. The IP, liability, and jurisdiction clauses are the ones to have a lawyer review.
A clean exit clause says you pay for work completed and accepted to date, and the vendor hands over all completed work and source code. Get that in writing, because it is what lets you leave a failing vendor without losing the code.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, AI products, FinTech systems, ERP and CRM, and SaaS platforms on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. We work across time zones in English and Portuguese, and we are happy to put scope, milestones, and IP ownership in writing before any money moves.
If you are planning a software project and want to talk through scope, milestones, and a realistic budget with an engineering team before you commit, talk to us about your project.
Tell us what you are building and where you are today. We typically reply within 24 hours.
