SaaS in the Company Cafeteria
For the last couple of weeks, there’s been a lot of debate in PK4 – about the lunchtime catering contractor (we discuss actual work-related things too, but maybe not with such strong opinions!). People have been getting tired of the predictability of the previous vendor’s menu, so we brought in another vendor today: a restaurant down the street. The food was different, good but inadequate. When he ran out of the fancy curd-rice-with-seasoning, the guy behind the counter mixed curd and rice and doled that out, much to the consternation of late-comers. When he ran out of the pulao, he just removed that serving vessel… you know the drill. So basically, the later you went in, the worse the food was. And that leads me to the comparison with SaaS – I do mean Software-as-a-Service, not Tulsi Virani messing up the food.
As a restaurateur, the new vendor is used to creating lots of dishes, but in small quantities all day. As a catering contractor, he’s got to churn out 500 meals every afternoon, but with at most ten items. To me, that’s the big difference between building a web-app and building a SaaS app: the focus on Variety and not Volume. Putting together a regular app that fits the needs of a specific group of users takes a particular set of skills. And once the app is built, you cut CDs or whatever and send it out, so people can install and use it. Every time you ship a release, you can go focus on the next function to build, since your users will deal with issues like the current one not installing, running slow, etc. With SaaS, though, the issues are all yours. With every new feature, user experience is important, but as important is the time it takes to execute, the resources it takes on the server, the impact it has on the database and so on. So instead of delivering a whole lot of functionality and not worrying about how it’s used, SaaS vendors typically build a base set of functions that’s very strong and scalable, then go on to adding more stuff. So while the non-SaaS vendor focuses on variety, the SaaS vendor builds for volume.
The new generation of SaaS vendors have broken through other barriers that in-premise vendors haven’t even begun to consider. Mass customization in the software context is one example, where a single app connected to a single database is made to look and work completely differently for different customers. With Impel, for example, we have small three-person companies logging in from Srinagar and Varanasi, while 200-person companies log in from all over the country. And they all see configurations of Impel that are specific to their own businesses. These configurations are not just field-name changes – they actually change the way some transactions operate. On our Call Center screen, for example, some customers want a change to data in a specific field to automatically kick off an email to a manager, while others want a pop-up screen that shows over a hundred data elements from multiple tables. Each function is critical to the company that uses it, but as far as we are concerned, both functions are delivered from the same Impel app cluster, with the same speed of delivery. So we are now able to very heavily customize for each customer an app is essentially built to be used by tens of thousands of users. That’s like saying that, while the catering vendor delivers 5000 lunches at one shot, s/he can also make sure that one diner gets food that’s less oily, say, than another. Now that would be a business that would eat everyone else’s lunch, so to speak!
