Software development contract checklist: IP, source code and escrow

If you pay for software, you don't automatically own it. A plain-language checklist of the clauses that matter when you commission custom software, from code ownership to escrow.

A software development contract sets out what's being built, what it costs, who owns the result, and what happens when things change or go wrong. Most business owners skim it, sign it, and only read it properly when there's a dispute. This checklist covers the clauses that matter most to a business commissioning custom software, especially who owns the code. It's written in plain language, so you know what to look for and what to ask your lawyer.

This is general information, not legal advice. Laws differ between countries. Have a lawyer review any contract that matters to your business.

Why ownership needs to be written down

Many business owners assume that if they pay for software, they own it. The law in many countries says otherwise unless the contract says so.

• In the United States, a commissioned work only counts as a "work made for hire", owned by the client, if it falls into one of nine specific categories listed in the Copyright Act and both parties sign a written agreement saying so. (US Copyright Office, Circular 30) Custom business software often doesn't fit neatly into those categories, which is why contracts usually also include an explicit assignment of copyright to the client.
• In the United Kingdom, the Copyright, Designs and Patents Act 1988 says the author of a work is the first owner of the copyright, with an exception for work made by an employee in the course of their employment, which belongs to the employer. (legislation.gov.uk) An outside developer or agency isn't your employee, so without an assignment in the contract, they may own the copyright in code you paid for.

Other countries have their own rules. The safe approach everywhere is the same: say clearly, in writing, that ownership transfers to you.

The checklist

1. Parties and scope

• The right legal entities are named on both sides.
• The scope is written down, ideally in an attached specification or statement of work. Our requirements document template helps.
• What's excluded is listed, as well as what's included.
• Assumptions the price depends on are stated, such as the systems it connects to and the data provided by you.

2. Price and payment

• Pricing model is clear: fixed price, time and materials, or a mix. See fixed price vs time and materials.
• Payments are tied to milestones you can see and test, not just dates.
• Expenses and third-party costs, like hosting, licences and paid APIs, are listed, along with who pays them.
• Under time and materials, there's a cap or a notice point before the budget is exceeded.

3. Changes

• A simple change process: who can request changes, how they're priced, and that nothing is built until the price and timeline impact are agreed in writing.

4. Acceptance

• "Done" is defined: the tests or criteria each milestone must pass.
• A review period for you to test each delivery, and what happens if it fails.

5. Intellectual property and ownership

• Copyright in the custom code is assigned to you, on payment or progressively as each milestone is paid. In the US, use "work made for hire" language where it applies, plus an assignment as a backstop.
• Pre-existing and third-party components are dealt with. Builders reuse their own libraries and open-source code. You should get a permanent, royalty-free licence to use anything you don't own outright, as part of your software.
• Open-source licences are disclosed for anything significant, so you know your obligations.
• No restriction on who maintains it later. You can have any developer work on the code.

6. Access to code, accounts and data

• The code lives in a repository you own, such as a GitHub or GitLab account in your business's name, or is delivered to you regularly.
• Hosting, domains, app store and third-party accounts are in your name, or transferred to you on request.
• Your data is yours, can be exported in a usable format at any time, and is returned or deleted when the relationship ends.
• Documentation is part of the deliverable: how to run, deploy and maintain the system.

7. Confidentiality and data protection

• Mutual confidentiality for business information shared during the project.
• Data protection terms if the builder handles personal data: what they can do with it, security measures, sub-processors, and breach notification.
• AI tools: whether your data or code may be sent to AI providers, and on what terms.

8. Warranties and fixes

• A fix period after launch, during which defects against the agreed scope are fixed at no cost.
• What counts as a defect, as opposed to a change.
• No known malicious code, and the builder has the right to grant what they're granting.

9. Support after launch

• What support is available after the fix period, how it's priced, and response times.
• Hosting and maintenance responsibilities: security updates, backups, monitoring.

10. Liability

• A sensible cap on liability on both sides, often linked to the contract value, with the usual exclusions your lawyer will advise on.

11. Ending the contract

• How either side can end it, and the notice required.
• What you get if it ends early: the code and work-in-progress paid for so far, documentation, and help handing over to someone else.
• No exit fees for retrieving your own code or data.

12. Source code escrow (when the supplier keeps the code)

If you're licensing software the supplier owns, rather than commissioning software you'll own, consider escrow. An independent escrow agent holds a copy of the source code and releases it to you on agreed events, typically the supplier's insolvency or failure to maintain the software. (Pinsent Masons, Out-Law guide to escrow) Ask for the deposit to be verified, so you know the code held in escrow can actually be built into a working system. When you own the code and it lives in your repository, escrow is usually unnecessary.

Red flags in a software contract

• "The supplier retains all intellectual property", with you getting only a licence, for software built specifically for you.
• Code and hosting only in the supplier's accounts.
• No written scope, or a scope of one paragraph.
• Payment mostly up front, not tied to working software.
• Changes billed at undefined rates.
• Exit fees, or no mention of what you receive if the contract ends.
• Unlimited liability for you, nothing for them.

Connecting your tools safely

If your project connects to the tools you already use, like your CRM, accounting package or payment provider, the contract should also cover:

• Whose API keys and accounts are used: yours, ideally.
• What data passes through the integration, and where it's stored.
• Who maintains the connection when one of those products changes its API.

How we contract at Lephlo

Our own terms cover the core of this checklist. You get a written scope with exclusions and a fixed price for it, and changes are priced before we do them. Once you've paid in full, you own the custom code and other deliverables we created for you, with no licence fees and no lock-in. Open-source and existing components stay with their owners, and you get the right to use them as part of your software. Fixes are free during the fix period after launch, and ongoing support is available through monthly care plans.

We build internal tools, customer portals and integrations that connect to the tools you already use. Read our terms, or see why Lephlo. To size a first version, try the Build Scope Planner, or book a free consultation.

Frequently asked questions

Do I automatically own software I pay a developer to build? Not necessarily. In both the US and the UK, an outside developer may own the copyright unless the contract assigns it to you or, in the US, it qualifies as a work made for hire under a written agreement. Make ownership explicit.

What is the difference between assignment and licence? An assignment transfers ownership of the copyright to you. A licence only gives you permission to use something the other party still owns.

What is source code escrow? An arrangement where an independent agent holds a copy of software source code and releases it to the customer on agreed events, such as the supplier's insolvency.

Do I need a lawyer to review a software contract? For anything your business depends on, yes. This checklist helps you ask the right questions and spot gaps before the lawyer's review.

Sources

• US Copyright Office, Circular 30: Works Made for Hire
• Copyright, Designs and Patents Act 1988, section 11
• Pinsent Masons, Out-Law guide: Escrow