Short answer: a software development agreement should cover twelve areas: scope and acceptance, IP assignment, pre-existing and third-party components, confidentiality, payment milestones, change control, warranty, termination and handover, liability, data protection, non-solicitation, and governing law. For each, the question to ask is the same: if this goes wrong, what does the document say happens next?
This is not legal advice. BBR is a software studio, not a law firm. This checklist describes what development contracts commonly contain, written from experience on the vendor's side of the table, so that you can read a draft critically. Contract law differs between the US, UK, Canada, Australia and elsewhere, and between states and provinces. Have a qualified lawyer in your jurisdiction review any agreement before you sign it.
How these contracts are usually structured
Most engagements use two documents. A master services agreement (MSA) holds the legal terms. A statement of work (SOW) describes the specific project: features, acceptance criteria, timeline, price and payment schedule. Founders tend to read the SOW carefully and skim the MSA. Read both, and check which one wins if they conflict; the contract should say.
The overview of how outsourced development engagements are set up explains where the contract fits in the wider process. This page goes clause by clause.
1. Scope and acceptance
Why it matters. Most disputes are about whether something was included and whether it is finished. Both are answered here or nowhere.
What to look for.
- Features written as testable behavior, not nouns. "A customer can cancel a booking up to 24 hours before and receives an email confirmation" can be accepted or rejected. "Booking management" cannot.
- A list of deliverables beyond code: designs, documentation, deployment, store submission, test accounts.
- Written exclusions and assumptions, such as "client provides API access to the accounting system by week two".
- An acceptance procedure: how many working days you have to review a milestone, how defects are reported, how many review rounds are included, and what happens if you do not respond. Many contracts include deemed acceptance after a period of silence; make sure the period is one you can meet.
- Your own obligations: feedback deadlines, content, access, a named decision-maker.
A strong scope usually starts from a strong brief. The project brief template shows how to describe features so they can later become acceptance criteria.
2. Intellectual property assignment
Why it matters. In many jurisdictions an independent contractor keeps the copyright in what they create unless it is assigned in writing. Paying for the work does not, by itself, necessarily make it yours. Investors and acquirers will check this.
What to look for.
- An express assignment to your company of everything created for the project: source code, designs, documentation, data models, test suites.
- A stated moment of transfer: on payment of each milestone, or on final payment. Per milestone protects you better if the project stops early.
- A warranty that the vendor's employees and subcontractors have assigned their rights to the vendor, so the vendor has them to pass on.
- An obligation to sign further documents if needed to perfect the assignment.
- A warranty that the deliverables do not knowingly infringe anyone else's rights.
- Whether the vendor may show the work in a portfolio, and whether that needs your consent.
The right wording depends on governing law. Some countries treat moral rights, "work made for hire" language and future assignments differently. This clause deserves your lawyer's closest attention.
3. Pre-existing and third-party components
Why it matters. Almost no product is written entirely from scratch. It will contain open-source libraries, possibly the vendor's own reusable code, and paid third-party services. None of those can be assigned to you, so the contract has to say what rights you get instead.
What to look for.
- Vendor background IP identified, with a perpetual, worldwide, royalty-free licence for you to use, modify and have others maintain it as part of the product. Without the last part, a future team may not be allowed to touch it.
- Open-source components listed or available on request, with a commitment not to use licences that would oblige you to publish your own source code unless you agree in advance.
- Paid services (hosting, maps, email, AI APIs) registered in your name, with you as the account holder and payer.
- Purchased assets such as fonts, icons, stock media and templates licensed to your company, not the vendor.
- No proprietary platform that only the vendor can host or deploy, unless you have chosen that knowingly.
4. Confidentiality
Why it matters. The vendor will see your plans, your data and often your customers' data.
What to look for.
- Mutual obligations; the vendor's methods and pricing are confidential too.
- A sensible definition of confidential information with the standard exceptions (already public, independently developed, required by law).
- Obligations that extend to the vendor's staff and subcontractors.
- A duration that outlives the contract, commonly a fixed number of years, longer for trade secrets.
- Return or deletion of materials at the end.
- If a separate NDA was signed earlier, a statement of which document governs from now on.
5. Payment milestones
Why it matters. The payment schedule is your main practical protection, more than any remedy clause. If neither side is ever far ahead of the other, a breakdown is survivable.
What to look for.
- Payments tied to deliverables you can inspect on a staging environment, not to dates.
- A deposit that reserves the team without prepaying a large share of the project.
- A meaningful final payment linked to launch and handover, so both sides want to finish.
- Currency, invoicing method, payment terms in days, who bears bank and transfer fees, and how taxes are treated. Cross-border tax treatment is a question for your accountant.
- Late payment consequences that are proportionate: interest or a right to pause work after notice, not immediate termination.
- For time and materials work: rates by role, how time is recorded and reported, any cap, and how often rates can change.
How the payment structure differs between pricing models is covered in fixed price or time and materials.
6. Change control
Why it matters. Requirements will change. A contract without a change procedure turns every change into a negotiation about the whole deal.
What to look for.
- A written procedure: request, estimate of cost and schedule impact, your written approval, then work.
- No work on unapproved changes, and no obligation to pay for it.
- Whether estimating a change is free or billable.
- The option to swap items of similar size at no charge, if the vendor offers it.
- Approved changes appended to the SOW, so acceptance always has one reference.
7. Warranty and bug-fix period
Why it matters. Some defects only appear under real use. You want them fixed without an argument about who pays.
What to look for.
- A defined period after acceptance or launch during which defects are corrected at no charge. Lengths vary; 30 to 90 days is a common range.
- A definition of defect: behavior that contradicts the agreed acceptance criteria. Behavior you now want to be different is a change.
- Severity levels and response expectations, at least for problems that stop the product from working.
- Reasonable exclusions: problems caused by your own modifications, third-party outages, or operating system and browser versions released later.
- A clear boundary between warranty and paid maintenance. Dependency updates, OS changes and new store requirements are maintenance; budget for them using the guide to what maintenance costs after launch.
8. Termination and handover
Why it matters. This clause decides whether "no lock-in" is real. Read it as if you were already in a dispute.
What to look for.
- Termination for convenience by either side with a notice period, not only termination for breach.
- Termination for material breach with a cure period.
- On termination: you pay for accepted work and a fair amount for work in progress, and you receive all of it, including unfinished code, designs and documentation.
- A handover checklist: repository with full history, credentials and secrets, environment configuration, build and deployment instructions, database schema and backups, design source files, third-party account transfers.
- A defined number of transition hours at the normal rate to brief a successor team.
- Which clauses survive termination: IP, confidentiality, payment for work done, liability.
- Continuous repository access during the project, so that handover is a formality. If the code is pushed to a repository your company owns from the first day, this clause becomes much less important.
What happens when this clause is missing is described in the guide to taking over an unfinished software project.
9. Liability
Why it matters. It sets the financial ceiling if something goes badly wrong, in both directions.
What to look for.
- A cap on each party's liability, commonly linked to the fees paid or payable under the contract. A small studio cannot credibly accept unlimited liability, and a contract that pretends otherwise gives you a claim you could never collect.
- Exclusion of indirect and consequential losses such as lost profits, usually mutual.
- Carve-outs from the cap for the things that matter most: breach of confidentiality, IP infringement indemnity, deliberate misconduct. Which carve-outs are enforceable varies by law.
- Indemnities in both directions: the vendor for infringement in what it creates, you for the content and materials you supply.
- Whether the vendor carries professional indemnity or similar insurance, if your project warrants it.
10. Data protection
Why it matters. If the vendor can access personal data about your users, privacy law in your users' location may require specific contract terms, and you remain responsible for your vendor's handling of it.
What to look for.
- A statement of whether the vendor will process personal data at all. The simplest compliance measure is to build and test with synthetic data and keep the vendor out of production data.
- If it will: a data processing agreement or equivalent terms covering purpose, security measures, sub-processors, breach notification, international transfers, and deletion at the end.
- Access on a least-privilege basis, removed when the engagement ends.
- Any sector rules that apply to you (health, finance, children, education) stated as requirements in the scope, since they affect engineering effort as well as paperwork.
Which regimes apply (GDPR, UK GDPR, US state laws, PIPEDA, the Australian Privacy Act or others) depends on where your users are. The pages for US, UK, Canadian and Australian clients outline the considerations when working with BBR from each country. Your lawyer should confirm what your product needs.
11. Non-solicitation
Why it matters. Vendors include it so that clients do not hire away the engineers they have trained. It matters to you if your long-term plan is to build an in-house team.
What to look for.
- Mutual application and a limited duration, commonly 12 months after the engagement.
- Scope limited to people who actually worked on the project.
- An exception for responses to general job advertisements.
- If you may want to hire someone from the team later, an agreed conversion fee is cleaner than a prohibition.
- No non-compete that would stop you from working with other vendors. Be cautious, too, about demanding that the vendor never work for anyone in your industry; it is rarely accepted and the confidentiality clause usually protects what you care about.
The enforceability of these restrictions varies widely by jurisdiction.
12. Governing law and disputes
Why it matters. It decides which country's or state's rules interpret everything above, and where a dispute would be heard.
What to look for.
- A named governing law and a named forum, whether courts or arbitration, plus the seat and language of any arbitration.
- An escalation step before formal proceedings: senior-level negotiation, then mediation.
- With an overseas vendor, a realistic view of enforcement. A judgment in your home court may be difficult to enforce abroad; arbitration awards are often easier to enforce internationally. This is a point to ask your lawyer about directly.
- Housekeeping clauses: how notices are given, whether the vendor may subcontract or assign the contract, force majeure, and entire-agreement wording that may override promises made in emails or proposals. If a promise matters, make sure it is in the contract itself.
Summary checklist
- Scope is written as testable behavior, with exclusions, assumptions and your own obligations listed
- Acceptance procedure has review periods you can meet and a clear defect process
- All project work is assigned to your company in writing, with a stated moment of transfer
- Vendor warrants that employees and subcontractors have assigned their rights
- Vendor background code is licensed perpetually, including the right for others to maintain it
- Open-source licences are disclosed; paid services and assets are in your company's name
- Confidentiality is mutual, covers subcontractors and survives the contract
- Payments follow inspectable deliverables; deposit is modest; final payment is tied to handover
- Changes require a written estimate and your written approval before work starts
- Warranty period is defined, with a definition that separates defects from changes
- Either side can terminate with notice; you receive everything produced to date
- Handover contents are listed: repository, credentials, deployment instructions, design files, account transfers
- Liability cap, exclusions and carve-outs are stated and balanced
- Data protection terms match the data the vendor will really touch
- Non-solicitation is mutual, time-limited and does not block your hiring plans
- Governing law, forum and escalation steps are named
- Repository, hosting, domains and store accounts are owned by your company from day one
- A lawyer in your jurisdiction has reviewed the final draft
What a contract cannot do for you
A contract allocates risk; it does not remove it. Two founders with identical contracts get very different outcomes depending on whether they hold their own accounts, see working software every one to two weeks, and have someone independent look at the code occasionally. Treat the agreement as the fallback and those habits as the first line of defense.
It also pays to discuss these clauses before the draft arrives. How a vendor reacts to questions about ownership, handover and termination tells you a good deal, and the due-diligence questions for agencies include what reasonable answers sound like. BBR's own position on code ownership, third-party components, NDAs and handover is set out on the how we work page, with ownership and licences agreed in each project contract. The projects this applies to are described under custom software development.