Development of a feature as a white label component for various customers

But what if a project involves multiple customers and involves the development of a feature that is to be integrated into multiple apps? These can be both existing and new apps. Every customer has their own ideas about how the feature should be integrated or what it should look like. There may also be technical requirements, as certain customer-specific systems must be connected.

In the following, we would like to take a closer look at the challenges and a developed solution for the implementation of such a project recently carried out at Cap3.

Project description

The aim of the project was to integrate a feature in the healthcare sector into a customer's existing app and to develop it as a standalone app for various other customers. The apps use the same basic technological framework. In addition to the purely technical functionality requirements, a wide variety of UX/UI requirements were also formulated in the course of the project. For development, for example, it was necessary not only to enable the connection of various individual interfaces, but also to incorporate a wide variety of customer requirements for the visual presentation of the feature. Overall, this resulted in a number of project-specific requirements for the implementation of the functionality, which is due to the involvement of various customers:

• CI (colors, fonts, icons, animations, etc.) can be configured for every customer.
• Texts can be individually adapted for each customer.
• Connection of customer-specific interfaces.
• Optional additional sub-features for each customer must be possible.
• Different entry points to the feature (tab for an existing app or a standalone app).

The list is not complete, but it already provides an insight into the various requirements of the project.

Previous approach

In the past, a project with a similar scope and requirements has already been carried out at Cap3. Here, too, a feature was developed for an existing app and as a separate app for some customers. The implementation was initially carried out as a white label app in a separate repository. As the project progressed, this repository was then cloned for the individual customer apps and supplemented with the respective customer-specific adjustments. For another customer, essential components that describe the feature to be developed were copied into the existing app and adopted.

From that moment on, however, there was a difficulty as development in the white label app had not yet been completed. The customer apps therefore had to be synchronized regularly with the WL app, which was prone to errors and involved effort. Furthermore, the individual changes in the repositories of the customer apps had to be synchronized between them so that all apps were in the same state.

The following graphic shows the chosen approach and shows the additional effort required to synchronize between the individual apps.

A major advantage of this approach is that the wishes and requirements of individual customers can be implemented more easily in the apps without necessarily having to coordinate them with the other customers. Another positive aspect is the structural separation of the individual repositories. This prevents any misconfigurations from automatically affecting other customers.

At the same time, however, complexity is increased, which quickly becomes a problem in a small team and thus outweighs the benefits. Based on the experience gained and further considerations within the team, a new approach was finally developed, which enabled us to reduce complexity and avoid synchronization problems.

Module-based approach

A central component of the new approach is a module that provides the feature to be developed. It also offers all configuration options, such as for colors, fonts and texts, which are relevant for integration for individual customers. On the one hand, the module provides the feature as a complete app, but on the other hand, partial integration into an existing app is also possible. The entire development takes place within the module. The module is versioned and can be easily integrated into an app via a package manager.

To integrate the feature into a customer's existing app, the module can be inserted at a specific point in the existing navigation. For other customers, the module is integrated into a white label app as a complete navigation system. This white label app includes all configurations of the corresponding customers as well as a variant of the app for demonstration purposes. The app can be made available to a customer with one click.

The benefits of this approach are obvious. Changes and adjustments can be made at a central location. It is also ensured that all apps are built from the same code base and that changes are therefore automatically available to all customers. The development is also significantly less complex and requires less maintenance.

However, since development takes place at a central location, changes must be well communicated and coordinated. An important prerequisite for this approach is therefore that the basic structure of the feature is as uniform as possible. Any addition or deviation for individual customers should be carefully justified and considered in order to minimize the complexity of the module and to prevent any effects on existing functions and adjustments for individual customers.