▶ Watch: White-Label Software: 5 Capabilities to Evaluate Before You Buy (2:21)
Brand covers what your customers see. Flexibility answers a different question:
How far can I adapt the software to the way I want to operate?
It's broader than configuration. It covers how the platform adapts per customer, how functionality is packaged and monetised, how it supports different markets, and how it connects to other systems. In the White-Label Capability Framework, it's the second of the two baseline-review domains.
Two routes: no-code and code
Flexibility can come from No-Code / Low-Code capabilities (settings, visual tools, pre-built functionality) or from Developer / Code capabilities (a white-label API or SDK). A platform can support either or both, and neither route is inherently "higher." A highly configurable no-code platform can reach Deep White-Label flexibility without exposing any API.
No-code / low-code capabilities
Configuration & workflow
| Capability | What to look for |
|---|---|
| Basic no-code configuration | Toggles, labels, defaults, notifications, modules on/off, all in the admin UI |
| Visual builder | Drag-and-drop design of pages, flows, emails, widgets. Raw HTML editing alone doesn't count |
| Custom fields / forms | Add text, select, date and file fields so records match your data model |
| Workflow configuration | Multi-step in-product processes: trigger → actions (e.g. notify → assign → update record) |
| Conditional logic | Workflows/forms that branch on field, plan, role or event. A straight trigger → action isn't enough |
| Custom pages / interfaces | Create or substantially change pages, portals, dashboards, not just rearrange widgets |
| Native integrations | Pre-built connectors (CRM, calendar, payments, email). A generic API is not this |
| Webhooks | Register an HTTPS endpoint to receive event payloads (signup, status change, payment) |
Customer & account management
| Capability | What to look for |
|---|---|
| Multi-client / sub-accounts | Manage many customer accounts from a central dashboard |
| Per-client configuration | Settings, workflows, fields, modules or branding differ per customer account |
| Feature visibility | Show/hide/enable features by customer, account, package or plan via the admin UI |
| Roles & permissions | Role-based (and per-account) access for internal staff, customer admins and end users |
| Reseller management | Create, activate, suspend, update and manage customer accounts from a central reseller interface |
| Multi-tenant management | Customer environments and data logically separated so tenants can't access or affect each other |
Packaging & monetisation
| Capability | What to look for |
|---|---|
| Subscription & pricing configuration | Create your own plans and prices in-product (monthly/annual, usage-based, per-seat, one-time). The vendor's pricing page doesn't count |
| Configurable billing | Intervals, trials, proration, taxes, discounts, credits |
| Payment gateway integration | Payments via your gateway (e.g. Stripe), with funds landing in your merchant account |
| Client billing / invoicing | Generate, send and track customer invoices in-product. The vendor's invoice to you doesn't count |
Localisation
| Capability | What to look for |
|---|---|
| Language localisation | Product runs in multiple languages per customer/account, not just a translated marketing site |
| Currency | Multiple currencies, or currency set per customer/account |
| Time zones | Per-customer/account time zones for dates, schedules and logs |
| Localised formats | Date, number and measurement formats follow locale (DD/MM/YYYY vs MM/DD/YYYY, metric vs imperial) |
| Local payment methods | Market-appropriate methods such as ACH, SEPA, UPI or wallets like Wero. Coverage matters, not the gateway count |
Developer / code capabilities
This is where devs should read closely: an API or SDK doesn't automatically qualify as white-label.
- White-Label API: lets you operate Brand and Flexibility capabilities in a white-label offering, such as account provisioning, branding/domain settings, workflows, roles and billing. A generic data or reporting API isn't this.
- White-Label SDK: lets you build or integrate Brand and Flexibility capabilities into a branded app or experience (libraries, components, abstractions). A generic REST wrapper, mobile kit or chat/agent SDK isn't this unless it's documented for white-label implementations.
The assessment focuses on what you can actually control or build, not on whether developer tools exist.
Flexibility maturity
| Level | No-code / low-code route | Developer / code route |
|---|---|---|
| 1. Brandable | Basic configuration, little control over underlying functionality or per-customer behaviour (Branded Business) | Limited dev capabilities; white-label API/SDK absent or limited (Branded Business) |
| 2. Enhanced | Advanced configuration, customer management, workflow customisation, selected operational/commercial controls (Branded Business, Agency, Reseller) | APIs/SDKs support meaningful customisation or integration of selected white-label functionality (Agency, Reseller, SaaS Builder) |
| 3. Deep | Extensive configuration supporting a highly differentiated offering, potentially without conventional development (Branded Business, Agency, Reseller) | Extensive dev capabilities giving substantial control over functionality, integration and product experience (SaaS Builder, Solution Integrator) |
The levels are a guide, not a checklist. A platform doesn't need every capability in a level to qualify, and the presence of an API or SDK alone doesn't establish a higher level.
Next in series → Domain 3: Control, or how independent you are from the provider.
This post is part of the **White-Label Capability Framework* series. The full framework, with every capability definition and maturity table, lives at iwhitelabel.io/pages/the-white-label-capability-framework. See the White-Label Software Glossary for terms, or browse white label software by category.*
Top comments (0)