I review SaaS contracts every week. Subscription agreements, MSAs, order forms, terms of service -- the documents that sit between your product and your revenue.
Most of them have the same problems. Not because founders are careless, but because they grabbed a template from the internet, tweaked a few lines, and moved on to building product. That works until it doesn't. And when it doesn't, the cost isn't a slap on the wrist -- it's a churned enterprise customer, a failed audit, or a six-figure dispute with no contractual leg to stand on.
Here are the seven mistakes I see most often, why they matter, and how to fix each one.
If your contract promises "99.9% uptime" but doesn't define how uptime is measured, what counts as downtime, or what happens when you miss the target, you don't have an SLA -- you have a marketing claim.
Enterprise buyers know the difference. During procurement, their legal team will flag a vague SLA immediately. And if you do have a major outage, a poorly drafted SLA gives your customer leverage to renegotiate the entire deal or walk away.
The fix: Define uptime with a specific calculation method (typically excluding scheduled maintenance windows). Establish tiered service credits -- for example, 5% credit for 99.0-99.9%, 10% for 98.0-99.0%, and termination rights below 98%. Make service credits the exclusive remedy for downtime so you cap your exposure.
If you're processing customer data -- and every SaaS company is -- your contract needs a Data Processing Addendum (DPA) that actually addresses the regulatory landscape your customers operate in.
A missing or weak DPA doesn't just create legal risk for you. It creates risk for your customer, which means their compliance team will either demand extensive revisions (slowing your sales cycle by weeks) or reject your product entirely.
The fix: Build a standalone DPA that covers GDPR, CCPA/CPRA, and any industry-specific requirements (HIPAA BAAs for healthcare customers, for instance). Address sub-processor management, data breach notification timelines (72 hours for GDPR), data deletion upon termination, and cross-border transfer mechanisms. Make it available on your website so prospects can review it before the sales conversation even starts.
This is the one that keeps me up at night on behalf of my clients. Many SaaS contracts either have no liability cap at all, or they have a cap with so many carve-outs that it's effectively unlimited.
Without a liability cap, a single data breach or service failure could expose your company to damages that dwarf your annual revenue. Even if the claim is ultimately defensible, the litigation costs alone can be devastating for a growth-stage company.
The fix: Set a general liability cap tied to the fees paid -- typically 12 months of subscription fees. Then handle sensitive areas with separate, higher caps: data breaches and IP infringement might warrant 2-3x annual fees. Certain things should be truly unlimited (willful misconduct, death or personal injury from negligence), but those should be narrow and explicitly defined. Never agree to unlimited liability as a default position.
Here's a scenario I've seen multiple times: a SaaS company signs a contract with an enterprise customer that includes a clause assigning all "work product" or "deliverables" to the customer. The founder signs it without thinking twice because the customer isn't paying for custom development -- they're subscribing to the platform.
But the contract language is broad enough that a creative lawyer could argue the customer owns improvements, features, or integrations built during the contract term. I've seen this create real disputes, especially when a customer-requested feature becomes a core part of the product.
The fix: Your contract should make crystal clear that you retain all IP in the platform, including any improvements, modifications, or derivative works -- even those inspired by customer feedback. The customer gets a license to use the platform, period. If you do build custom work, address it in a separate SOW with explicit IP ownership terms. Never let a subscription agreement double as an IP assignment.
Auto-renewal is great for revenue predictability. But if your auto-renewal clause doesn't comply with the specific notice requirements in your customer's jurisdiction, the renewal may be unenforceable -- and you'll have a customer who thinks they cancelled and a billing dispute on your hands.
Several states now have laws requiring specific advance notice before auto-renewal kicks in. California, New York, and others have enacted or strengthened these requirements in recent years. Connecticut has its own automatic renewal statute (Conn. Gen. Stat. Section 42-635) that applies to certain business-to-consumer contracts.
The fix: Send renewal notices at least 30 days before the renewal date (60-90 days for enterprise contracts). Make the cancellation process clear and accessible -- don't bury it. Include the renewal term, pricing, and a direct cancellation method in the notice. And review the auto-renewal laws in the states where your major customers are located. The cost of compliance is minimal compared to the cost of a disputed renewal.
An Acceptable Use Policy (AUP) isn't just about covering yourself legally -- it's about protecting your platform and every other customer on it from abuse. Without an enforceable AUP, you have limited recourse when a customer uses your platform for spam, illegal scraping, or anything else that could damage your infrastructure or reputation.
The key word is enforceable. An AUP that lives on a webpage and isn't referenced in your contract may not give you the right to suspend or terminate service. And an AUP that's so broad it could apply to normal usage won't hold up if challenged.
The fix: Incorporate the AUP by reference in your master agreement with clear language that violation constitutes a material breach. Define prohibited uses with enough specificity that a reasonable person can understand what's allowed. Include graduated enforcement: notice, cure period, suspension, termination. Reserve the right to suspend immediately for violations that pose a security risk or could affect other customers.
What happens to customer data when the contract ends? What's the transition period? Can the customer keep using the platform while they migrate? Does pricing change during the wind-down?
If your contract doesn't answer these questions, every offboarding becomes a negotiation -- usually at a time when the relationship is already strained. I've seen termination disputes drag on for months, consuming management attention and legal fees that far exceed the value of the contract.
The fix: Define a post-termination data retrieval period (30-60 days is standard). Specify the format for data export (API access, CSV/JSON download, or database dump). State clearly that after the retrieval period, all customer data will be permanently deleted from production systems and backups within a defined timeframe. If you offer any wind-down or transition services, price them in advance so there's no ambiguity.
Your SaaS contract isn't just a legal formality -- it's a revenue document. A well-drafted agreement accelerates your sales cycle (because enterprise legal teams have fewer objections), reduces churn (because expectations are clearly set), and protects your company from catastrophic risk.
If you're currently using a template you found online, or if you haven't had your contracts reviewed since your last funding round, it's worth the investment to get them right. The fixes above aren't theoretical -- they're the specific changes I make for SaaS clients every month.
Schedule a free consultation if you want a second set of eyes on your SaaS agreements. I'll tell you exactly where the risk is and what to fix first.