Showcase Your White Label Software
iwhitelabel invites white-label software providers to demonstrate a real product capability through an iwhitelabel Product Showcase.
This is not a guest post. You record a screen video of the product, with a voiceover. iwhitelabel turns an approved video into an interactive walkthrough readers can step through. Where it fits, the same video can also appear on your product listing.
Don't just tell people what your software can do. Show them.
Who this is for
This opportunity is for:
- White-label software providers demonstrating a product capability
- SaaS companies with white-label, reseller or rebrandable solutions
- Platforms whose distinctive workflows are easier to understand on screen
- Vendors who want evidence of a capability, not another product description
A good showcase answers one question: what can your software actually do, and what does that look like in practice?
What a Product Showcase is
A Product Showcase is a demonstration-led page that takes readers into the product so they can see how it works in practice.
Use the White-Label Capability Framework as a reference so the demonstration maps to Brand or Flexibility. You can show one capability, several related capabilities, or a complete use case.
Your iwhitelabel listing remains the place for broader product information. The Product Showcase is the evidence layer for what you demonstrate.
What to demonstrate
Show the product in use. The framework is a reference, not a menu you have to pick one item from.
Any demonstration is fine if it maps to Brand or Flexibility and can be seen on screen. That can be a single capability, several related capabilities, or a full journey through a white-label or reseller use case.
The strongest demonstrations show a complete journey: configure → apply → resulting experience. Show where the setting lives, what you change, and what the reseller, customer or end user then sees.
✦ Brand
Brand answers: can I make the software look and feel like my own?
That can include logos and brand assets, UI styling, favicon, branded frontend and login, custom domain, branded emails, reports, backend dashboard branding, per-client branding, provider-branding removal, mobile and app-store branding, and branded support surfaces.
View all Brand capabilities →
Brand goes beyond uploading a logo. A genuinely branded experience can extend across the customer-facing application, login experience, emails, reports and other touchpoints.
| Brand capability | What we look for |
|---|---|
| Logo / brand assets | Buyer can upload and apply its own logo and core brand assets in the live product, in place of the provider’s defaults. |
| UI brand configuration | Buyer can apply a brand kit across the interface — colours, fonts and visual styling — so surfaces match the buyer’s look. Custom CSS can count; a theme or brand-kit control is enough. |
| Favicon | Buyer can replace the provider favicon so the browser tab (and app/PWA icon, if the product has one) shows the buyer’s icon. |
| Branded frontend | The customer-facing application — screens, navigation, labels and customer portal — is shown as the buyer’s product, without the vendor’s name, logo or default visual identity. |
| Branded login | The sign-in page, plus registration and password-reset screens, uses the buyer’s logo, colours and copy rather than the provider’s. |
| Custom domain | The product opens on the buyer’s domain or subdomain after DNS setup, with a valid SSL certificate on that hostname. |
| Branded emails | Transactional and system emails send as the buyer: buyer From name/address and branded templates, via custom SMTP or provider-managed sending from a verified buyer domain. |
| Branded reports / documents | Generated customer documents — reports, PDFs, exports, invoices — show the buyer’s logo, colours and header/footer rather than the provider’s. |
| Backend dashboard branding | The admin / operator dashboard used by the buyer’s employees and sub-admins is branded as the buyer’s product. |
| Per-client branding | Individual customer or tenant accounts can use their own brand kit, not only one agency-wide theme. |
| Provider branding removal | Vendor name, logo, “powered by” and other provider-identifying marks can be turned off or removed from the customer experience. |
| Branded mobile app | A mobile app or PWA shows the buyer’s app name, icon, splash screen and interface rather than the provider’s. |
| Branded app-store app | A store-listed Android and/or iOS app can go out under the buyer’s own developer account, with the buyer’s app name, icon and store listing. |
| Branded customer support surfaces | The customer-facing help centre, knowledge base, in-app help or docs site can use the buyer’s brand rather than the provider’s support site. |
⚒ Flexibility
Flexibility answers: how far can I adapt the software to the way I want to operate?
That can include configuration and workflows, custom fields and pages, integrations and webhooks, multi-client accounts, reseller and multi-tenant management, packaging and billing, localisation, and white-label API or SDK capabilities.
Flexibility can come from no-code / low-code configuration, from developer capabilities, or from both.
View all Flexibility capabilities →
Configuration & Workflow
| Capability | What we look for |
|---|---|
| Basic no-code configuration | Buyer can change standard product settings in the admin UI without writing code. |
| Visual builder | Buyer can design or substantially change customer-facing experiences with a visual or drag-and-drop builder. Editing raw HTML or code alone does not count. |
| Custom fields / forms | Buyer can add or adapt data fields and forms so records and intake match its own data model. |
| Workflow configuration | Buyer can build a multi-step process in the product (trigger → actions the platform executes). |
| Conditional logic | That in-product workflow or form can branch based on a field, plan, role or event. |
| Custom pages / interfaces | Buyer can create or substantially change customer-facing pages or views, not only rearrange widgets on a fixed layout. |
| Native integrations | Pre-built connectors in the product’s integration list connect to other services without custom development. |
| Webhooks | Buyer can register an HTTPS endpoint so the product sends event payloads when defined actions occur. |
Customer & Account Management
| Capability | What we look for |
|---|---|
| Multi-client / sub-accounts | Buyer can create and operate multiple customer accounts from one login. |
| Per-client configuration | Settings, workflows, fields or modules can be set differently per customer account. |
| Feature visibility | Features can be shown, hidden or included by customer, account or plan. |
| Roles & permissions | Access can be set by role, and where offered by customer. |
| Reseller management | The buyer has an agency / dealer portal to sell and manage customer accounts under its own business or brand. |
| Multi-tenant management | Customer environments and data are logically separated. |
Packaging & Monetisation
| Capability | What we look for |
|---|---|
| Subscription & pricing configuration | Buyer can create customer plans and prices in the product. The vendor’s own pricing page does not count. |
| Configurable billing | Buyer can configure how customers are billed — intervals, trials, proration, taxes, discounts or similar rules. |
| Payment gateway integration | Customer payments can run through a connected gateway so charges go to the buyer’s merchant account. |
| Client billing / invoicing | Buyer can create and manage customer invoices or billing records in the product. |
Localisation
| Capability | What we look for |
|---|---|
| Language localisation | The product can run in more than one language for customers or accounts, not only a translated marketing site. |
| Currency | Prices, balances or billing can use more than one currency, or the buyer can set currency per customer or account. |
| Time zones | Customer or account time zones can be set so dates, schedules and logs follow that zone. |
| Localised formats | Date, number and measurement formats can follow the customer’s locale. |
| Local payment methods | Customers can pay using payment methods appropriate to their market. |
Developer / Code
| Capability | What we look for |
|---|---|
| White-Label API | An API the buyer can use to operate Brand and Flexibility capabilities in a white-label customer offering. A generic data or reporting API is not this. |
| White-Label SDK | An SDK the buyer can use to build or integrate Brand and Flexibility capabilities into a branded customer application or experience. |
See the full White-Label Capability Framework for definitions and maturity levels.
Video requirements
The submitted video is the source material iwhitelabel uses to create the interactive walkthrough. It must:
- Show the actual product in use
- Map to Brand and/or Flexibility in the White-Label Capability Framework
- Include a voiceover that explains what is happening and why it matters
- Be hosted on an accessible platform or supplied in an accessible format
- Accurately represent the current product experience
Voiceover is required. Someone unfamiliar with the product should understand what you are doing, why you are doing it, what to notice, and what the result means for a reseller, customer or end user. Clear and informative matters more than polished production.
Keep branding limited. Light company or product branding is fine. Do not turn the demonstration into a promotional video dominated by logos, marketing slides, sales messages, company introductions or unrelated calls to action.
Do not add captions or subtitles. iwhitelabel prepares the demonstration for publication as part of the walkthrough.
What does not qualify
Submissions are unlikely to be suitable when the video is mainly:
- A company introduction
- A promotional advertisement
- A slide presentation
- Stock footage
- A collection of screenshots
- A generic product overview with no demonstrated workflow
- Marketing claims without showing the underlying functionality
From video to walkthrough
Record a screen video of the product, with a voiceover. That video is the demonstration.
You do not create the interactive experience yourself.
You provide the narrated video. iwhitelabel turns the approved recording into a walkthrough so readers can move through the process step by step, instead of only watching a conventional video from start to finish. The same video may also be used as evidence on your product listing.
Supporting content
Keep the email short. The video should do most of the explaining.
Include enough context for iwhitelabel to present the showcase accurately:
Product
What the product does, who it is for, and how it relates to white-labeling, reselling or rebranding.
What the demonstration shows
What is being shown, why it matters, and the relevant white-label or reseller use case. Note how it maps to Brand and/or Flexibility.
Demonstration context
Anything that may not be obvious from the video, such as configuration requirements, what the reseller controls, what the customer sees, limitations, or dependencies.
What you receive
Approved Product Showcase contributors receive:
- A dedicated Product Showcase on iwhitelabel, with an interactive walkthrough created from the submitted video
- The demonstration on your existing product listing, where appropriate
- A lifetime 25% discount on iwhitelabel purchases, including advertising, featured placements and other eligible promotional products or services
- A do-follow link to a relevant website or product page
The listing holds broader product information plus the demonstration video. The showcase holds the capability demonstration plus the interactive walkthrough.
How to submit
- Record a screen video of the product, with a clear voiceover. Use the White-Label Capability Framework as a reference so the demonstration maps to Brand or Flexibility.
- Email the video link and the details in the template below. You do not need to build the walkthrough yourself.
- For approved submissions, iwhitelabel creates the interactive Product Showcase and, where appropriate, adds the video to the product listing.
Send the email to care@iwhitelabel.io.
Editorial guidelines
iwhitelabel may make reasonable edits to grammar, spelling, formatting, headings, clarity, structure and consistency with directory terminology. We may request clarification when a capability or claim cannot be understood from the submitted video.
We may reject or request changes to submissions that are primarily promotional, misleading, irrelevant to white-label software, poorly demonstrated, substantially duplicate existing iwhitelabel content, written mainly for SEO rather than readers, or unable to provide an accessible demonstration.
Before you submit
- My product is relevant to white-label software, reselling or rebranding
- The demonstration maps to Brand and/or Flexibility in the White-Label Capability Framework
- My video shows the actual product in use
- My video includes a clear voiceover
- The demonstration shows the product rather than simply describing it
- I have provided enough context to understand the demonstration
- My claims accurately reflect the product
- My video is accessible for review and embedding
Email template
Subject: Product Showcase — [Product Name]
Product name:
Company / contact:
Product website:
Video link:
Existing iwhitelabel listing (if any):
Preferred link for the showcase:
What the product does:
[Short description, who it is for, and how it relates to white-labeling, reselling or rebranding]
What the video shows:
[What happens in the demonstration and why it matters]
Maps to:
[Brand and/or Flexibility area]
Context not obvious from the video:
[Requirements, what the reseller controls, what the customer sees, limitations or dependencies]