Saturday, January 31, 2009

SaaS Customer specific modifications - Lessons learned

After various years of maintaining SaaS applications, I've learned various things, one is that you sometimes have to add feature(s) just for one customer. Some will say that you should avoid those at all costs as it breaks the economy of scale but small SaaS ISVs sometimes do not have a choice if they want to stay in business.
37 signals explained that you should be careful to not let your customers drive, they mention that many people have been asking for Gantt charts in Basecamp and that the answer has and will always be no because it's not aligned with their view of how project management should be handled and how their software should be used. I could not agree more...

Now, if you do have to add a small feature for one customer, you might be tempted to add that feature in a "quick and dirty" way. Maybe hard code it based on the tenantID or add the setting to the database but do not create a UI for managing it, to try to save on development costs. I'm sure you'll have pressure coming from the sales person that want that feature right away and at the same time a tight budget.
So when that happen and you start to think about hard coding, think twice. First, because that feature will be buried into the code and the QA team will have to remember that this feature is enabled for that Tenant only, not to mention that in your QA environment you'll have to create that special Tenant to be able to test the feature. Second it's easy for a developer to break that feature without noticing and if you're not so lucky, your Unit Tests and QA team could let the problem slip up to the customer.
Adding the setting to the database and managing it just like any other feature but without a UI can be seen as valid and less problematic but still your QA team will complain and might end up forgetting about that feature (intentionally?)
After some time, I've seen how many of those custom features ended up becoming real features used by multiple customers (I'd say maybe 30%), so always take into account that maybe that feature will be enabled for multiple tenants/customers and also take into account that maybe that feature will disappear either because the customer that asked for it left or simply because he is no longer using it. I'll even recommend running a poll if possible to try to determine if that feature could be valuable for another customer either as-is or with some slight modifications.

Interestingly, the customers asking for special features are usually the same and somehow when your company granted them one, they suddenly think it's always going to be that way and tend to ask for more and more up to the point where the number of custom features you've added for them outgrow their value and you have no other choice than to let them go knock the door of a competitor.

Some customers may have developers handy and may start asking you to open up your API more and more. Be careful about that too as at some point you might end up building a platform which is usually not your area of expertise.

At the end of the day, what you need to remember is that you should add features the right way or let the customer go. The ROI is not always clear and more than once you'll end up spending on a customer that will leave anyway...