The White-Label Capability Framework
Understand what “white label” actually means, identify the maturity level you need, and compare software on the capabilities that matter.
When searching for white-label software, you will encounter terms such as white-label rebranding, white-label SaaS, reselling and embedded software. The problem is that these terms are not used consistently.
Some providers have a dedicated white-label offering with detailed documentation. Others mention “white label” in an SEO title or blog post without explaining what can actually be branded or configured. We have also found software listed as white label by third-party websites while the vendor itself describes a much narrower offering.
That makes it difficult to answer a basic question:
What can I actually make my own?
The White-Label Capability Framework provides a consistent way to answer that question.
It focuses on two capability domains for the baseline review: Brand and Flexibility. Together, they show what your customers see and how much you can adapt the software to your own offering.
The framework also recognises three further domains: Control, Trust, and Commercial & Operations which become important when carrying out deeper due diligence.
How the framework works
The framework uses three maturity levels:
| Level | Maturity | Typical buyer fit | Core question |
|---|---|---|---|
| Level 1 | Brandable White-Label | No-Code Entrepreneur | Can I present the software as my own? |
| Level 2 | Enhanced White-Label | Agency, Reseller | Can I operate and adapt it as my own offering for multiple customers? |
| Level 3 | Fully White-Label | SaaS Builder, Solution Integrator | Can I make this sufficiently my own product or solution? |
These relationships are a guide rather than fixed rules. A buyer can need a higher level than their typical fit suggests. For example, a No-Code Entrepreneur may require Level 3 because the platform provides extensive no-code capabilities, while a reseller may only need Level 2.
The maturity of Flexibility can also be reached through different routes. Some platforms provide extensive no-code or low-code control; others provide developer capabilities such as a white-label API or white-label SDK.
The practical approach is to look at the overall capability profile. A product does not need every capability in a level to fit it.
What we verify
The baseline review is designed to be repeatable across a large number of software products.
A software website is added to the directory before it has necessarily been verified against the framework. Verification is a separate step.
Good signals include a dedicated white-label page, product documentation explaining the white-label offering, and knowledge-base articles showing how to enable or configure white-label features. A mention of “white label” in a blog post or SEO title alone is not considered sufficient evidence.
A listing receives a Verified designation when the capabilities can be confirmed through the software itself, normally by logging into the application, supported by provider documentation where relevant.
For technical capabilities, the distinction is important. An API or SDK does not automatically mean a white-label API or white-label SDK. Where a provider documents a white-label API or SDK, that documentation can be used as evidence. If the public documentation does not establish the white-label scope, provider confirmation may be required.
Capability Domain 1: Brand
Brand answers the most visible white-label question:
Can I make the software look and feel like my own?
Brand goes beyond uploading a logo. A genuinely branded experience can extend across the customer-facing application, login experience, emails, reports and other touchpoints.
The exact capabilities vary by platform, but the review looks for the following.
| Brand capability | What we look for |
|---|---|
| Logo / brand assets | Ability to apply the buyer's logo and core brand assets |
| UI brand configuration | Ability to apply a brand kit across the interface, such as typography, colours and visual styling |
| Favicon | Ability to replace the provider favicon with the buyer's own |
| Branded frontend | Customer-facing application is presented under the buyer's brand |
| Branded login | Login and authentication experience carries the buyer's branding |
| Custom domain | Platform can operate under the buyer's own domain or subdomain |
| Branded emails | Transactional and system emails can be presented under the buyer's brand |
| Branded reports / documents | Generated reports, PDFs or other customer-facing documents can carry the buyer's branding |
| Backend dashboard branding | The administration dashboard used by the buyer or their team can also be branded |
| Per-client branding | Different customer accounts can have their own branding where required |
| Provider branding removal | Provider branding can be removed from the relevant customer experiences |
| Branded mobile application | Mobile application can be presented under the buyer's brand where applicable |
Brand maturity
| Level | Brand maturity | Typical buyer fit |
|---|---|---|
| Level 1 — Brandable White-Label | Core branding such as logo, brand styling, domain and branded customer experience | No-Code Entrepreneur |
| Level 2 — Enhanced White-Label | Broader branding across customer accounts and platform touchpoints, including per-client branding | Agency, Reseller |
| Level 3 — Fully White-Label | Extensive branding across the platform, customer experiences and relevant product surfaces | SaaS Builder, Solution Integrator |
Capability Domain 2: Flexibility
Flexibility answers a different question:
How far can I adapt the software to the way I want to operate?
Flexibility is broader than simply having an API. A buyer may achieve significant flexibility through no-code configuration, customer management, workflows, packaging and localisation. A more technical buyer may need a white-label API, white-label SDK or self-hosting.
There are therefore two main routes to Flexibility maturity.
No-Code / Low-Code Route
| Flexibility capability | What we look for |
|---|---|
| Basic no-code configuration | Settings and functionality can be adapted without development |
| No-code / low-code builder | Visual tools allow substantial modification or creation of customer experiences |
| Custom fields / forms | Buyer can adapt data collection to its own requirements |
| Workflow configuration | Buyer can configure processes and automation |
| Conditional logic | Workflows or functionality can behave differently based on defined conditions |
| Custom pages / components | Buyer can create or modify relevant customer-facing areas |
| Multi-client / sub-accounts | Multiple customer accounts can be managed within the platform |
| Per-client configuration | Functionality can be configured differently for individual customers |
| Feature visibility | Features can be shown or hidden by customer, account or plan |
| Roles & permissions | Access can be tailored by user, customer or role |
| Customer provisioning | New customer environments can be created and configured efficiently |
| Multi-tenant management | Customer environments and data can be logically separated |
| Feature packaging | Functionality can be grouped into different customer packages |
| Subscription configuration | Different customer subscription plans can be created |
| Feature entitlements | Features can be linked to customer plans or account types |
| Configurable billing | Customer billing models can be configured |
| Payment gateway integration | Customer payments can be processed through supported payment providers |
| Usage-based monetisation | Customers can be charged according to usage where supported |
| Client billing / invoicing | Customer billing and invoicing can be managed through the platform |
| Language localisation | Multiple languages can be supported |
| Currency | Multiple currencies can be supported or configured |
| Time zones | Customer or account time zones can be configured |
| Regional formats | Date, number and other regional formats can be adapted |
| Regional payment methods | Market-specific payment methods can be supported |
| Measurement units | Regional measurement systems can be configured |
| Native integrations and webhooks | Pre-built integrations and event-based connections allow the platform to connect with other services and automatically exchange data without custom development. |
Developer / Code Route
The developer route is deliberately narrower. API and SDK are not treated as generic technical features. The review looks specifically for developer capabilities that support a white-label use case.
| Flexibility capability | What we look for |
|---|---|
| White-Label API | API capabilities are documented as supporting the creation or operation of the buyer's own branded offering |
| White-Label SDK | SDK and mobile SDK capabilities are documented as supporting the creation or integration of the buyer's own branded offering |
| Self-hosting | The software or relevant components can be deployed within the buyer's own infrastructure where supported |
Flexibility can mature through two different routes: No-Code / Low-Code and Developer / Code. The table shows how each route maps to the three white-label levels and the buyer types most likely to use it. A platform can qualify through either route, or through a combination of both.
Flexibility maturity
| Level | No-Code / Low-Code route | Typical buyer fit — No-Code / Low-Code | Developer / Code route | Typical buyer fit — Developer / Code |
|---|---|---|---|---|
| Level 1 — Brandable White-Label | Basic configuration and limited customer adaptation | No-Code Entrepreneur | Limited or no white-label developer capabilities | — |
| Level 2 — Enhanced White-Label | Advanced configuration, customer management and selected commercial capabilities | Agency, Reseller | White-label API or other documented white-label developer capabilities | SaaS Builder |
| Level 3 — Fully White-Label | Extensive no-code/low-code capabilities sufficient to build a highly customised offering | No-Code Entrepreneur, Agency, Reseller | White-label API + white-label SDK and/or self-hosting capabilities sufficient to build or integrate the offering | SaaS Builder, Solution Integrator |
The routes are not mutually exclusive. A platform can support both. A No-Code Entrepreneur may reach Fully White-Label through extensive no-code functionality, while a Solution Integrator will typically reach it through the developer route.
Buyer Fit
The buyer types describe why someone is looking for white-label software:
| Buyer type | What they are typically trying to do |
|---|---|
| No-Code Entrepreneur | Launch a branded software product or service without significant development |
| Agency | Deliver branded software and services to multiple clients |
| Reseller | Package, sell and monetise software as its own offering |
| SaaS Builder | Build a differentiated SaaS product around an underlying platform |
| Solution Integrator | Integrate software functionality into its own product, technology or infrastructure |
A white label software product can fit more than one buyer type.
Click here for more on the Framework
Beyond Brand and Flexibility
Brand and Flexibility are the two domains used for the baseline review because they can generally be verified from a provider's website, product documentation and, where available, the application itself.
The framework also includes Control, Trust, and Commercial & Operations. These matter when assessing the longer-term suitability of white-label software, but they are harder to verify consistently from public information alone. They can involve sentiment analysis, data ownership, migration, security, pricing, support, infrastructure, service levels and product roadmaps.
These domains are therefore better suited to a deeper review conducted with the provider, rather than being required for every directory listing.
🧩 Capability Domain 3: Control
Control measures how dependent you are on the provider. It covers areas such as data portability, migration, hosting, source-code access, ownership and what happens if the provider changes its pricing, product or ownership.
It answers:
How independent am I from the provider?
🔐 Capability Domain 4: Trust
Trust considers whether the provider is reliable enough to build your business and client relationships on. It can include security, compliance, uptime, API stability, support, reputation and transparency.
It answers:
Can I rely on the provider long term?
⚙️ Capability Domain 5: Commercial & Operations
Commercial & Operations covers what is required to run the software in practice. This varies by software category and can include onboarding, data migration, billing, support, partnerships, integrations and day-to-day production operations.
It answers:
Will it work for my business in production?
The Five Domains
| Domain | What it answers | Baseline review |
|---|---|---|
| 🎨 Brand | What can I present as my own? | ✓ |
| 🔌 Flexibility | How far can I adapt the software to my offering? | ✓ |
| 🧩 Control | How independent am I from the provider? | — |
| 🔐 Trust | Can I rely on the provider long term? | — |
| ⚙️ Commercial & Operations | Will it work for my business in production? | — |
The framework is broader than the baseline review. Brand and Flexibility provide a practical way to compare a large number of software products consistently. Control, Trust, and Commercial & Operations provide additional context for buyers who need deeper due diligence before committing to a platform.
The aim is not to turn every software listing into an exhaustive procurement exercise. The baseline gives buyers a consistent starting point for understanding what a provider actually offers, identifying the appropriate white-label maturity level and buyer fit, and deciding when a deeper conversation with the provider is warranted.