The draft terms of service read like every other SaaS contract: confident, comprehensive, quietly overstating what the product actually does. Promises about how long we'd hold a customer's data and how it was handled — written at the altitude of a company much further along than we were. The legal boilerplate makes you sound established, so the temptation is to keep it.
We cut it instead.
The reasoning was simple. A term you can't honor isn't protection — it's a liability you've written against yourself, in your own hand, signed. The first time the gap between the promise and the reality surfaces, it surfaces in front of a customer who trusted the document. That's the worst possible place to discover you oversold.
So the rule we landed on: terms describe what the product does today, not what we hope it does at scale. In one case the product had quietly changed so it no longer needed to keep what the terms still said it might — the words had drifted into a claim that wasn't even true anymore. We rewrote them to match the code, and where we couldn't stand behind a clause, we deleted it rather than soften it with weasel words.
There's a cost. Plain terms make you look smaller than the inflated version. We decided that was fine — looking smaller and being honest beats looking solid and being caught.
The portable lesson: your policy is really a claim about your code. When they drift apart, the code is the truth and the words are the bug. Write at the altitude you can defend, and revisit as the product earns more ground.