Most founders write their terms of service the night before launch. The payment provider wants a link, so you paste something from a competitor, swap the company name and move on. Nothing happens for months. Then a customer asks for a refund your terms never mention, a B2B buyer's lawyer sends back a page of questions, or you change your free plan and realise you have no idea which version of the terms anyone actually agreed to.
This guide is for founders of small SaaS products, from zero to a few hundred customers, who want terms that match how the product really works without losing a week to it. It covers where to start, the clauses that matter at your size, how to get real agreement, and how to change the terms later. It is not legal advice. Use it to show up to a lawyer with a good draft and good questions, or to know when you can wait.
The short answer
Good terms of service for a small SaaS are short, specific to your product, and actually agreed to. Start from an openly licensed template instead of a competitor's page, fill in the clauses that match how you bill and handle data, and make sure your pricing page, checkout and terms all say the same thing.
Start from a real base: a generator, openly licensed policies, or a standard B2B agreement. Never a competitor's terms.
Write down how you sell first: plans, trials, renewals, refunds, who your customers are and where they live.
Get clear agreement: a visible line at signup and checkout saying that clicking the button means agreeing.
Keep versions: a "last updated" date, an archive of old versions, and a record of who accepted which one.
Change terms with notice: email customers before material changes. Quietly editing the page is not enough.
What terms of service do for a small SaaS
Terms of service are the contract between you and the people who use your product. At your size they do three jobs: they set expectations (what people get, what they pay, what happens when they stop paying), they cap your risk so one angry customer cannot claim far more than they ever paid you, and they give you clear rules to point to when someone misuses the product. They do not protect you if nobody actually agreed to them.
Founders often cram several documents into one page. It helps to know which one does which job.
Document | What it covers | When you need it |
|---|---|---|
Terms of service | The rules of the deal: access, payment, renewals, acceptable use, liability, ending the account | Before anyone signs up or pays |
Privacy policy | What personal data you collect, why, who you share it with, how people can ask for deletion | As soon as you collect an email address |
Refund policy | When money comes back and how to ask for it | Before you take payment (a section of the terms or its own page) |
Acceptable use policy | What customers must not do with your product | Once people can upload content, send email or use AI features through you |
Order form or signed agreement | Custom terms for one larger customer: price, term, special promises | Your first B2B deal outside self-serve checkout |
This guide is about the first one. Your privacy policy deserves its own afternoon, because it has to describe your real data flows, not a generic list.
Step 1: Write down how you actually sell
Templates go wrong when they describe a business you do not run. Before you open one, spend twenty minutes answering these questions in a plain note. Most answers go straight into the terms.
Who are your customers? Businesses, consumers, or both? Consumer protection rules are much stricter.
Where do they live? Note any customers in the EU, UK or California.
How do they pay? Monthly, annual, usage-based? Stripe directly, or a merchant of record like Paddle or Lemon Squeezy? SideHunt has a guide to setting up payments and choosing between Stripe and a merchant of record.
Do plans renew automatically? Almost every SaaS plan does, and the terms must say so plainly.
Is there a free plan or trial? Card required? What happens on the last day? If you are still deciding, read Aura++'s guide on choosing between a free trial and freemium before product-market fit.
What is your real refund rule? The one you actually follow when someone emails you.
What do customers put into the product? Files, client lists, prompts? Does any of it go to an AI model provider?
What would hurt you most? Spam sent through you, account sharing, scraping, resold access? Those become your use rules.
Illustrative example (made up, used throughout this guide): Tidelist is a $24 a month tool that turns client emails into task lists for small agencies. Customers are businesses, mostly in the US and UK, a few in Germany. Billing is monthly or annual through Stripe, with a 14-day trial and no card required. The founder refunds the last charge if someone asks within 7 days. An AI model summarises the emails customers paste in. The biggest risk is someone pasting in data they are not allowed to share.
Step 2: Pick a starting point you can defend
Copying a competitor's terms feels efficient, but it is the worst option. Their terms are written for their business, their country and their risk, they are usually protected by copyright, and they often mention entities or laws that have nothing to do with you. Here are the honest options.
Starting point | Cost (as of Oct 2026) | Good for | Watch out for |
|---|---|---|---|
Terms generator (for example Termly) | Termly's free plan includes one legal policy; Pro+ lists at $20 a month billed monthly | A fast first draft from a questionnaire | Generic wording; check every answer against your Step 1 note |
Free under CC BY 4.0 (keep the attribution) | Plain-English terms, refund and use policies for a self-serve subscription | The repo is no longer maintained and describes 37signals' own business, so edit heavily | |
Free under CC BY 4.0 | B2B deals with an order form; written by a committee of attorneys | Built for signed deals under US law, so heavier than a self-serve signup needs | |
A lawyer drafting or reviewing | Varies widely; ask for a fixed quote | Consumer sales, sensitive data, big contracts, anything unusual | Bring your note and a draft so you pay for judgement, not typing |
For most self-serve B2B products, a sensible path is: draft from a generator or the Basecamp policies, borrow structure and fair defaults from Common Paper, then pay for a review once you have paying customers or your first larger deal.
Step 3: Fill in the clauses that matter at your size
A big company's terms run to forty sections. You need about a dozen, and each should say something specific. Work through this table with your note open.
Clause | What to write | Common mistake |
|---|---|---|
Who you are | Legal company name (or your own name as a sole trader), country, contact email | Only the product name, so nobody knows who the contract is with |
Accounts | Business-only use or minimum age, who is responsible for logins, seat rules if you price per seat | Not saying whether accounts can be shared |
Billing and renewal | Prices live on the pricing page, plans renew until cancelled, when cards are charged, how tax works | Hard-coding prices into the terms and forgetting to update them |
Trials and free plans | Trial length, what happens when it ends, that free plans can be limited or changed | Promising a free plan "forever" |
Refunds | The rule you actually follow, in one or two sentences | "All sales final" while you quietly refund people anyway |
Customer data | Customers own what they put in; you use it only to run and improve the service; how to export it | Claiming broad rights over content you do not need |
AI features | Output can be wrong and needs human review; whether data trains models; which providers process it | Saying nothing, then answering the same question for every B2B buyer |
Acceptable use | Your real risks from Step 1: no spam, no illegal content, no data you have no right to share, no reselling | A long generic list that misses your actual risk |
Availability | You aim to keep the service running but promise no uptime unless you offer a real SLA | Marketing copy promising "99.99% uptime" with nothing behind it |
Limitation of liability | A cap, usually tied to what the customer paid in the last 12 months | No cap at all, or a $0 cap a court may ignore |
Ending the account | How customers stop, when you can suspend (non-payment, abuse), how long data stays before deletion | Silence on what happens to data after closing |
Changes and governing law | How you will notify people of changes, and which country or state's law applies | "We may change these terms at any time without notice" |
The liability cap
This clause protects a small company the most. A common B2B pattern caps each side's liability at the fees paid in the 12 months before a claim. The Common Paper agreement page says 85% of agreements made with it set that cap at 1x those fees, and warns that a $0 cap would generally be unenforceable (checked October 2026). If you sell to consumers, many countries limit how far you can cap liability at all.
Customer data and AI
This is now one of the first things B2B buyers ask about. Version 2 of the Common Paper agreement added default machine-learning language, including a line that AI output "may be incorrect or inaccurate" and is "not a substitute for human oversight." Whatever wording you pick, match it to what your code does. If a model provider keeps prompts for 30 days, your terms should not say data never leaves your servers. When buyers start sending detailed data questions, MakerHunt's guide on writing a security page that unblocks your first B2B deals covers the other half of the answer.
Step 4: Put a plain-English summary on top
Most people will never read your full terms. A short summary at the top, clearly labelled as a summary, helps honest customers and costs you nothing. Keep it to five or six lines and say the full terms below are what count.
Illustrative example of the Tidelist summary:
Tidelist is for businesses. You need to be 18 or older and using it for work.
Plans renew monthly or yearly until you cancel in Settings. We email a receipt each time we charge you.
If you ask within 7 days of a charge, we will refund it.
Your emails and tasks are yours. An AI provider summarises them, and we do not use your content to train models.
Do not paste in data you are not allowed to share.
If we change these terms in a way that matters, we will email you at least 30 days before.
Writing the summary is also a test. If you cannot explain a clause in one plain line, you probably do not know what it commits you to yet.
Step 5: Get real agreement at signup and checkout
Terms nobody agreed to are just a web page. In Berman v. Freedom Financial Network (Ninth Circuit, 2022), the court refused to enforce terms shown in tiny grey text, with links in the same grey as the rest of the sentence, above a large green "Continue" button. Notice has to be reasonably conspicuous, it said, and a click only counts as agreement if the person is explicitly told that clicking means agreeing. It said the defect could easily have been fixed with language such as "By clicking the Continue >> button, you agree to the Terms & Conditions."
In practice:
Put the line right next to the button on the signup form, in readable text, not only in the footer.
Make the link look like a link and make it open the actual terms.
Use the button's own words: "By clicking Create account, you agree to the Terms of Service and Privacy Policy." An unticked checkbox works too.
Repeat it at checkout. In Stripe Checkout, setting
consent_collection.terms_of_servicetorequiredshows a tickbox customers must tick before paying. Stripe's Checkout policies documentation says you first add your terms URL to your account's public details, and the completed session then records the consent asaccepted.Keep a record. Store the terms version and a timestamp against the user. Two columns,
terms_version_acceptedandterms_accepted_at, are enough.
That last step is the one founders skip, and the one you will want most the day someone disputes a charge.
Step 6: Make every page tell the same story
Most real problems come from contradictions, not missing clauses. The pricing page says "cancel anytime," the terms say annual plans are non-refundable, and an old support reply promised a full refund. Customers and card networks will believe the most generous version they can find. Spend thirty minutes checking these agree:
Where | What to check |
|---|---|
Pricing page | Renewal wording, trial length, what "unlimited" really means, whether tax is included |
Checkout | Plan name and amount match, renewal is stated, terms link works |
Onboarding emails | No promises the terms do not back up |
Help docs and saved replies | Same refund rule, same cancellation steps |
Receipts and renewal reminders | A link to the terms and a way to reach you |
Payment providers check too. Paddle's domain review requirements ask for terms and conditions, a refund policy and a privacy policy reachable from your site's navigation, with your company name (or a sole trader's legal name) in the terms (checked October 2026).
Step 7: Publish it where people can find it
Put the terms at a stable URL like /terms and link them from the footer, the signup form, checkout and receipt emails. Add a "Last updated" date and a short version number, like v1.2.
Keep every old version, either on a /terms/archive page with dated copies or as files in your repo. When a customer from last year disputes something, you need to show what they agreed to, not today's text. Basecamp ran its policies as a public GitHub repo for years, so every change had a date and a diff.
Step 8: Change your terms the right way
You will change your terms: new plans, an AI feature, a new payment provider. The mistake is treating the terms like any other page you can edit at will. In Douglas v. U.S. District Court (Ninth Circuit, 2007), a phone company posted revised terms with new charges and an arbitration clause on its website without telling an existing customer. The court held he was not bound: a revised contract is a new offer, and you cannot accept an offer you do not know exists.
A safer routine:
Decide if the change is material. Money, data use, liability, disputes or what the product does: material. A typo fix: not.
Email every active customer about material changes, with a two-line summary, the new version and the old one.
Give a clear effective date. Thirty days is a common, fair default for paid customers; some laws and contracts require specific periods.
Ask for agreement again for big changes, with a short prompt at next login using the same clear wording as signup.
Update the version, date and archive, and record the new acceptance.
When a template stops being enough
Everything above leans toward businesses buying from businesses. Consumer sales are stricter. The EU's Your Europe guide to the right of withdrawal explains that consumers who buy a service online can generally cancel within 14 days without a reason, with exceptions such as a fully delivered service the consumer expressly asked to start immediately, acknowledging they would lose that right. Book a lawyer when any of these apply:
You sell to consumers in the EU, UK or a US state with its own auto-renewal law.
Customers put health, financial, children's or other sensitive data into the product.
A customer wants to sign their own contract or sends redlines on yours.
One deal is worth more than a few months of revenue.
You want arbitration, class action waivers or anything limiting how customers can bring claims.
You are raising money or selling the company, when someone will read every word.
A 7-day plan
Day | Task | Time |
|---|---|---|
1 | Write the Step 1 note: customers, countries, billing, trial, refunds, data, risks | 30 minutes |
2 | Pick a starting point and create the base draft | 1 hour |
3 | Rewrite clause by clause using the Step 3 table | 2 hours |
4 | Write the plain-English summary; cut anything you cannot explain | 45 minutes |
5 | Add the signup line, turn on checkout consent, add the two database columns | 1 to 2 hours |
6 | Run the Step 6 consistency check and fix contradictions | 30 minutes |
7 | Publish at /terms with date, version and archive; link from footer and receipts | 30 minutes |
FAQ
Do I legally need terms of service for my SaaS?
Often no law forces you to have them, but in practice you do. Payment providers such as Paddle require them before you can sell, B2B buyers expect them, and without them you have no agreed liability cap or rules on misuse.
Can I use a free terms of service template?
Yes, if it is openly licensed and you adapt it. Basecamp's policies and the Common Paper agreement are free under CC BY 4.0, so keep the attribution. What you should not do is copy another company's terms.
Is a checkbox better than "By clicking, you agree"?
Both can work if the notice is clear and sits right next to the action. An unticked checkbox is the most explicit. The real risk is faint text that is easy to miss, or a button that never says clicking means agreeing.
How often should I update my terms?
When something real changes: pricing structure, data handling, a new AI or payment provider, a new country. Reread them once a year against your Step 1 note to catch drift.
The bottom line
Your terms of service are not a box to tick for the payment provider. Write down how you really sell, start from a template you are allowed to use, make every clause match your product, get clear agreement, and tell people before you change anything. That is a weekend of work, and it saves you from the worst kind of customer argument: the one where your own pages disagree with each other.
When your terms, pricing and signup flow are ready for more people, Aura++ is where founders launch and get discovered by early users who are already looking for tools like theirs.