One other idea about SaaS and VC that was recently voiced (I wish I could remember the contributor) was that a typical SaaS growth rate is so consistent and a relatively low risk that
a) A SaaS start-up that has a very steady growth rate can generally sustain itself on recurring cash stream, founder infusions, and loans, and so does not need VC infusion
b) SaaS risk, growth rate, and the corresponding rate of return does not warrant VC’s interest.

It seems like a logical argument and may certainly hold true in the instances where a SaaS shop can sustain itself with some regulated internal and external cash infusions. For these SaaS companies, cash infusion does not equate to substantial growth and does not justify the loss in ownership.

However, that is not always the case. A SaaS start-up incurs high maintenance costs while it is building out to maintain the high security and uptime that do not increase in line with the customer base. In other words, a SaaS vendor may not have the advantage of economies of scale for some time after launch and may need substantial capital to keep up and running until that is achieved.

On the other hand, there are SaaS companies that are growing much faster than overall SaaS industry rates and those companies would present more that acceptable returns to the investors.

In a recent conversation with a later stage private equity firm, I got the perception that the investment community in general is aware of these factors and is ready and waiting for the SaaS market to mature on its own terms.

David Linthicum makes a good point (and a very dramatic one) about VCs getting overexcited and jumping on SaaS like a pack of wild dogs (vivid visuals here) without truly discriminating their potential which is bound to result in some disappointments down the road.

It is true that some VCs could be getting antsy hearing much of the similarly spectacular hype-talk. But the truth remains that many still remember the painful lessons of the early 2000. SaaS may sound like a way of life in a tight SaaS evangelist crowd but the general public still largely lacks awareness, and VCs must (hopefully) be aware of it. Finally, exciting as it may be SaaS model requires has some buying into from the companies used to traditionally lower IT overheads, occasionally lower breakeven volumes and lucrative maintenance contracts enjoyed by many of the enterprise players.

As was explained to me by one VC company, SaaS has “huge, recurring IT costs, requires hoards of clients to break even, and maintenance eats up the rest of the margin”. I don’t think it is quite as bad, but to be fair, these are valid concerns that are true to the business model in general. If nothing else, they must be addressed first for any long-term promise.

With respect to the critical points (I think David’s focus shifts somewhat to consumers from VC)… the answer to the question of what criteria should matter on whether to invest or not is “it depends”.

When selling a low cost service to the large market it may take some time to get to the ROI. But that should not be discounted. Surely, there are plenty of companies that still regret not getting into the Pay per Click space.

Similarly, granularity is important, but as long as the company needs and is able to function effectively (and efficiently) using multiple SaaS solutions, specific number of them is not very important. Remember that SaaS is a very broadly defined industry. Your electronic banking, online shopping portals, news subscriptions, calendars, many other things as Saas. So you cannot stop at some magic number.

Certainly the will be disappointments in the future and it is important to (try to) maintain a realistic (and even at times pragmatic) outlook on the industry in general.

The question what happens with the data if SaaS vendor flops or has a devastating outage keeps coming up. Here is some feedback on that based on my favorite session from recent SaaSCon conference. For a little under an hour three SaaS PPM clients were grilled by SaaS vendors in the audience on this and similar issues.

Their responses were: store the source code for technology in escrow, back up, and develop scenarios for emergency situations. They admitted that none of them actually has gone through emergency drills. One company also commented that data preservation was not mission critical for their specific setting and it is important distinction to keep in mind.

When working with SaaS, client companies need to develop awareness on how important is the data preservation and/or availability for the specific Web-based service they are using. In some cases periodic lack of availability (and even possible loss of the data in its entirety) will not disrupt operations, and thus may not be worth increased concerns and resulting costs. However, when the data is vital, it is worthwhile to at least minimally go through the steps that these client companies went through. I would argue that when data is critical they should try to go further and run through at least some of possible outage scenarios.

In what appears to be a first editorial of this sort, Barry Rosenberg and Craig Wright discussed how CIOs and CFOs should work jointly to evaluate economic benefits of SaaS vs alternative software services procurement methods on a more comparable ground. The authors looked at specific fixed and variable costs of developing and maintaining the software application in-house, outsourcing or investing into license to SaaS subscription costs.

The article illustrates the challenges of comparing disjointed cost categories. While in-house development is often characterized by capitalized hardware/software/salaries costs, the subscription model generally fits into a different expense capegory (operating expenses). In-house development costs may also be spread over a longer time period i.e. 5-year rent for facilities cost. In contrast, while some SaaS contracts stipulate several year lock-ins, typical contracts are on a month-to-month basis.

Other considerations include:

1. Comparative scalability: typically not an issue of concern with SaaS but possibly a can of worms in case of in-house development in terms of hardware/software expenses, and resources utilized.
2. Sunk costs: even if SaaS costs will be lower overall, it may be difficult to make the right decision if there are already resources invested in the in-house project. Software ages very quickly and continual investment is necessary to keep it in line with the current needs.
3. Opportunity costs: of using competitive apps or engaging the workforce on the more strategic tasks
4. Costs of upgrades and maintenance: again, largely immaterial to SaaS
   data security/ownership risk: while executives may feel that in-house data maintenance is “more secure,” the comfort zone may have a higher price tag attached compared to the SaaS vendor who enjoys economies of scale and is able to spread the costs across the subscriptions.
5. Administrative expenses: vendor/contract management, hr for in-house staff
6. Usage considerations: if the application is part of a company’s “core competencies” in-house development may be more beneficial given greater potential for customization, quicker responsiveness to changes, customization to accommodate specific new initiatives and ability to “branch out” into related functional areas. On the other hand, if the application is not a part of company’s strategic initiatives and is aimed at supporting specific infrastructure i.e. HR, CRM, Sales, SaaS may be a better alternative.
7. What are some of the additional issues to keep in mind when comparing the two approaches?

Just as I was finishing this post, I came across Andrew Conry-Murray's article where specific cost comparison for similar licensed and SaaS products is done. That brings me back to the point I wanted to make - even though it is a bit more complicated, side-by-side comparisons (or the closest thing to them) are needed when evaluating both approaches and their implications.

Hardly a week goes by without a SaaS vendor reporting support for offline services, in line with Phil Wainewright‘s predictions. Industry monitors are distinguishing offline support as one the key components of SaaS delivery model as well.

No, it is not a step backward to the enterprise model, it is a major move forward into a whole new world.

SaaS industry vendors are recognizing the need for offline support for clients with intermittent Internet connectivity (Manhattan Fruitier discussion) or who are on the move. And they are working to ensure that these clients are able to continue to use their services and do not have to turn to the enterprise model. With the offline limitation removed, the choice is becoming clearer.

While it is a given that a vendor is expected to maintain more than a certain degree of service accessibility, it may not make business sense to assume that of clients.

The ability to take a paradigm that may look alien and embrace it for a client’s benefit, shows tremendous adaptability of vendors across the industry. This is a powerful message to the consumers that further pulls the rug away from under the “pure enterprise” solution.

Robert Jaques mentions this when discussing Google new online office product offering:
“…the analyst firm went on to advise firms that Google Apps is not ready as an enterprise-wide SaaS collaboration option for most enterprises”…"This is a version 1.0 product and lacks key features, such as offline availability.”

This is the world we are in today... Moving forward.

Byte and switch had a reasonably revealing poll about on demand in the context of online hosting (despite just 19 responses).

Here is the break down.

No surprise about the first one… The second is biased towards the hosting context (where the poll was published) – it would be good to get a better idea about what the 29% that stand for “Other” really stand for. In the third question the same 29% are generally unclear on the cost-saving benefits of SaaS – this is where more work has to be done by SaaS vendors to educate consumers. Finally, the last one is the most intriguing.

About 18% think that the cost is the barrier – is that in the context of the hosting industry? And it is only marginally consistent with the results of the previous poll. 18% site security issues – this is again surprising given not only the context but also the general premise of on-demand. It would be great to corroborate that with other analyses. Being unable to sell it internally 18% of the time is understandable - I could not sell it to my boss either. Finally SaaS vendor would really love to get inside the last one: Other 47%.

Speaking of insightful polls, take a look at Phil’s. Given some recent press, the collective wisdom seems to be right on target.

I am inspired to create a poll of my own, to get to the bottom of my questions. But better yet, given that the blog is still not mainstream :), I’ll be happy share my survey ideas with anyone who has interest.

Check out Top Ten SaaS Buzzwords from James Maguire

Here are a few more:

SaaS-enabler: a company/technology that can take an enterprise/offline business and replicate the functionality in terms of SaaS services. Essentially convert a non-SaaS application into SaaS offering.

SaaS vs. ASP: ASP (Application Service Provider) is a client-service architecture deployed over HTML. A “pure” ASP does not support a multi-tenant model. Each instance of the application/service may be customized for clients. ASPs may also take a licensed product and host it (as well as operate, maintain, support) for clients.

SaaS vs SOA: SOA (Service-oriented architecture) is a software architecture that supports loosely coupled software services that impart some business functionality. These services can communicate but it is not required. SOA may be interpreted as the underlying platform for SaaS. More on Wikipedia.