Software development contract checklist: what to agree before you sign

Key points

• Scope, change requests and acceptance criteria decide most disputes. Make them specific.
• Ownership needs a signed assignment of intellectual property, plus the code and accounts in your own name.
• If the developer will touch personal data, data protection law may require particular contract terms.
• Agree what happens at the end, including an early end: what is handed over, in what form, and with what help.
• Liability, dispute resolution and governing law should be chosen on purpose, not left to boilerplate.
• This is general information with examples from several countries. A lawyer where you are should review the contract.

How software development contracts are put together

Many agencies use two documents. A master services agreement sets the legal terms that apply to all work: ownership, confidentiality, liability, termination and disputes. A statement of work, sometimes called an order or a schedule, describes one piece of work: the scope, deliverables, milestones and how the work is charged. Smaller projects often combine both in one contract.

Check which document wins when they disagree. A common and sensible order is that the master agreement wins on legal terms, and the statement of work wins on what is being built. Also check that nothing important lives only in a proposal, an email or a website’s terms that the contract does not mention.

This is not legal advice. Contract law, copyright and data protection differ by country, and the examples below from the US, the UK, the EU and India are there to show why the wording matters, not to tell you what applies to you. Ask a lawyer where you are to review the contract, and check the regulator’s own guidance for your situation.

Scope, change requests and acceptance

Most disagreements between a client and a development team are about what was agreed, not about the law. Three clauses do most of the work.

• Scope. Good: a list of features, screens or user stories, an explicit list of what is out of scope, and the assumptions behind it, such as which integrations and platforms are included. Red flag: “build an app as discussed”, or a scope that points to a document nobody attached.
• Change requests. Good: a written process where either side can propose a change, the team says what it does to effort and order of work, and nothing changes until you approve it. Red flag: changes agreed in chat and argued about at the end, or no process at all.
• Acceptance. Good: criteria you can test, a set period for you to review each deliverable, a way to report what fails, and a rule for what counts as accepted. Red flag: work deemed accepted the moment it is delivered, or acceptance based on the team’s opinion that it is finished.

If the contract ties payment milestones to deliverables, tie them to accepted deliverables, not to dates or to effort spent. How much of this you can fix in advance depends on the model you choose; Dedicated team vs fixed scope explains how each handles change.

Ownership: intellectual property, source code and accounts

In many countries the person who writes the code owns its copyright unless it is transferred in writing, even when you commissioned and funded the work. The UK’s Intellectual Property Office says the creator of a commissioned work is its first owner unless agreed otherwise in writing. US law says a transfer of copyright is not valid unless it is in writing and signed by the owner. India’s Copyright Act also requires a written assignment that identifies the work and the rights.

• IP assignment. Good: all rights in everything made for you, including code, designs, documentation and tests, assigned to your company, with a clear moment when ownership passes. Red flag: the agency keeps ownership and gives you a license, or the contract only says “work made for hire” and stops there.
• Pre-existing materials. Good: the team keeps its own reusable tools, and you get a permanent license to use and change them as part of your product, which survives the end of the contract. Red flag: a license that ends when the relationship ends.
• Open source. Good: a list of open-source components and their licenses delivered with the code, and your approval needed before adding copyleft code. Red flag: no mention at all.
• Source code. Good: the code lives in a repository your company owns, from the first commit. Red flag: you receive the code only at the end, or only on request.
• Accounts. Good: cloud hosting, domain, app store developer accounts and third-party services opened in your company’s name, with the team added as users. Red flag: the developer holds the accounts and “will transfer them later”.

Who owns the code goes through the copyright rules and the accounts in more detail.

Confidentiality and data protection

• Confidentiality. Good: it covers your product plans, business information, code and data, binds everyone the team brings in, and lasts beyond the end of the contract. Red flag: it protects only the agency’s information, or ends when the project does.
• Data protection. If the team will access personal data, such as your users’ records, the law may require specific terms. Under the UK and EU GDPR, a processor working for you needs a written contract that covers, among other things, acting only on your documented instructions, confidentiality, security, the use of sub-processors, helping with people’s data rights, what happens to the data at the end, and audits. The UK regulator, the ICO, lists these terms, and the European Commission publishes standard clauses that can be used for them.
• Red flags: no data clause on a project that clearly handles personal data, or a team that cannot say where the data will be stored and who else can reach it.

Other countries have their own data protection laws with their own contract rules. Ask your lawyer which apply to your users, not only to your company.

Warranty and defect fixing

Software ships with defects. The question is who fixes them, and on what terms. The USDS Digital Services Playbook, written for US government buyers, recommends that a contract specify a warranty period in which the vendor fixes defects at no extra cost. Private buyers can ask for the same.

• Good: a warranty period after acceptance, a definition of a defect as behavior that does not match the agreed scope or acceptance criteria, severity levels, and how quickly each level is acknowledged.
• Good: a clear line between a defect, which the team fixes, and a change, which goes through change requests.
• Good: ongoing support and maintenance agreed separately, so it is clear what happens after the warranty ends.
• Red flags: “as is” with no warranty at all, a warranty that is void if anyone else touches the code, or one that covers only defects reported in a form nobody told you about.

Termination and handover

• Termination. Good: either side can end the contract with written notice, and either can end it sooner for a serious breach that is not fixed. It says what is owed for work done up to that point. Red flag: only the agency can end it early, or ending it costs you the rights to work already delivered and settled.
• Handover. Good: on any ending, the team delivers the full source code, documentation, build and deployment steps, credentials and access, and a reasonable amount of help for the next team. The Digital Services Playbook asks for a transition-out plan for this reason. Red flag: no handover clause, or handover only if the contract ends in the agency’s favor.
• Survival. Good: the IP assignment, licenses, confidentiality and handover duties continue after the contract ends. Red flag: everything ends on the same day.

If you are already ending a project, Freelancer project handover has the step-by-step version.

Liability, disputes and governing law

• Liability. Most contracts cap what either side can claim from the other and exclude indirect losses such as lost profits. That is normal. Check that the cap applies to both sides, and whether breaches of confidentiality, data protection or IP rights sit outside it. Red flag: a cap that applies only to the agency, or one so low it makes the other promises meaningless. Ask what insurance the team holds.
• Disputes. Good: a ladder, starting with senior people from both sides talking, then mediation, then arbitration or court. In mediation, a neutral person helps both sides reach a settlement but cannot impose one. Arbitration gives a binding decision, and the New York Convention requires its member states to recognize and enforce foreign arbitral awards, which helps when the two sides are in different countries.
• Governing law and forum. Good: one named country’s law, and courts or an arbitration seat that match it. The Hague Choice of Court Convention exists to make these clauses effective between businesses in international deals, among the countries that have joined it. Red flag: a law and a forum that are both far from you and convenient only for the other side, or no choice at all.

Cross-border work is normal now, so these clauses matter even for small projects. A lawyer in your country can tell you whether a decision made under the chosen law and forum can be enforced where the other side is.

The checklist

The same points are worth raising before the contract stage, when you compare teams; How to choose a software development company has the questions.

At BYD Tech the code lives in the client’s GitHub from day one and IP is assigned to the client. We price by the project or by the week, never by the hour, with a written estimate after scoping. MVP development explains how a first version starts.