When building a hosted/SAAS application, how do you manage multiple versions when customizations by the customer are allowed? [closed]

Question

Let's imagine you are building a Calculator application. You will allow customers to customize this Calculator with their own logos and CSS stylesheets. Customers will point their domains to your hosted Calculator and the application will serve up the correct theme for each customer. For example:

• www.AcmeCalculator.com will serve up the Calculator with the Acme logo, and a bland corporate style they created.
• www.HellzCalc.com will server up the Calculator with some Hell's Angels biker signs and a black, blood red theme they created.

You've pushed out Calculator 1.0 and everyone has written their styles to work on this version.

Next month you are ready to release Calculator 1.1 which added a new feature, let's say "Scientific Mode" which required you to add some new UI - HTML in this example - components. This means if you push out 1.1, you will break some of your customer's styles.

The best solution I've come up with is that you keep multiple versions of your application running. For example:

• www.AcmeCalculator.com resolves to your app server, which checks the version Acme is currently on, and forwards to www.AcmeCalculator.com/1.0
• www.HellzCalc.com resolves to your app server, which notices that they are running on the new 1.1 version since they went in an updated their CSS to work on the new version and clicked the "Finish Upgrade" button or whatever, so they get redirected to "www.HellzCalc.com/1.1

One problem with this system is that you'll inevitably have lazy customers who never invest in upgrading. You'd be running 200 versions concurently, trying to fix bugs in each of them, basically going insane.

One solution would be to use part of your monthly hosting fee to employ a "UI Migration Team" which would be a group of designers whose only jobs is to constantly take clients in the queue running the oldest versions and tweak their CSS and validate them to run on the newest version. This would allow you to support only X versions concurrently, where X is a function of how much money you invest in the UI Migration Team, adding resources to speed them up or slow them down.

The same idea would work with database changes: Calculator 1.0 and 1.1 runs on database 1.0, but Calculator 1.2 runs on database 1.1, etc. You could just add schemas with version names, and employ a similar "Data Migration Team" to move data from schema 1.0 to schema 1.1, finally deleting schema 1.0 when no (app) clients are left.

I'm sure this type of problem has come up before, and I'd like to see how other have solved it. Perhaps there is even a "best practices" for this.

Answer 1

Unless you are in the enterprise space and your customers require significant customization of their app and you can charge them accordingly, I'd avoid this. As you're discovering, this is the tip of the iceberg of a product management nightmare. One of the reasons SaaS has become so popular is that it is very difficult to manage different people on different versions, and it's hard to get people to upgrade.

Having done this a few times (I'm a product manager by background, not an engineer, so I probably feel the pain nearly as bad as the engineers having to implement), I would suggest having configurable parameters. Often you can charge extra money for this type of configuration. That is, the base price comes with little to no customization, and higher tiers allow CSS customization, branding, etc. See JobScore.com for an example. A good reason to charge money for this is that smaller companies don't care and won't pay, but larger companies want the feature and won't care as much about the cost. Getting this sort of price premium is critical for a successful SaaS product: Most SaaS companies make 80% of their revenues from the "enterprise" version of their product, so you need to price accordingly. If your top tier is $99/mo and WalMart signs up and uses it for $99/mo across their entire company, you're leaving a lot on the table.

Anyway, back to the original question: don't allow different versions, that could literally kill your company. Instead, offer configurations/variables.