B2B SaaS before the first paying customer: what needs to be ready?

You have a working demo and a business willing to pay for it. You need to agree what it is buying, when charges begin and what happens to its data when the relationship ends. A lengthy legal package covering every possible future version can wait. The terms of that first sale cannot.

Start legal preparation for B2B SaaS with the customer’s actual journey: ordering, access, payment, data and exit. Choose documents and product changes around that journey. This keeps the initial budget focused on paid sales, with further work tied to features as they become real.

What this article covers

Walk through the purchase as a customer

Suppose you sell an application to businesses. Today there is one monthly plan and manual onboarding. In six months you want annual subscriptions, usage-based billing and an API. The launch terms need to describe today’s model, while the future changes need a place on the review list.

Follow the process from the offer to the first invoice. Does the contract arise through checkout, a signed order or acceptance by email? When are the terms provided, and what evidence of acceptance is retained? A person administering an account is not necessarily authorised to order a paid service for the business.

Check applicable rules on making terms available. For example, Article 8 of Poland’s Electronic Services Act, in Polish, requires service terms to be provided before contracting in a form that can be obtained, reproduced and retained. A footer link alone does not resolve what the customer received before purchasing.

What needs to be settled before the first charge?

Small inconsistencies across the landing page, pricing, account area and contract create avoidable friction. One page says the trial is free, another requires a card, and nobody has decided when the paid period starts.

Before launch, connect these decisions:

• Scope: features, limits, users and paid extras.
• Price: currency, taxes, billing period and charging unit.
• Start: contract formation and the start of paid access.
• Changes: upgrades, downgrades, renewals and price changes.
• Failed payment: retries, communication and possible suspension.
• Exit: cancellation, data export, retention and account deletion.

These are decisions to make, rather than a single mandatory model for every service. A negotiated order can contain customer-specific terms. Self-service sales rely more heavily on terms presented in the application and a record of which version was accepted.

Match the launch package to what you sell

A simple model needs consistent service terms, privacy information and, where you act as a processor, data processing arrangements. An order can specify the plan, price and agreed exceptions. Establish which document takes priority if they conflict.

A competitor’s five annexes do not automatically justify five of your own. Equally, a one-page agreement cannot replace decisions about liability if the service supports a customer’s critical process. Let the actual service and risk determine the work.

Check who can buy the product. A business label does not always remove protective rules. In Poland, certain sole traders can benefit from unfair-term protection when a directly business-related contract is outside their professional field (Civil Code, Article 385⁵, in Polish). Opening registration to those customers needs a separate assessment.

Establish data roles before sending a DPA

You may process customer-uploaded data on the customer’s behalf while acting as a controller for your own billing. Review the actual purposes and flows. A DPA does not replace privacy information for your own processing.

Where you process personal data on behalf of a customer within the GDPR’s scope, Article 28 GDPR sets requirements for the processing contract. Prepare the subprocessor list, security description, support access arrangements and end-of-service process. The article on objections to a new subprocessor explains vendor changes in more detail.

Return to the application with manual onboarding. If support accesses customer accounts through a shared password, another annex will not fix the process. Agree how access will work, then describe it accurately.

An enterprise customer may need a separate route

A larger customer may send its own contract, DPA and security questionnaire. Confirm the answers with the people responsible for the product and infrastructure before signing. Questionnaire responses may become contractual commitments, particularly when the questionnaire forms an annex.

Set negotiation boundaries around availability, support, audits and liability. A service level agreement (SLA) promising 99.9% availability needs a measurement method, exclusions and consequences for missing the target. Also check the product’s IP chain before making contractual assurances about rights.

One customer’s negotiation need not change the terms for every user. An individual order with explicit exceptions can support the larger deal while preserving the standard sales model.

What can wait for the next iteration?

A future partner programme, marketplace or API plan does not need final terms on the day the first subscription is sold. It does need a clear review point before release.

Include legal review in the process for introducing new billing, customer groups, integrations and data uses. Assign responsibility for flagging changes, approving terms and keeping previous versions. For service exit, also assess the applicability of the Data Act’s switching rules.

Key points

• Prepare purchase, billing, data and exit for the plan actually offered at launch.
• Review the application and evidence of acceptance alongside the documents.
• Match the DPA to real data flows and enterprise commitments to the team’s capabilities.
• Tie further legal work to product changes so the launch budget is not consumed by future variants.

This is how we scope IT and SaaS legal support. Our experience section includes work on a platform launch and subsequent payment iterations.