SaaSContractsChoosing a vendorCustom software
White-label SaaS: how it works and what to watch
9 min read
White-label SaaS is online software built and run by one vendor but presented to users under another company's brand. The reseller sells, the vendor operates. The model works well when roles, customisation and the exit route are written down before launch, and disappoints when they are discovered afterwards.
The term covers two quite different situations. In the first, you resell an existing product to your customers under your own name. In the second, you commission a platform that will be deployed, under each member's brand, across a network: franchisees, members of a trade association, distributors or subsidiaries of a group. This article covers both sides, then the agreement that binds them.
How it works
Three parties share the work:
| Party | What it does | What it sees |
|---|---|---|
| Vendor | Builds, hosts, maintains and evolves the software | One platform, many resellers |
| Reseller | Sells and brands the product, often handles first-line support | Its own customers |
| End customer | Uses the software to run its business | A product bearing the reseller's name |
Technically, one platform serves every reseller. Each has its own space, customers, settings and branding. It is a multi-tenant architecture with an extra layer: the tenants have tenants of their own. The ways to isolate data are compared in multi-tenant SaaS architecture explained.
Side one: reselling an existing SaaS under your brand
This is the fastest way to add software to your offer without building it. Consultancies, systems integrators and specialised distributors use it to sell a complementary product with their own margin.
Questions to ask the vendor before signing:
- What can really be customised? Logo and colours, almost always. Custom domain, email sender address, document templates, a mobile app under your name: check each one.
- Who handles support, and at which level? The common split is that the reseller answers how-to questions and the vendor fixes defects. The boundary and the response times must be in writing.
- Who decides the roadmap? The vendor has its own priorities; your customers will have requests. Knowing how requests travel upstream, and which are taken on, prevents promises you cannot keep.
- What happens if the vendor shuts down, is acquired or raises prices? That is the exit question, covered below.
- Does the vendor's name still appear anywhere? Legal pages, error screens, system emails: a partial white label can surprise customers.
Side two: building a white-label platform for your network
The second case concerns organisations at the head of a network. A franchise wants every franchisee on the same management tool, each under its local trading name. A trade association wants to offer members a business application. A group wants one tool shared by subsidiaries that keep their own identities.
The need resembles a multi-site back-office, with one major difference: network members are often independent legal entities. They sign their own terms, own their own data and can leave the network.
What to design in from the start:
- self-service creation of a new member space, so onboarding a member is not a project each time;
- per-member branding: logo, colours, contact details, document templates, optional domain;
- bounded business settings: what each member may change, and what the network fixes for everyone;
- a consolidated view for headquarters, limited to what the contracts allow it to see;
- an offboarding procedure: a member leaving the network must be able to take its data, and its space must be closed cleanly.
The most common pitfalls
Per-customer feature work. Swapping a logo costs almost nothing. Adding a feature for one reseller creates a product variant that must be tested and maintained in every release. Multiply those variants and the whole platform slows down. A healthy rule: branding is free, features are shared, and a feature requested by one party is either generalised, declined or charged for with eyes open.
Tiered support without clear boundaries. When an end user reports a problem, they call the reseller, who escalates to the vendor. Without a written split and response times, each side assumes the other is on it.
Emails that never arrive. Sending email from a reseller's domain requires that domain to authorise the platform's mail servers through its DNS records, or messages land in spam. This has to be configured and tested for every reseller domain.
Unplanned dependency. The reseller builds its customer relationships on software it does not control. A price increase, an acquisition or an end-of-life notice, and its customer base is exposed.
Data nobody clearly owns. In a three-party chain, data protection roles must be settled before the first customer, not during the first incident.
How the money usually flows
White-label pricing between vendor and reseller tends to follow one of three patterns, sometimes combined:
- a wholesale price per end customer or per seat, which the reseller marks up freely;
- a revenue share, where the vendor takes a percentage of what the reseller bills;
- a flat platform fee, common when a network commissions its own platform, with members then paying the network rather than the vendor.
Each pattern moves risk differently. A wholesale price protects the vendor; a revenue share aligns both parties but requires the reseller to open its books; a flat fee gives the network predictable costs and full control over what it charges members. Whichever you choose, write down how prices can change and with how much notice.
The agreement: clauses not to forget
The vendor-reseller agreement borrows from a software development contract and from a SaaS agreement, plus a few points specific to white labelling.
| Clause | What it should state |
|---|---|
| White-label scope | Customisable elements, vendor mentions that remain |
| Licence | Right to distribute under your brand, territory, any exclusivity |
| Ownership | Who owns the code, reseller-specific work, trademarks and data |
| Pricing | Price list, revisions, volume tiers, what is billed separately |
| Service levels | Availability, response times, split of support duties |
| Roadmap | How requests are raised, who decides, who pays |
| Personal data | Data protection roles, processing agreements, hosting location |
| Exit | Data export, transition period, assistance, custom domain |
| Termination | Notice, continuity for end customers, exit conditions |
On ownership, there is no single answer. Rights over the platform code and over work done for a specific reseller are defined case by case in the contract, depending on the model chosen; our article on who owns custom software source code explains the options.
On data, if any party serves customers in the European Union, the usual chain is: the end customer is the controller, the reseller its processor, and the vendor a sub-processor. Article 28 of the GDPR then requires a written contract at each link, and the controller's prior written authorisation, general or specific, before a sub-processor is engaged, with the same obligations passed down. Outside the EU, local privacy laws apply and may follow a different logic. Either way, confirm the roles with a lawyer.
On exit, the reversibility clause is the one that protects the reseller most. Our vendor lock-in exit plan lists what it should contain.
Resell or build: how to choose
| Criterion | Resell an existing SaaS | Build your own |
|---|---|---|
| Time to launch | Short, the product exists | Longer, it has to be designed |
| Upfront cost | Low, often a subscription | Development to fund |
| Fit with the business | That of the existing product | That of your network |
| Roadmap | Set by the vendor | Set by you |
| Dependency | High, to be framed by contract | Lower if the contract covers exit |
| Differentiation | Limited, others resell the same product | Real if the software carries your know-how |
Reselling is often enough when software is a complement to what you sell. Building makes sense when the software is central to what you bring to your network, or when no product on the market covers its trade without workarounds.
See the platform before you sign
Either way, the best protection is to see the software with your own cases before committing: a member's space, the branding, the headquarters view, the onboarding flow for a new customer.
At LPR Studio, that prototype is free and presented on a video call within 5 business days. It shows the platform under the brand of a fictional member of your network, before any decision. Three engagement models can then build it: fixed price, a subscription with no upfront development cost, or SaaS publishing.