White Labelling is a great option for selling your application or platform and if you want to use this product strategy, there are several options for delivering it to market, each with their own pros and cons.
In this article I describe what white labelling is and how you can implement it within your systems in the way that best suits your requirements.
White Label Products
A White Label product is one that is typically unnamed and allows your client to sell it as their own by giving it their own name and branding.
Advantages
Having someone else sell your product under their own brand and name may seem not seem like good business. However, there are advantages to this strategy :
- Your client is an organisation that does not promote particular brands, such as government agencies.
- It can raise the barrier to entry for competitors by making it harder for them to break into the, apparently, crowded market place.
- Your market can be expanded through the use of clients who are already in particular market segments.
- You can focus on your core strengths without having to worry about marketing and sales.
This last benefit is particularly important for start-up organisations that may not have the skills, experience or bandwidth to sell a product. Your focus can be on making the best possible product and, if appropriate, you can also supply managed services to your clients to look after operational aspects.
Disadvantages
Selling a white label product also comes with a down side and this must be balanced up against the advantages to work out if it is right for you.
- Moving to a wholesale model means that your revenue per user is likely to be lower as your client takes their ‘clip of the ticket’, which is their portion of the revenue.
- Sales and marketing is not removed entirely as you must now sell your solution to potential clients as a wholesale product.
- The impact on your systems and on your cost base can be large and you can find yourself struggling to maintain the margin you need.
Technical Impact
If you decide that white labelling is right for you, then you will need to consider the impact to your technical solution.
When it comes to white labelling your product, the solutions broadly fall into three categories:
- Multiple Instances
- Customisable Accounts
- Multi-tenancy
Before selecting a category, you should understand how each of these solutions impact your development, hosting costs, maintenance costs, billing model, security and feature set. The right solution for one product may not be right for another.
The higher the impact, the higher the costs to you.
Development represents the effort and complexity of the code that is required to deliver the white label solution.
Hosting Costs reflect the cost of the cloud-based servers you need to deploy your product to. In some solutions you may need more servers and in others you may need bigger servers or more compute cycles if serverless. In each case, your hosting costs increase.
Maintenance Costs are driven by the cost of fixing defects and user support. Some solutions have lower maintenance costs than others.
Billing Model refers to the way in which you and your clients are going to charge the end user. Depending on how you charge your client and how your client charges their end customers, you may need to look at additional development.
Security covers the identity of the users. In some cases a person may need to have a single account across all your clients and in others they may need to have separate accounts. In both cases you need to consider how you ensure the separation of the data held by each of your clients on their users.
Feature Set is a key consideration and goes further than simply branding, colours and icons. It also covers which features of your product each of your clients offer to their customers and users. This can quickly become very complex and expensive for your product depending on the solution you choose.
Below I look at each category, explain how and when they should be used and give them a star rating against each of the factors above.
Multiple Instances
This is the simplest of the categories to implement and is typically the first solution that people think about when implementing a white label product.
Multiple instances means that each time you sign up a new client, you actually deploy a new copy of your product specifically for them. This is truely a white label product and avoids many of the technical complexities of the other solutions.
When you deploy the new instance, you can give it its own URLs, its own emails, its own payment gateways and charging. You can provide any mix of features that your client requests.
Development – Low
As each instance is simply a copy of what you already have, the cost of additional development is limited to deployment tooling and some level of configurable customisation.
Hosting costs – High
Each instance will require deployment of additional cloud services which will increase your overall costs, especially when the client has few users.
Maintenance costs – High
Maintenance costs are dramatically higher with this category of solution. Whilst the aim would be to keep a single copy of your product and then deploy to multiple instances, there are many reasons why this does not happen and you end up with multiple versions:
- Clients insist on different feature sets to distinguish them from other clients.
- Clients do not agree to upgrade their instance or want deployments delayed leading to multiple versions in production.
- The need to context switch between instances when providing support to different clients.
Billing Model – Low
Separate instances means that you can easily enable different billing and charging models for each client, understanding that this will increase the cost of maintenance and operational support.
Security – Low to Moderate
Separation of instances gives the highest level of isolation between client’s data and user base. Costs may rise if security issues must then be investigated and solutions rolled out across all instances.
Feature Set – High
As each client is deployed separately, it is possible to provide totally different features sets for each, understanding that this will increase the cost of maintenance and operational support. The ability to do this will, in itself, lead to multiple versions across your clients.
Overall
Multiple Instances should only be considered where the client requires separate instances for security reasons. It should be used sparingly as the maintenance and operational costs become prohibitive. Wholesale pricing should reflect these additional costs.
If an urgent need arises for a white labelled product, this is probably the best way to deliver a solution.
Finally, this solution can be considered when integration to existing client services is required.
Customisable Accounts
With this category of solution, your product allows a client to create an account on your platform and then allows them to configure look and feel of the product for their particular use. Depending on the requirements, users either create an account on the platform and join a client’s account or create their account within the client’s account.
Development – High
Building a platform that can accomodate users across accounts is complex and increases business logic and therefore the testing costs. If this type of platform is required, it is advised that it must be built with this in mind from the beginning.
Hosting costs – Low
As there is only one instance being used, it can be deployed efficiently at the lowest hosting costs. You will not be wasting services keeping platforms available when a client has no users.
Maintenance costs – Low
In the same way as hosting costs are optimised, so are maintenance and support costs. There is only one platform, one copy of the deployed product and one user database to support.
Billing Model – High
As there is only one instance of your product, you will have centralised charging and billing. This will require the ability to manage different plans for different clients and their customer. This can become an operational support problem. Clients who want charging and billing outside of the norm, will also introduce development, maintenance and operational costs.
In this category of solution, it is likely that you will have to manage charging and billing on behalf of the client to ensure separation of client interests.
Security – Moderate
With one instance, problems can arise when a given user want to use services from different clients on your platform. You will need to consider how their identity and data are managed.
There are situations where your clients may actually want a given customer to have access to multiple clients with a single identity. Examples include consultants that may service the same customer.
Feature Set – Low
With a single instance, the ability to customise the user experience for each client is limited. As the level of customisation is increased, you will see an increase in development costs.
Overall
This is not a true white label product. You are effectively selling a platform that clients can use and then configure for their own purpose. However, when your client are cost sensitive or when they want a customer to be able to be serviced by multiple clients, this would be the solution to select.
Multi-tenancy
This category is the most complex from a technology perspective. It gives the illusion of separate instances whilst managing it all from a single instance.
True multi-tenancy effectively builds walls from the top to bottom of the solution stack, ensuring separation of your clients data and possible feature set. Depending on the level of security required, you may be able to share certain components, such as the database, which would lower costs.
By deploying a multi-tenancy solution you get the majority of benefits from the multiple instances category without its cost drivers. You can now have clients with few users at a minimal cost to the product overall.
Development – Moderate
When developing a multi-tenancy solution, you need to create a template for the services that you offer that will ensure you get the separation you require. Retrofitting multi-tenancy is not advisable due to possible leakage points in the solution.
Hosting costs – Low
If the multi-tenancy solution is implemented efficiently, it is possible to get the lowest services usage for a white label product against all categories.
Maintenance costs – Low
In the same way as hosting costs are optimised, so are maintenance and support costs. There is only one platform, one copy of the deployed product and one user database to support.
Billing Model – High
In order to appeal to a large number of clients, you need as much flexibility in your product as possible. You also need to consider how pricing plans, discounts and promotions are managed, all of which your clients will want to do themselves. This gives rise to high development, maintenance and operational costs.
Security – Moderate to High
Ensuring segregation of the clients can be challenging and requires careful security testing. You also need to consider what happens if a user wants to access your products through two different clients. These considerations can lead to extended costs.
Feature Set – Low
With a single platform your clients will need to abide by the ‘same features for all’ rule. Now feature development can be done for all clients, lowering the overall cost. Testing is a little higher as there will be a need to test the multi tenancy nature of the feature.
It is likely that clients will want their own features and you may need to consider the ability to build pluggable features into your product to meet individual needs. If this is done, it is expected that the additional costs must be borne by the client requesting them.
Overall
Whilst many people see multi-tenancy as a good compromise between client flexibility and the high cost of individual deployments, it does bring in a number of security and separation requirements that make life difficult.
Branding
Before I highlight my conclusions, branding of the white label product needs to be considered. You may think that bring of a white label product is meaningless, however, the solution you pick will have different impacts on the branding equation.
Even with the whitest or white label products, you still need to sell it as a wholesale product. Whilst the end-user may never see the name, you will need to refer to it and to market it.
Branding does not only look at the logo on the front page or the name. It also covers colours, text, language and other things (internationalisation is another but related topic). But it also covers URLs, email domains and error messages. Creating a truely white label product may not be possible and you may need to have a grey label product.
Typically grey label products are identified by their ‘powered by xyz’ tag line. By advertising that the platform is powered by another product, it makes it more acceptable for your brand to leak in to the clients world. As a client, by using a grey label product, you can reduce your costs whilst still retaining your own branding.
Conclusion
Offering your product as a white label product is a valid strategy that can expand your markets, lower your costs and allow you to focus on what you do best.
There are three main categories of solution and whilst the overall impact of each is more or less the same, individual impacts can vary greatly.
If you ask me which category of solution I recommend, like all advice, I must clearly reply with ‘it depends…’
Unless you have a large client who demands their own instance, you should keep away from multiple instances as this can drive a high level of costs. With large (and few) clients, your wholesale pricing needs to reflect the increased costs of development, hosting and maintenance.
If you are offering more of a market place product whereby the same user may be involved in the service provided by multiple clients, then it is advisable to consider the custom account solution. This solution works well in this scenario but does come with more complex security requirements and testing. To go down this path, you should architect your solution from the ground up with this in mind.
Multi-tenancy is often touted as the way to go, reducing your hosting and maintenance costs. However, this is not a valid reason for blindly accepting this solution. With a large number of users and decreasing cost of hosting, you may find that the overall costs are similar to multiple instances in the long run. If you want to market wholesale services as independent services and you are at the start of your development, then you should select this solution.
In the majority of my product developments, I tended to use the customised account solution as this has the greatest flexibility, which is important when starting out as you may not know where the market will drive your product.
If you would like to understand more about how to implement a white label product, book a confidential, obligation-free consultation with me here and we can discuss your ideas.
website: requillion-solutions.com.au