What contracts does my SaaS or app startup need?

Think in layers

A gap in a lower layer weakens everything above it. Your customer contracts can only promise what your internal paper lets you deliver.

• Ownership layer: founder IP assignments, employee and contractor agreements, development agreements with agencies.
• Data layer: privacy policy, an internal data map, vendor and subprocessor contracts.
• Customer layer: terms of service or a SaaS agreement, an EULA for downloadable software, order forms, service levels.
• AI layer: what customers can put into your AI features, who owns the output, and whether you train on customer data.

A consumer app at launch usually needs the ownership layer, a privacy policy and terms of service. A B2B product selling to mid-market companies will also be asked for a negotiated agreement and a data processing addendum within the first few deals.

Which to do first

Usually the IP assignments from founders and anyone who has written code, because ownership problems get harder to fix over time. Customer-facing terms come next, right before launch.

Terms of service, EULA or SaaS agreement

These overlap but do different jobs.

Terms of service govern use of a website, app or platform: account rules, prohibited conduct, content ownership, suspension, disclaimers, limitation of liability and governing law. For consumer products, how users accept them matters. A clickwrap flow, where users take an affirmative step, gives you a much better record than a link in the footer.

An EULA is a licence to install and use software, common for desktop and mobile apps. App stores impose their own baseline terms, so check how your EULA sits alongside the store’s rules rather than assuming yours controls.

A SaaS agreement, often a master agreement with order forms, is what business customers expect. It’s where uptime, support, fees, renewals, security, indemnities and liability caps get negotiated. One negotiated master agreement can cover several purchases, with order forms for pricing and scope. See SaaS agreements.

Copying another app’s terms is risky twice over: the text may be protected by copyright, and it describes someone else’s product, data flows and jurisdiction.

Privacy policy and data processing terms

If you collect personal information in the course of commercial activity, PIPEDA generally applies, and Quebec, Alberta and British Columbia have their own private sector laws. Your privacy policy explains what you collect, why, where it goes and how people can access or correct it. See privacy policies for apps.

Under PIPEDA (Principle 4.1.3 of Schedule 1), you stay responsible for personal information you transfer to a third party for processing, and must use contractual or other means to protect it. The Privacy Commissioner’s cross-border guidelines also expect organizations to tell people, in clear language, when their information may be processed in a foreign country. If you run on US cloud infrastructure, your privacy policy should say so, and your vendor contracts should carry real data protection terms.

Business customers will ask the same of you through a data processing agreement: how you handle their data, which subprocessors you use, and what happens after a breach. If you serve Quebec, its private sector privacy law (s. 17) requires a privacy impact assessment before personal information is communicated outside Quebec, including to other provinces.

Development agreements with contractors and agencies

This is a gap that often surfaces in investor diligence. Under the Copyright Act (s. 13), employers are generally the first owners of work employees create in the course of employment. Contractors and agencies are different: they own what they create unless they assign it in a signed written agreement. A development agreement should include a present assignment of all deliverables and code, a moral rights waiver, a list of pre-existing tools the developer keeps (with a licence to you), handover of repositories and credentials, and milestones and acceptance testing. See who owns code a contractor writes.

Open source

Almost every codebase uses open source. Permissive licences generally allow commercial use with attribution. Others attach conditions, such as making source code available when you distribute modified versions, and whether those are triggered can depend on how you ship (a hosted service and a distributed mobile app can be treated differently).

You don’t need a lawyer to review every package. You do need a current inventory of dependencies and licences, a rule about which licence families need sign-off, and customer terms that don’t promise more than your open source position allows. Buyers and acquirers increasingly ask for the list.

AI terms

If your product calls a third-party model or has its own generative AI features, your terms should answer the questions procurement teams ask:

• Inputs: what customers may submit, and what they may not.
• Outputs: who owns generated content, and a clear statement that outputs may be inaccurate and should be reviewed.
• Training: whether you use customer data to train or improve models, and how customers can opt out.
• Upstream providers: how your obligations line up with your model provider’s terms.
• Acceptable use: an AI acceptable use policy you can actually enforce.

If a feature makes decisions about people based exclusively on automated processing of their personal information, Quebec’s private sector privacy law (s. 12.1) requires you to tell them no later than when you tell them about the decision. See AI product terms, NDAs for startups and AI and SaaS contracts.