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...

Scio Consulting Partners with Apprenda for Rapid SaaS Product Enablement

It is now official, Scio Consulting has partnered with Apprenda to offer SaaS enablement services using Apprenda’s cloud OS “SaaSGrid”. You can read more about the partnership on the company blog and you can read more about SaaSGrid here.
Among other things, that platform is built with SOA in mind and will allow us to not only build ASP.net Ajax applications but Silverlight and Flex RIA leveraging WCF services. And all that without having to worry about billing, multi-tenancy, subscription management and so on, as those are bundled with SaaSGrid.
So well, expect to see, reviews, tutorials and code samples soon…

Why SaaS needs RIA

Softwares sold under the SaaS model are usually web applications. I say usually because it may not always be the case as SaaS vendor Entellium demonstrated recently.
One of the things that SaaS vendors use to sell is the fact that the software is immediately available and that no install is needed. However desktop installs are now easier than ever and if the desktop application of your competitor is better in terms of UI and/or functionality, the choice will be simple.

Not only your UI should be Rich and easy to use to compete with the desktop equivalent but also to keep support costs as low as possible. Additionnaly, moving some of the processing to the client machine is a good thing in general, it makes the app more responsive and will save cpu cycles on the servers to keep hosting costs down.

Lately a lot of people are saying that SaaS is not a profitable business. It's partially true. Some vendors think they can build any software and sell it under the SaaS model and that it will work. Believing in this is like thinking that SaaS will turn any software into gold. However, take it the other way if your software is gold then you can potentially sell it under any model.

Welcome

As you may have have noticed, SaaS is becoming increasingly popular even though it's not really new. I've been working with SaaS for quite some time now along with Rich Internet Applications using all sorts of technology (Ajax, Gears, Flex, Air and more recently Silverlight).
Just following the trend, I am going to create yet another acronym "RIAaaS" which stands for Rich Internet Applications sold as a Service in the hope that this term will one day become popular just like SaaS, PaaS or DBaaS.
This blog is going to talk about RIA, SaaS and how they work together.