- Under Canadian copyright law, the general default rule is that the person who actually creates a work owns the copyright in it, unless they created it as an employee acting within the…
- Scope creep is one of the most common sources of dispute in custom development relationships.
- Ask for a warranty period after delivery during which the developer will fix defects at no additional cost, distinct from paid ongoing maintenance or new feature work.
Hiring a developer or a development shop to build custom software — an internal tool, a customer-facing app, a platform your business will run on — is a significant commitment, and the contract you sign shapes who actually owns what gets built. A surprising number of businesses discover only after the fact that they don't own the source code they paid for.
Here is what to negotiate before work begins, not after a dispute starts.
Start With Intellectual Property Ownership
This is the single most important — and most commonly mishandled — term in a custom development agreement. Under Canadian copyright law, the general default rule is that the person who actually creates a work owns the copyright in it, unless they created it as an employee acting within the scope of their employment. An independent contractor developer is not your employee, which means that without an explicit written assignment clause, the developer may own the copyright in the code they wrote for you — even though you paid for it.
A well-drafted agreement should:
- Include a clear, present-tense assignment of all intellectual property in the deliverables to your business, not just a licence to use it
- Address moral rights — under Canadian copyright law these cannot be assigned, only waived, so the agreement should include an explicit waiver
- Clarify ownership of any pre-existing tools, libraries, or frameworks the developer brings to the project versus what is created specifically for you
- Address what happens to any open-source components the developer chooses to incorporate
Scope, Deliverables, and Change Management
| Term | What It Should Address |
|---|---|
| Statement of work | A description of what is being built, detailed enough to judge whether it was actually delivered |
| Milestones and payment | Payment tied to defined, verifiable deliverables rather than time elapsed |
| Acceptance testing | A defined process and timeline for you to test and either accept or reject each deliverable |
| Change orders | A formal process for adding, removing, or modifying scope mid-project, including how it affects price and timeline |
| Source code delivery | Confirmation that you receive the actual source code and documentation, not just a compiled or hosted application |
Scope creep is one of the most common sources of dispute in custom development relationships. A change-order process that requires written agreement before new work begins — rather than assuming everything discussed in a call is now "in scope" — protects both sides.
Warranties and Post-Delivery Support
Ask for a warranty period after delivery during which the developer will fix defects at no additional cost, distinct from paid ongoing maintenance or new feature work. Be specific about what counts as a "defect" (the software doesn't do what the specification said) versus a change request (you want it to do something new).
Confidentiality and Data Handling
If the developer will have access to your business's confidential information, customer data, or systems during the project, the agreement should include confidentiality obligations that survive after the engagement ends, and — if personal information is involved — commitments consistent with your own obligations under federal privacy law (PIPEDA).
Liability and Insurance
Development agreements commonly include a cap on the developer's liability (often tied to fees paid) and exclusions for indirect or consequential damages. Consider whether that cap is appropriate given what the software will actually do — a cap that makes sense for a marketing website may be inadequate for software that will process payments or handle sensitive data. For higher-stakes projects, consider requiring the developer to carry professional liability (errors and omissions) insurance.
Termination
Address what happens if either side wants to end the engagement early: what work product and source code you're entitled to for work already paid for, whether there's a wind-down or transition period, and whether the IP assignment clause survives termination — it should.
Frequently asked questions
If I paid for the software, don't I automatically own it?
Not necessarily. Payment alone doesn't transfer copyright ownership under Canadian law — you need an explicit written assignment clause. This is one of the most common and costly gaps in developer agreements.
What's the difference between owning the software and licensing it?
Ownership means you hold the copyright and can do anything with the code, including modify it, license it to others, or sell it. A licence only gives you permission to use it under whatever terms the agreement sets, while the developer retains ownership. Most businesses commissioning custom, purpose-built software want ownership, not just a licence.
Should payment be based on a fixed price or time and materials?
Both are common, and the right choice depends on how well-defined the scope is. A fixed price protects you from cost overruns but works best with a detailed specification; time-and-materials arrangements offer flexibility but need a strong change-management and reporting process to control cost.
What if the developer used open-source code in what they built for us?
Your agreement should require the developer to disclose any open-source components used and confirm that their inclusion doesn't create licensing obligations that conflict with your intended use of the software.
This is a corporate question
Start a file online — flat, published fees, reviewed by a licensed Ontario lawyer before a dollar is owed.