Terms written for your product
Drafted from how the platform actually works, rather than adapted from a business with a different shape.
Technology
Platform terms.
Your terms are the only agreement most of your users will ever have with you. They are also the document that decides what happens when an account is suspended, a customer refuses to pay, or something posted on your platform causes a problem. Most of the trouble comes not from what the terms say but from whether anybody agreed to them.
What this looks like when it goes wrong
The commonest version is a set of terms borrowed from another business. They describe a product that is not yours, refer to features you do not have, and are silent on the one thing that carries real risk. Nobody notices until the document is read by somebody looking for a way out, and the parts that were copied are the parts that do not fit.
The next version is terms nobody accepted. The document exists, it is linked in the footer, and there is no record showing that a particular customer saw it before committing, or which version was in force when they did. The sign up flow was designed to be quick. It was not designed to produce evidence.
Then there is the change nobody had the power to make. Pricing moves, a feature is withdrawn, or the liability position is tightened, and the new wording goes live for everybody at once. If the original terms did not say how they could be varied, the customer is arguably still on the old ones and there is no clean way of showing otherwise.
The quietest version is an acceptable use policy that cannot actually be used. An account is suspended for behaviour everyone agrees was unacceptable, and nothing in the documents permitted suspension, described the conduct or said what happens to the customer data afterwards. The commercial decision was right and the paperwork does not support it.
What actually decides it
Incorporation decides more of these arguments than wording does. What matters is whether the user was given the terms before they committed, whether they had to do something to accept them, and whether you can later show which version they saw. A platform that records acceptance against a stored copy of the document is in a very different position from one that relies on a link in a footer.
Who your users are changes what you can rely on. Terms between businesses are given a good deal of freedom. Terms offered to consumers sit under protective rules that limit what can be imposed on somebody with no ability to negotiate, and a clause that is unremarkable in a business contract can be vulnerable when the customer is an individual. Where a platform serves both, one document trying to cover both is usually the reason neither is properly covered.
Clauses limiting or excluding liability are the ones people argue about, and they turn on the drafting rather than on any general rule. Whether an exclusion reaches the loss that actually occurred, whether it survives the kind of failure that caused it, and whether it can be relied on against that particular customer are separate questions answered by what the clause says and where it sits. Terms written to sound reassuring frequently do less work than terms written to be narrow and specific.
Everything to do with material your users put on the platform runs on the licence you took and the control you kept. What you may do with their content, what you may remove and on what basis, what you say to a complainant, and what you owe the user when you act all come from the same document. So does the ending: what happens to an account, to the data in it and to anything you host once the relationship stops. Terms that describe only the good version of the relationship leave the hardest week undocumented.
What we do
The acceptance step
How and when users agree, and what your systems record, so the version in force can be shown later.
Acceptable use that can be used
Conduct rules, suspension and removal set out so that acting on them is straightforward rather than arguable.
Consumer and business users separated
Different terms where the audiences are different, instead of one document that serves neither properly.
Liability and risk allocation
Exclusions and limits drafted to the risks the product carries, and honest about what they do not reach.
Changing terms later
A variation route that works, so the next price change or withdrawn feature does not create a fresh problem.
When to spend nothing
Before launch, with a handful of users and a product whose shape is still changing, bespoke terms are usually the wrong purchase. A sound standard set plus genuine attention to the acceptance step will carry an early product a long way. What is never worth doing is lifting terms from a competitor, because the risk that they do not fit your product is precisely the risk they were supposed to cover.
The moment to spend properly is when the answer to a customer question starts being found in the terms rather than in a conversation. Enterprise customers who negotiate, payment volumes that make a refusal expensive, material posted by users, and any adjacency to a regulated activity all move the document from housekeeping to infrastructure. Until then, keeping the terms short and true is better than making them long.
Technology
More on technology
- SaaS and licensing
- Software ownership
- Data and privacy
- AI and emerging technology
- Technology disputes
Before anything is sent
Positions harden the moment the other side takes advice, and the quiet routes stop being available once a demand has gone out. While nothing has been sent, everything is still open.