This is a question that I often get asked. Not the abstract “what do I need to set up a company”, but the version that bites once things get real: we’ve built something, we’re putting it in front of customers – what do we need in place? Often the product is a portal or a subscription service, and the plan is to launch a basic version to test the market while you keep building. The instinct is to keep the legals light. That instinct is right. But “light” is not the same as “nothing”. The skill is in spending where the risk actually sits.

A quick word on how to think about this. Don’t start from a list of documents. Start from the question each document answers – who are we selling to, what are we promising, what are we doing with their data, and what happens if it goes wrong. If a question genuinely applies to you, deal with it. If it doesn’t yet, you can usually wait.

First, is your sector itself regulated?

One important assumption underpins everything below: that your business itself is not in a regulated sector. If it is – financial services, payments or lending, insurance, health or medical devices, regulated professional services, gambling and the like – then getting your sector compliance right from the outset is not optional, and keeping it light is not on the table. What you can sell, how, and to whom will turn on the rules for your sector and on exactly what your product or service does, so take specific advice early. The proportionate, spend-where-the-risk-sits approach below still applies to your general commercial and data terms – but it sits on top of your regulatory obligations, never instead of them.

“It’s only a beta or test version” – you still need terms

Launching an early, cut-down version of your product to test the market is sensible. But the moment someone can sign up and use it, you are supplying a service – and that means you need customer terms.

For a test or beta product, your terms need to do two extra jobs. First, be honest about what it is: an evolving, pre-release version that may change, may have bugs, and may be withdrawn or discontinued. Second, set realistic expectations on availability, support and reliability, and limit your warranties and liability to match (within the limits the law allows – see below). In practice that means saying the service is provided on an “as is” basis so far as legally permitted, that you don’t guarantee continuity or particular features, and that the customer should not rely on it for anything business-critical.

In fairness, this is a matter of degree rather than a different approach. Most SaaS-type services run on limited warranties and an “as is” footing even in their full-release versions, and most terms try to disclaim liability for how a customer chooses to use the service. With a beta you are simply leaning harder on that framing – being more conservative on availability, support and reliability – because the product genuinely is unfinished.

This is what protects you from the customer who treats your free beta as a guaranteed, mission-critical service and then complains when it changes.

Who are you selling to – businesses or consumers?

The rules are very different depending on whether your customers are businesses or consumers.

If you sell to consumers, the Consumer Rights Act 2015 implies terms you cannot exclude: services must be carried out with reasonable skill and care, and digital content must be of satisfactory quality, fit for purpose and as described. You also have to give certain pre-contract information, usually a right to cancel for distance sales, and your terms must be fair and transparent or they won’t be enforceable. You cannot simply contract your way out of any of this.

If you sell to other businesses, you have far more freedom to allocate risk – but not unlimited freedom. Under the Unfair Contract Terms Act 1977 your exclusions and limitations have to be reasonable, and you can never exclude liability for death or personal injury caused by negligence, or for fraud.

A specific warning: lots of founders copy US software terms because they are easy to find and very supplier-friendly – sweeping “AS IS” disclaimers and near-total liability exclusions. In the UK those clauses may simply fail the reasonableness test; in Germany and much of the EU they would fare worse still. Don’t lift US terms wholesale – they can leave you less protected than a sensible, enforceable clause would.

Warranties and liability – get the balance right

Two different levers: what you promise (your warranties and service commitments) and what you are on the hook for if something goes wrong (your liability).

The natural instinct is to promise nothing and exclude everything. That doesn’t work. Against consumers you can’t exclude the core statutory rights at all. And in a business contract, a clause that tries to exclude all liability can be struck down as unreasonable – leaving you worse off than if you had set a sensible cap.

The balanced position is usually: give limited, honest warranties; exclude indirect and consequential loss; cap your total liability at a sensible figure (often linked to the fees paid); and carve out the things you are not allowed to exclude. A reasonable cap is far more likely to be upheld than a blanket exclusion.

Everything is GDPR… isn’t it?

This is where there is the most fear, and most of it comes from mixing up two completely different things that are governed by different rules.

The first is personal data – information about identifiable individuals (your users, their staff, their contacts). This is governed by data protection law: the UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025. Here you need to be transparent through a privacy notice (who you are, what you collect, why, your lawful basis, how long you keep it, who you share it with, and individuals’ rights), to collect only what you need, to set sensible retention periods, and to keep the data secure. If you process personal data on a customer’s behalf, you also need data processing terms in your contract.

The second is the business or commercially sensitive information a client uploads into your portal – for example operational figures or supplier information. This is usually not personal data at all, so data protection law is largely beside the point. The protection here is contractual. Your customer terms should tell the client plainly what you will do with their data, give you the licence you actually need to provide (and, where relevant, improve) the service, and commit you to holding it securely and in confidence. If you want to use that data to improve your product or for benchmarking, the way to reassure clients is to commit to aggregating and anonymising it so that their organisation cannot be identified.

The distinction founders most often miss is this: a privacy notice speaks to individuals about their personal data; the data clauses in your customer contract speak to the customer organisation about its data and what you are allowed to do with it. You usually need both – they do different jobs.

A few other terms worth getting right

Beyond the big-ticket items above, a handful of other terms regularly earn their place:

Pricing. Be explicit about whether VAT is on top. If your price is silent it is treated as VAT-inclusive, which can quietly cost you a fifth of your revenue.

Changing your terms. You can reserve the right to change your terms, but for anything material you should give customers reasonable notice and a way out – and a refund where they have paid in advance.

Describing your service. Be clear about what the service is and, just as importantly, what it is not. If there is any risk of customers using your outputs in regulated activities, say prominently that the outputs are not intended for those uses and that, if used that way, the customer is responsible for its own compliance.

Indemnities. You can ask customers to indemnify you, but where the customer is an individual the indemnity has to be reasonable, fair and transparent to be enforceable. Be cautious about volunteering indemnities of your own – you generally don’t want to.

Mind your marketing – claims can become promises

Bold marketing is not just marketing. A specific claim on your website or in a pitch can become a contractual term, or a misrepresentation you are liable for if it turns out to be wrong. And to consumers, misleading claims can breach the unfair commercial practices rules – now contained in the Digital Markets, Competition and Consumers Act 2024, in force since April 2025. Under that Act, the Competition and Markets Authority can impose fines of up to 10% of global turnover directly, without going to court. “Bank-grade security”, “fully compliant”, “guaranteed savings”, “99.9% uptime” – only say it if it is true and you can stand behind it.

The same discipline applies to the promises in your own terms. Don’t commit to things that aren’t entirely within your control – and even where they are, consider an “all reasonable endeavours” formulation rather than an absolute guarantee. A common trap is telling customers their data will “never” be used to train AI models while relying on third-party providers whose own terms may permit exactly that. Don’t promise what your supply chain won’t let you deliver.

Insurance – do you need it, and how much?

A common question the moment you start selling. There is no universal answer, but the usual candidates are professional indemnity cover (if customers rely on your advice or service), public liability, and increasingly cyber cover. Two things drive the decision: your actual risk exposure, and what your customers require – business customers, especially larger ones, often insist on minimum levels of cover in their contracts, and your liability cap and your insurance should line up. Start proportionate to your risk and your contract values, and revisit it as your customers and deal sizes grow.

Where did your IP come from?

If two or more of you built the product before incorporating the company, the intellectual property you each created does not automatically belong to the company. It needs to be formally assigned in. Investors will check this, and it is painful and expensive to fix after the event – especially if one of the original founders has since left.

In the same vein, a short founders’ agreement (who owns what, vesting, what happens when someone leaves, and how decisions get made) should ideally have been put in place at the start. If it wasn’t, do it now – before you are selling in earnest, and certainly before you fundraise.

On a funding round you will usually put a shareholders’ agreement in place, which will override the founders’ agreement – but until then the founders’ agreement does a useful job. You can keep it high-level or go into detail: a short, plain-English version will often be enough for now, whereas a more detailed one is likely to need professional input.

Do we need everyone to sign an NDA?

NDAs do not protect an idea as such. Ideas aren’t property.

What an NDA does protect is the confidential information you disclose: your methodology, how your platform actually works, your datasets, your roadmap, your pricing and your customer information. Even without a patent, the real value usually sits in exactly those things – how you have built it and how it works.

So use one when you are about to share genuinely confidential detail with someone who could use it – a prospective customer who will see under the bonnet, a development partner, a supplier. Don’t expect one from investors, though – most won’t sign an NDA at the pitch stage, and pressing the point can mark you out as inexperienced. The better protection is to control what you actually disclose: share the story, the results and the traction, but keep the genuinely confidential detail – how the platform works, your datasets and your methodology – back until later stages, when there is a real deal on the table and the right protections are in place.

The takeaway

There is no fixed list. The right setup depends on your specific facts and the kind of business you are building.

Once you are selling, the things that genuinely matter are: customer terms that fit both your customers (business or consumer) and your product (including its beta status); a clear handle on data (personal data under data protection law with a privacy notice, and commercial data dealt with in your contract); honest marketing; a sensible warranty, liability and insurance position; and clean IP behind you. Spend where the exposure is real, keep it proportionate, and don’t copy someone else’s terms – least of all US ones – wholesale.

As a rule of thumb, the core documents are your customer terms and a privacy notice. Beyond that, it depends on your model: if third parties feed data into your platform, or you depend on a genuinely material supplier, you may want your own bespoke terms covering that relationship too. The reality however is that most suppliers will contract on their own terms and it would be rare for an early-stage company to be in a position to impose its own terms (or even negotiate the supplier’s terms!).

If you are not sure what applies to you yet, that is a useful conversation to have – and a far cheaper one – than fixing any of it later.

This article is general information and does not necessarily deal with every important topic or cover every aspect of the topics with which it deals. It is not designed to provide legal or other advice and should not be relied on as a substitute for legal advice.

© MR&T Advisory Limited, 15 June 2026