Product document package: EULA, terms, policies
We will write the set your product actually ships with: the EULA or the SaaS agreement, the terms, the privacy policy, and the checks you run on the people who pay you.
Records kept
Хранение записей
at least 5 years
не менее 5 лет
Electronic form
Электронная форма
88 countries
88 государств
When you need a EULA and terms
The product ships next month
Code is ready and the legal pages are placeholders copied from somewhere. Whatever is on the site at launch is what binds you to your first users.
A store rejected your build
Review asks for a working privacy policy and terms at a real address. A missing page holds a release that everything else was ready for.
You started taking payments
Money changes the paperwork. A payment provider will ask who you are, what you sell and — where money moves through you — how you check the people paying.
A business customer sent redlines
Your first enterprise buyer replies with tracked changes to a SaaS agreement you never wrote. Negotiating from someone else’s draft costs terms you would have kept.
A user quotes terms you changed
Someone insists on a rule you replaced months ago. Which of you is right depends on what your system kept about that day.
Your documents contradict each other
The terms promise one refund window, the store page another and support a third. Without a kept record you cannot show which version the user saw.
What you get
- A licence or subscription agreement
- Terms your users accept
- A privacy policy that matches reality
- A written check procedure
- A version record you can show
What a SaaS agreement and the rest cover
A product document package is one set, written together. The licence says what the user may do with the product; the terms say how you and the user behave towards each other; the privacy policy says what you collect and why; and where money moves, a written procedure says whom you check and how.
Where the law puts an electronic message on a par with writing, a document accepted with a click is still a document — and a click you cannot prove is a document you cannot prove either. The model rule behind that is written for the legislator, and 88 countries have built their own law on it or under its influence. That is why half of this work is about the record: what the user saw, when, and which version it was.
What the set has to answer
- Who the contract is with — the entity that actually bills, not the brand written on the website header.
- What the user is allowed to do, what is forbidden, and what happens to their content and their account when either side stops.
- Money: what is charged, when it renews, how a refund works and what happens to data after the last payment.
- Liability and its limits, written so they survive a reader who is looking for a way around them.
- How the documents change: notice, effective date, and what happens to users who never open an email.
What we need from you
- What the product does, told plainly — including the parts the marketing page does not mention.
- What data the product collects, in one list — the detail belongs to data privacy and protection.
- How payments run: who takes the money, in what form, and whether anything is held on your side.
- Who your users are: consumers, businesses, children, or a mixture, because the answer changes the whole set.
- Whatever you are already using, even if it was copied — we need to know what your users have accepted so far.
Where a set breaks
- Documents copied from another product, which describe features you do not have and promise terms you cannot keep.
- A change pushed live with no date and no kept copy, so nobody can say what a given user accepted.
- Support answering by habit, in words that contradict the page the user actually agreed to.
- A new market or a new payment flow added to the product while the documents stay where they were.
Checks on the people paying
- Who you verify and at what point: on registration, on the first payment, or when a sum crosses a line you set in advance.
- What you ask for, what you keep and for how long: the retention period is written into the procedure itself. The international standard names at least five years — and asks it of financial institutions.
- Who decides when something looks wrong, what they are allowed to do about it, and how that decision is recorded.
- What your payment provider requires of you by contract, which can be stricter than anything the law asks.
Where the product is a game or an application going through store review, the same set is read again by the platform — that is a store compliance audit. Where personal data is the whole question, it is data privacy and protection.
Sources: the UNCITRAL Model Law on Electronic Commerce makes an electronic message meet a requirement of writing; legislation based on or influenced by it has been enacted in 88 countries. The forty FATF Recommendations are a standard for states; under it, financial institutions keep transaction and customer records for at least five years.
Stages of work
Reading the product — 3–5 working days.
We will go through the product the way a user does, and then the way a regulator would: what it collects, what it charges for, what it promises.
What the documents have to say comes out of the product, and a document written before anyone looked at the product is the reason sets contradict each other.
Deciding what the set contains.
Not every product needs every document. We will say which of them yours needs, which can wait and which would only add a page nobody reads.
Drafting the set — 1–2 weeks.
The licence or the subscription agreement, the terms, the privacy policy and, where money moves, the check procedure — drafted together so they agree with one another.
Where you already have documents, we will keep what works. Users have accepted those words, and replacing them wholesale creates a question about everything accepted before.
Acceptance and the record of it.
We will set out how the user accepts: what they see, what they tick and what your system stores about it. That record is the difference between an agreement and a screenshot.
The check procedure, where payments call for it.
We will write who is verified, at what threshold, what is kept and who decides when something looks wrong. It is written to be followed by your team without a lawyer in the room.
Rollout and versions.
Documents go live with a date, and the previous version is kept. We will describe how the version record has to work, so you can show what a user accepted on a given day.
Updates when the product changes.
A new feature, a new payment flow or a new market changes the set. We will update it and tell you when a change needs notice to users before it takes effect.
Our other work on licensing and compliance sits in the Licensing & Compliance area.
Our case studies
FAQ
Discuss
the Task
Speak to our team
Speak to our team. Tell us about your task –
we’ll help you with it in any jurisdiction.