How to Build a White-Label App
White-labeling a mobile app is a great option that many businesses choose for its affordability, lower level of risk than custom development as well as sufficient flexibility and customization compared to app builders.
Taking the rising demand into account, the number of white-label app providers started to increase as well. And it makes perfect sense — it’s less time-consuming, doesn’t take that much effort (if compared to custom apps development), and can be sold to an unlimited number of customers with little adjustments to each use case.
However, this industry is quite specific and may have some aspects that require a more detailed review. For example, whether it’s technically possible to make a white-label app out of an existing solution.
So, if you’d like to start providing white-label-related services, in this article we’ll try to cover all the important questions that might bother you so you’re all set for the development journey!
❓ FAQ on White-Label App Development
Even though the concept of white-labeling applications isn’t that sophisticated, there might be quite a few confusions. So, in this section, we’ll give you answers to some questions that you might search for.
Is it Possible to Make a White-Label App out of a Custom One?
Let’s say you already have a custom app. The question is whether it’s possible to build a white-label solution out of it.
The answer is pretty simple — yes it is. If you have a custom app, you most likely have full ownership of the app’s code
Thus, you can ask your development team to make a white-label solution based on this code. Even though it takes time and effort too, it’s surely easier than writing the code from scratch.
However, in this case, you would have to stick to the type of product that you have. For example, if you have a native app but want to build a white-label progressive web app, you won’t be able to reuse the code (unless it was built with React Native).
3rd-Party Integrations: Yes or No?
Actually, the answer here isn’t really about what you can or can not do — it’s more about whether it’s reasonable or not.
Many people choose white-label apps for their simplicity. If they need something more complex in terms of functionality, design, or technical infrastructure, they’re likely to go for a custom development since the price won’t be that much higher in this case.
If you decide that you want or need to enable a 3rd-party integration, it’s normally done with the help of APIs — an interface that has a set of tools for integrating relevant features in it.
With white-labeling, there are multiple options for how you can do it, and the choice is often not on you. Depending on which API you’ll choose, you could:
- Connect all apps to one account so the access will be mutual.
- Build a separate API access key for each app.
- Have several keys even for 1 client (for example, for iOS and Android App).
Do App Store & Google Play Really Delete Template Apps?
One more thing we wanted to cover is how app markets treat white-label apps.
There’s a lot of information going around that the so-called template apps are deleted according to guidelines — it’s especially relevant for the App Store.
We at Stormotion have been working on a project that helps to convert websites into apps and offers white-label solutions. So, from our experience, not even a single app was deleted in several years.
Yet, we’ve heard about the cases when apps got deleted. However, it doesn’t happen as often as people thought it would be.
What we can recommend here to avoid problems with the App Store or Google Play is to have as much design customization as possible. Not to change just colors, but offer different layouts, sizes, and shapes of components, etc. Further in the article, we’re going to talk about UI customization in detail.
🤖 Single- Vs. Multi-Tenant White-Label Apps
There are two types of white-label apps you can build: single-tenant and multi-tenant. The сhosen type will greatly define the scope of features, some technical characteristics of the app, and, thus, the development strategy and budget.
Let’s briefly review both options and take a look at their special properties. Additionally, we’ll give you some cases when a certain type of white-label app might suit you more.
Single-Tenant White-Label Apps
Single-tenancy provides a customer with a singular copy of a White-label product, which means that each client has a separate, highly customized (to an extent that’s possible in the white-labeling) application.
To build a single-tenant white-label app, developers reuse the backend code (if it already existed), but change the frontend of the app. In other words, while using the same technical architecture, the apps can have more UI customization options and a higher level of user engagement.
Single-tenancy has certain special properties that basically define the architecture and its difference from multi-tenancy:
- They have an isolated database on the server.
- More customization possibilities like additional features or structural changes are possible since they won’t concern other tenants. Basically, there are customization options in multi-tenancy as well, however, such architecture means that changes will occur in each tenant’s app.
- Tenants are free to choose to update the app whenever they want in the future since they’re not bound to any other tenant or server, meaning that updates don’t apply to them in any way.
When developing this type of white-label app, you should consider implementing the CI/CD (Continuous Integration and Continuous Delivery). CI implies updating the code in the git-repository, where special CI tools test and build it automatically. CD then is used to apply the changes to the actual app’s code on the server. Continuous here means that changes are deployed right after the tests are completed successfully.
If you are interested in such a setup, you can talk to your dev team or to us about it — we’ll fill you in on the details like price, time input, etc.
Also, we at Stormotion utilize Xcode to build schemes that help us provide different versions of the same code with minor adjustments in each variant. These Xcode schemes help to set up different customizable items: for example, app name, app icon, bundle ID, info.plist file. The same feature in Android Studio is called “Build Variants”.
However, you should pay attention to the fact that the more apps you will have, the more resource-consuming it will be to introduce any new updates.
Multi-Tenant White-Label Apps
The alternative option is multi-tenancy. This Saas model (Software-as-a-service) supports more users (tenants), and while the UI design of such apps is adjusted, the underlying platform remains the same for all tenants.
In this case, there is one server that hosts the software and stores customer data. Multi-tenant apps are usually a more popular choice simply because compared to single-tenancy, they’re an easier and cheaper option for companies. However, this means that all activities like updating, breaches, etc., are applicable to each app on the server.
Just like in the previous case, customers can customize features or design elements. However, here providers focus less on customization and personalization but more on quick development and cost-efficiency.
Thanks to a single configuration of these apps, maintenance, QA & testing are much faster. Additionally, you as a provider have only one application — bug fixes are also automatically applied to all of your tenants.
Since it’s likely that with the multi-tenant architecture of your white-label app, you’ll work with multiple clients at once, you can make it easier for both you and them by making a tenant onboarding guiding set, which can include videos, text guides, support specialists that will walk clients through each stage of the onboarding, etc.
Furthermore, if you choose multi-tenancy, we dare assume that you’d like to cover a bigger audience and not focus on UX (features, integrations) customization that much. This is why it might be a good idea to define what functionality and terms of coworking will be customizable in advance and place it somewhere on your website, landing page, or whatever it is you have.
This way, potential clients will know what to expect and, perhaps, will prepare questions about whether additional changes are negotiable or not — it can save both of you a lot of time.
It’s also essential because the list of customizable elements in such a model is normally limited to the ones that you’ve enabled at the development stage. In other words, your tenants can easily change a logo or a color palette but can’t do the same with a page layout or some specific features — unless you as a provider foresaw and made it possible when building your white-label product.
Single- & Multi-Tenancy: Use Cases
So, let’s briefly review some use cases when it might be more suitable for you to opt for one of two options.
You should consider multi-tenancy if you are planning to:
- Target and work with a wide audience in little time.
- Focus on providing more affordable services by reducing customization.
- Target small- and medium-sized businesses, start-ups, companies that need a fully functioning MVP, etc.
- Provide an easy-to-launch product rather than focusing on covering each detail and take a lot of time to perfect it.
And single-tenancy might be a better match to those who want to:
- Have not that many clients but have a long-term partnership with most of them.
- Provide an experience close to a custom one.
- Work with companies that have a higher budget and want to update or modify the app in the future.
- Pay more attention to the consistency of the products with a client’s brand or other existing solutions.
These were the main aspects that you should know to be able to make an initial decision. To deepen the understanding of your idea and its technical implementability, you should ask your tech partner to tell you about other app architectures since single- & multi-tenancy themselves divide into types as well.
✅ White-Label Apps Customization
Since the main concept of white-labeling is reusing the backend for a big part but customizing visuals to make it branded, it’s essential to talk about how you can enable it in a customer-friendly way.
Splash Screen & App Icon
The first thing your clients’ users will see is the splash screen. That’s why it’s important to pay a lot of attention to its customization and provide rebranding options.
Splash Screen can be assembled by using either images and logos that represent the main message of the brand and is consistent with it or an introductory animation.
Additionally, you can offer clients to add widgets or animation so that onboarding will be as custom as possible.
You should think out a couple more aspects as well:
- Will you allow changing the layout of logos and images, in addition to changing colors?
- Are you going to limit the set of customizable splash screen elements to what you offer or allow users to upload their own ones?
- If you offer to place a video on the splash screen, what the time limit is, what size the video can be. Moreover, you should think about screen adjustment since each has a different size - it can be easily enabled by using certain tools that your development team is most likely aware of.
Regarding an app icon, the concept is similar. You can offer to change the color, provide a wide range of icon construction kit elements so clients can make it in case they don’t have it yet, and allow them to upload their own icon design.
In-App UI Elements & Colors
To make the app as custom as possible and still keep all the benefits (like cost-efficiency) that make white-label apps demanded, you can make in-app UI features adjustable. This usually includes colors, fonts (type, style, size, position, etc.), and spacing.
Let’s review the coloring system in detail. Normally, white-label app providers offer a convenient and easy-to-use two-level color system. It means that there are two color pallets that are responsible for different parts of the app — let’s call them primary palette and secondary palette.
The primary color palette is used to change the color of the app’s main components like CAT buttons, action icons, links. Here, it’s not reasonable to limit the color choice since you never know what a customer might need.
However, what you can do is to ask your client what colors they’ll need and simply add them, without having to burden the app with additional ones that they’re not likely to use. If they prefer to have the whole palette — so be it. Furthermore, you can allow them to change the shades, saturation, brightness, transparency, etc.
The secondary palette is responsible for coloring most backgrounds, sections, etc. Here, you can add basic white and black with several shades from lighter to darker tones. This palette probably won’t be too heavy in terms of data so there’s no need to exclude some of them even if clients think that they won’t need it.
App Components & Templates
Components, in this context, include titles, CTA buttons, regular buttons that help users navigate the app, and other parts that form a screen.
Some designers also divide them into primary and secondary. For instance, a primary button would mean a bigger size with more distinct UI elements.
Secondary would mean that these are less important, thus, they’ll take up not much space and can be less distinct if needed. Surely, it’s up to your clients, yet, we’d recommend not having more than 1 primary button on the screen to not confuse users.
It might be a great idea to allow clients to customize components by changing their:
- Font & others.
Furthermore, you can offer optional screen layout templates, where you’ll give some ideas on how to structure the screen (where to place components, and so on). It makes the approach more user-centric since clients won’t have to design screens from scratch but make little adjustments and, thus, save time.
⚙️ Technical Aspects of White-Labeling
When providing white-label app services, there are a lot of technical parts of the workflow that you as a provider should be aware of. So, in this section, we’d like to draw your attention to them.
Server Choice & Error Monitoring
Depending on your white-labeling architecture model, you’ll have to handle the hosting of your clients’ apps, which often includes providing the server and technical support.
Talking about the server, you should think about where you’ll buy a place. The most popular options among white label apps are Google App Engine and Amazon AWS. They basically lift off the necessity of finding a server, plus, offer a bunch of different benefits like security ensuring. This 1-minute video represents how it works in detail:
We would recommend opting for Google App Engine since they focus on applications specifically, but surely, the choice is up to you.
Another important aspect is reporting and fixing bugs. In fact, if you use hosting providers that offer a wider range of services like Google App Engine, it’ll likely be included in your subscription package.
When using such services, you can tie all apps up to a single account and tag each one of them. So, when the error is being reported, you can track down which app caused it. If it’s a general issue on the server, it can be labeled accordingly.
We were talking a lot about how and what can be customized when providing white-label services. Now, we’d like to give you some tips on how the customization can be simplified and made more user-centric.
To easily manage the customization, you can build a client dashboard where both they and you have access to the app’s components.
In this way, next time they want to change color, make a button bigger or update the content, instead of asking you they simply open the dashboard and customize the UI themselves.
However, if you want to have full control over this process, you can simply build the dashboard for yourself, have all tenant’s apps stored in one place, and easily make adjustments on your own.
💰 What Affects White-Label App Development Costs
When planning the development process, one of the most important things is budgeting the project. We can’t tell you the exact cost, however, some aspects need to be taken into account to make budgetary planning and cost prediction as precise as possible:
- Number and complexity of features. Plus, the more features you want to be customizable, the higher will cost be.
- Your choice in terms of single- or multi-tenancy.
- 3rd-party integrations.
- An hourly rate of your development team.
- Whether you’ll use services like Google App Engine & others.
If you’d like to know a more or less precise cost, you can contact us to discuss your use case!
So, white-labeling apps is quite a business to do — there’s a lot to take care of, but the benefits and demand are worth it. Now that we’ve covered all important aspects of the development, we hope that it has become clearer what steps you should take to start such a business.
Let’s briefly sum up what steps you should take to build a white-label app:
- Choose between single- & multi-tenancy.
- Decide on what UI/UX features will be customizable.
- Set up a UI/UX customization dashboard.
- Choose a server.
- Enable error monitoring.
We, from our side, would recommend you finding a great tech partner who could walk you through each essential detail and find the best way to put your idea into practice from a technical perspective.
If you need any help with the development, have questions left, or want to share your thoughts on white-label apps with us, feel free to reach out!