HN Explorer

Ask HN: How do you handle white-labeling product from a technical perspective?

6 points by bradleyjoyce ↗ HN
My company provides a service to large commercial real estate companies that has both a mobile app client as well as a web app client for utilizing the service. Many customers and prospects are asking us for the ability to white-label everything so they can maintain their branding. We've resisted this so far, but the requests are getting to the point where we need to seriously consider going down that road. My question to you all is, how do you handle the white-labeling from a technical standpoint, especially when it comes to code management and release management? Thanks in advance for any insights/tips.

7 comments

[ 5.6 ms ] story [ 20.2 ms ] thread
amk_
Disclaimer: I've never done this before, but this is what I'd do.

Approach branding in the same way as internationalization. Instead of hardcoding strings, reference a config file that translates the logo/brand names/color scheme for the specific deployment. Look into how Shopify does this for their customers.

bradleyjoyce
yeah something like that is decently easy on web... I think it may be a more significant challenge on the Mobile side. I'm also curious about things like... should we have 1 github repository for the base app and then branches for each customer, or some other type of code management setup.
joshschreuder
I haven't done this for mobile but have done for web. I imagine for mobile it becomes part of yout build process? Eg. Your build runs and looks for a config named like the client name, from there you swap out designs.

For Github we had the base app in one repo and client apps in their own repos. This was more out of necessity as we had different clients on different versions of the product / with their own custom functionality.

brianwawok
That's not a good use of branches. A live product shouldn't need to pull in 100 branches.... Just keep it simple, a directory called branding with a subdirectory for each client. Ideally shouldn't be code, just assets and maybe a simple css or color file.
aspratley
I've done this on a small scale for web, never for mobile/apps though. My approach was a git repo containing the main code then a branch for each brand which only had config changes. It works ok but gets difficult to manage once your size grows - it's essentially using git as the build tool.

If I were to do it again I'd likely not use the branches for branding config, but keep them all in one place and use a build tool to make sure the required settings are in place and merged before deployment. As long as you tag your releases you can fix certain clients to certain releases.

Make sure you talk to your clients about what their branding requirements are. Some companies get very very specific about what they 'need' and as soon as you offer the ability to customise something they can get irritated if their brand doesn't look quite right. As others have said make all of these customisations part of a config file and just reference that in your code. Once you start making specific changes for a client your life becomes difficult and you end up managing a specific bunch of code just for them.

You didn't say if the white labeled app would be a public download of it it's intended for company staff. If it's the latter you can probably have a single app that gets configured on the first start up, i.e. it's blank when you open it, sign in and it pulls in the required config and then takes on the customer's brand.

gonyea
You'll have to. Stop resisting. Follow the money and build a platform others can use and the company can sell.

White labels are fairly easy. As another poster mentioned, use internationalization tools for branding language. Create layouts specific to each partner and namespace assets in a folder.

Setup a subdomain for each partner and you're done. It's not hard at all if you're using a framework like Rails.

koichirose
We've been doing this for a while for a website that receives not too much traffic:

- we use a single server and the domain name determines which white label we are on.

- we use LESS and everything is variable. We load a single compiled CSS based on the domain.

- we never hard code anything, unless we know it's a single page for a single domain (everything is internationalized).

- the database contains everything and we filter out stuff a particular white label doesn't want.

This is because the website displays content (it's not a service like shopify) and most white labels want most of our editorial content, so syncing DBs is not an option (is it?). We have 40+ white labels and unless the customization is heavy we can create a new one in a matter of minutes.