How do I white label a SaaS solution?

Question

I'm building a SaaS product, and one of the top customer requirements is that they be allowed to white label it.

• Customer domain
• Include customer logo in UI
• Change color schemes to match customer branding

Of everything that needs to be done, I think the easiest part for me to grasp is setting up the custom subdomain (I'm running on AppEngine, but it's pretty straightforward on any server setup).

My main questions revolve around best practices on the front end styling. My setup requires for me to define colors both to overwrite CSS rules and to overwrite Javascript variables. The assumptions I'm making are that I am storing any image assets / paths and color information in the database. These are the two paths that I'm considering, but both seem to have pretty serious flaws.

1. Deployment task - Before deployment, run a Grunt (or other automation) task that pulls customer styling information from the database and creates custom CSS / JS files per
2. Runtime - During application bootstrapping, pull customer info from db and overwrite styling dynamically (inline styles, JS overrides, etc)

I've looked a lot for recommendations or other experiences and have come up empty. What are best practices for white labelling? Should I continue down one of these two paths or is there a better option? What pitfalls should I be aware of? Are there performance implications for the different options?

This question is purposefully language and framework agnostic, as the basic principles should be the same, no matter how it is implemented.

Answer 1

I have implemented this before using LESS:

We first updated all our CSS files to use LESS. All the necessary colours that will change on a per customer basis used LESS variables. We called the main less site file 'main.less'.

When a user logged into our system it would grab the information relating to the customer's theme from the database and convert it to LESS variable notation. It would then grab a copy of the contents of main.less and prepend the client specific less variables to it, then write this to a client-specific .less file (client-a.less). Then our system would compile it into a css file (client-a.css) that our system then included in each page request (our system would know what the compiled css file will be named based on the client name, for example).

This method will result in a unique .less and .css file being created for each client and will mitigate any need to call client specific theme details from the database every time a page is requested, as this compilation process only takes place upon each login.

You can save further server resource by serializing the compiled less file (client-a.less) and storing it as a .cache file. Now, when each user logs onto your system, you can serialize the content that is due to to be compiled into client-a.less, compare it to the .cache file and if different go on to compile the client-a.css file. If there is no difference then no need to compile the css file.