SaaS 101: The Drawbacks


A while back I wrote an article called “SaaS 101: The Benefits” in which I discussed some of the benefits of the SaaS model for end users and software vendors alike. Of course, where there’s a yin there’s a yang, and so this article (a long time coming, we know) will explore the other side of the coin.

For the Customer & End User:

  • No direct control of the data - One of the biggest hurdles to get over is the control of the data. Specifically, what happens when things go wrong? I’m sure every company trying to sell you a product will tell you that things can’t go wrong and that they will be there to support you for years to come. It is important that you ask the difficult questions: How safe is my data? Will I be able to download it? Will it be disposed of properly and safely? Can it be sold? Can anyone else host the application and my data? Will the application source be opened so that hosting can happen in house or by another provider? Stories of companies going belly up are not uncommon, and not only for SaaS companies but for traditional software companies as well. The only difference is that when a traditional software company goes under, the most you might lose is the years of support you were expecting from the vendor. When your SaaS provider goes under, deeper implications surrounding your vital business data have to be considered. 
  • Internet connection required - I don’t know of many businesses that run without an internet connection these days. Nonetheless, it could affect your operations if you need to access an application and the internet connection is down.  A good set of companies are trying to solve this problem by allowing their applications to continue to work in a disconnected fashion for a period of time but at some point you will need to sync back up to the server. If this is a big concern for you make sure that your provider can address this need.
  • Dependence on an outsider to run your business - In a big way, you are trusting an outsider to help you run your business, and if they are not keeping their end of the bargain it can really affect you. To keep it in perspective, these people are out there to stay in business and they do this for a living so arguably 95 out of 100 times they can do it a lot better than you could in house. This does not mean that you shouldn’t be aware of the implications so make sure you ask the tough questions.
  • Security awareness - Another big hurdle is security. This concern is the umbrella that is home to the concerns above, as the common thread among them all is that they make you consider how “secure” you feel with SaaS. You are trusting your really valuable data to someone else. This can be a painful reality to accept but most security breaches occur because of disgruntled internal employees that end up selling or releasing the data when they are fired or when they quit, having your data managed and stored by an expert of the application is not a bad idea as long as they take it as seriously as you would. Again, it is in their best interest to do so but make sure you trust your provider the same way or more than you would trust your internal IT department and again, don’t forget to ask the tough questions!

For the Provider:

  • Focus on customer satisfaction - This is one of those bad things that it’s good to have and makes great companies but we have to mention it anyways. SaaS providers need to focus on customer satisfaction month in and month out or they will lose their customers. They need to earn their customer’s business every month or they can simply leave. Contrary to on-premise deployments which are very costly and time consuming, if your customer is unhappy with the service he can up and leave at any time with very minimal cost. Some might argue that you can negotiate longer term contracts, make it hard to take their data and all other kind of shenanigans but if you ask me, it is bad practice and if you are not the best, then you better have one damn good reason why they should stick with you other than a binding contract.
  • Harder development process - There are many different approaches to writing SaaS applications and they are outside the scope of this article but the bottom line is that there is a whole new set of things that you need to worry about when writing a SaaS application that you otherwise wouldn’t need if it were a traditional on-premise deployment. Things like tenant isolation, provisioning and scalability to mention a few could be a hard thing to tackle where you wouldn’t even have to think about if you were writing an on-premise application. Nowadays there are several companies working on “SaaS Platforms” including mine that make this a lot easier but none the less it’s something that you didn’t have to deal with before. For a great article on how to transition your company into SaaS read Sinclair’s article where he outlines a couple different strategies. Another thing that makes the development process harder is finding the right talent as the skill sets required are more advanced than for its on-premise counterpart but hey, who doesn’t enjoy a good challenge!?
  • Compensation issues - One of the early problems for SaaS providers is how to maintain operations when there is only very little money coming in. Unlike traditional on-premise deployments where one deal could bring you $60,000 upfront and carry you for a couple of months while you close more deals, SaaS deals are MUCH smaller so initially it will be a lot harder to maintain operations unless you are properly funded so you can survive until enough money is coming in . Additionally the question of how you compensate your sales team can be a tough one to answer and can vary greatly depending on your offering. It might require you to offer higher base salaries and get creative with your commissions but without a doubt it can be one of the tougher operational questions you will encounter.  As an example let’s look at this scenario: Provider A sales an on-premise application for $2,500 a license. On a decent 20 seat deal they would bring $50,000 ($2,500 x 20) plus an additional $10,000 for support (usually 20%). Out of the $60,000 they would normally give anywhere between 1% to 4% commission to the sales rep leaving the company roughly $58,500 to run operations. In a comparable scenario where Provider B sales the same type of application as Provider A but as a SaaS application it will probably cost around $75 per seat so on the same 20 seat deal they would bring $1,500 a month taking over 3 years to reach the same $60,000 that the on-premise company received. You will need to come up with a good strategy on how to compensate your sales guys but at the same time have enough money to run the company.
  • Success can be a problem - You’ve heard many times that being too successful is a great problem to have but in the case of SaaS it can literally bring you to your knees if you are not prepared. This goes back to my second point of SaaS being harder to develop. Things can grow out of control if the application is not architected properly and addresses scalability issues and your service can become unusable over time if it does not scale properly with the addition of new tenants. Make sure you don’t leave the hard decisions for later because you will run into a wall down the road.

After reading this article some of you are probably thinking “Damn, Why would anyone even think of getting into SaaS?!” But for the ones that are still not convinced check the benefits before making any decision. As with anything else you should always make a decision after you have considered all things good and bad.

What do you think? Does it make sense to jump into SaaS from end user and provider perspectives? Do the benefits outweigh the drawbacks? Or is it the other way around?

Who will be the winner?

View Results

Loading ... Loading …

We’d love to hear your opinions, so leave your comments!

 

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
The Not So Obvious Advantages of a SaaS Platform
Introducing Our New Co-Author: Abe Sultan



Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Hi Abe,

this insn’t a mutuall exclusive scenario… i think in some markets and some segments SaaS will win out, but never at 100% penetration

Paul,

You are absolutely right. It shouldn’t be a clear cut decision for one model or the other, there is definitely room for both models to co-exists and ideally it would be a close synergy where both offer their unique benefits depending on the application or service being rendered.

Thanks for keeping us in sync! See updated poll.

I would agree with both of you that there’s room for both SaaS and On-Premise applications. What I find interesting is considering which option would play in which scenario.

I think that SaaS has a great future serving SMBs and providing support functionality for enterprise-level customers. In the first case, the economies of scale for the SaaS providers, as well as their expertise makes it somewhat of a no-brainer for the small companies. In the second case, using SaaS options like SalesForce.com or any of the various online office tools could be an easy way to reduce costs at a relatively small risk to the enterprise.

On the other hand, I think that enterprise customers will be very wary in trusting SaaS providers for anything they deem critical to their core business - largely for the reasons Abe lays out above. I think it will be quite hard to convince these companies - many of whom are quite risk-averse - to pass off a piece of their key IT processing to a somewhat unproven model. In fact, I wouldn’t be surprised to see these customers being more willing to pass off all their operations (outsource their IT) than to utilize SaaS providers to provide the same service - just because they are more familiar with the concept. Perhaps after SaaS matures more in practice, enterprises will be more willing to consider their use in core functionality, but I think that will be a ways off.

Dan,

You make a good point. The key for SaaS to continue succeeding at a mass level will be to increase trust and to prove that the model works.

This is very similar to the resistance banks encountered in the earlier days. For the longest time people believed their money was safer under their mattress than in the bank; even today there are people that believe this and that probably will never change; clearly this is not the case. It will take some time and some success stories to prove that SaaS is the right way even for the big enterprises but we are well into the process.

Everyday there are more and more companies porting their applications to SaaS and you will be hard pressed to find any size enterprise small, medium or large that is not considering SaaS applications in one way or another.

Obviously time will tell if SaaS has any future in our industry and if it truly is the next BIG THING but if you ask me, the future is imminent.

Cheers!

First of all I am glad to find this blog and a couple of others to talk about SaaS. By trade I am a SAP Portal Architect and I have spend last nine years designing and implementing large scale portals.

In the last couple of years we were developing a portal infrastructure embedded with content management and CRM systems. In our company,Beyond Portals, we have called these modules Collaborative Content Management System (CCMS) and Customer Information Management System (CIMS).

In 2007 we have built our first SaaS application , namely Web2Expense. Web2Expense was built on a multitenant portal architecture where CCMS and CIMS provided core content and user management services. The biggest challenge that we faced was the assumption of using the standard web browser as our client without any additional technologies such as Java Applets or ActiveX controls.

One can argue how we can claim Web2Expense to be an SaaS application. We actually thought a lot about this question as well. Here is my short answer, check your application against industry classifications. In our case, we have looked at IDC’s and Microsoft’s definitions of what a SaaS application provider should be and we had qualified in each one of their categories.

Finally, please feel free to use Web2Expense Travel Expense Management system it is free for individual use. We welcome any comments you may have regarding SaaS development in general and Web2Expense in particular. Also if you have questions send me an email…

PS. I voted there is room for both but my heart is in the pure SaaS domain…

Semih,

We are glad that you like our blog and we hope that you find it useful. There are many forms of SaaS; some more efficient than others and some more appropriate than others depending on the application.

In this blog we try to give you the necessary tools to help you make an educated decision on what type of implementation to use. At the end of the day, Single Instance – Multi Tenant is an advantage for the provider not for the customer and depending on your needs and your market, it might be something that you don’t need to worry about. However if you are looking for efficiency and scalability you will want to implement some level of Single Instance – Multi Tenancy.

Please read the following article by Gianpaolo and Fred where they discuss different architecture alternatives for SaaS and last you can always look at SaaS Platforms to help you develop your applications.

Cheers!

Abe,

Thanks for pointing that article and excellent remarks… Very good information indeed. I guess I have to mention that when we were designing the multitenant portal instance cost was one of our major constraints where scalability and maintainability were the others. The difficulty is to design something that everybody can afford. Additionally, millions of users should be able to use the same instance and you maintain the whole architecture with a handful of people.

On the benefit side, I think the biggest benefit we can provide to the consumer is to provide an enterprise class software even a two person company can afford let alone SMBs…

To be honest with you for small SaaS ISVs the biggest challenge is the trust issue. How do you convince the companies to trust you with their data? Do you have any insights you can share?

Best Regards,
Semih

Semih,

The trust issue is not just hard for the small ISVs, it certainly is harden than for the larger ISVs but it is still hard for all SaaS ISVs to convince customers that their data will be safe. To be honest, there isn’t much you can do except for to use every success story as a building block to foster trust. This is something that only time will ease as more and more companies get comfortable with SaaS.

In the meantime you could try to ease some of the concerns by getting your applications certified by 3rd party vendors. You could also encrypt the persisted data but this could have a severe impact on performance and it is probably unnecessary unless your market requires it.

One of the best things you can do is to treat the data as if it were yours and keep security as one of your top priorities implementing checks at every point of the application.

Keep an eye for a future article where we’ll address ways to minimize trust concerns for SaaS ISVs.

Regards,
Abe

Good start but I think you’re missing some bits from both consuming and providing S+S. Here are a couple of blogs which I wrote covering some of the basics:

http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-consuming-saas-services.aspx

http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-providing-saas-services.aspx

Hi Abe,
I believe the issue of being able to run your SaaS application offline (and synchronize data) is greater than just internet connectivity in the office. When I moved from On-Premise to SaaS I thought the offline days were behind me, but if your app targets sales reps and managers (eg CRM) as primary users who are out on the road a lot, then a occasionally connected scenario is very common. Many of our customers insist on this functionality and prospects still do.

Just a thought…

Troy,

You are absolutely right. CRM is a definite candidate for supporting offline functionality, and like this, many others. We are still not in the days where internet connectivity is available everywhere anytime so for the time being some SaaS providers should consider offering a hybrid solution that allows you to use the application in a disconnected fashion.

This goes back to understanding your target market and choosing the right implementation for your needs.

[…] SaaS Blogs - » SaaS 101: The Drawbacks (tags: saas business) […]

What you think in the SCM area? Will SaaS grow and survive there?

Hi Tiago,

I think that SaaS will do exceptionally well in the Supply Chain Management vertical. Even today ERP/PLM/SCM applications represent the second largest segment of SaaS applications behind CRM.

There are many issues that plague SCM that SaaS is built to support out of the gate but like any other obstacle, one of the biggest things that will have to be solved before it succeeds to its fullest potential is a seamless integration with all the additional on-premise hardware devices that are part of the supply chain.

I think that SCM is one segment to keep a very close tap on and I’m very sure we will see a couple more poster child success SaaS stories coming out of this segment.

Cheers,
Abe

Do you have any post about the integration of SaaS with the SCM?

Sorry the bad english.

Thank you very much.

Hi Tiago,

Unfortunately we don’t have any posts that deal with SaaS and Supply Chain Management (SCM) integration but I’ll make sure that we write one in the very near future.

Keep an eye for it,

Regards,
Abe

I think SaaS should work off-line but we have to be honest here, I live in Portugal and it’s not that advanced in terms of broadband and internet penetration as the USA, but nowadays you can have a 3G connection in many places, and in a very recent future it will be almost a 100% coverage area.

That will benifit SaaS for sure!

Abe,

Are there any significant differences in accounting treatment of SaaS expenses? A large software purchase is a capital expense. Even 3-year lease financing to get monthly payments is typically considered a capital lease. How is SaaS treated in a company that signs a 2 or 3 year SaaS agreement? Is this capitalized, or are the monthly costs treated as simple period operating expenses?

Hi Tom,

That’s a great question, I’m going to let Sinclair give you an answer as he is way better qualified than me to address it!

Cheers,
Abe

Hi Tom,

Thanks for the comment! Sorry, but I’ll steal Abe’s thunder on this one since I bumped into your comment first;-)

Accounting treatment is different. On-premises software is a capitalized purchase, allowing a company to depreciate it as a capital expense. Technically speaking, this reduces the perceived (important distinction from actual here) cost advantage of SaaS after the first year or two because SaaS licenses are recorded as standard period op-ex and can’t leverage depreciation mechanics like capitalized software purchases do.

Now let’s get down into the weeds and see why this isn’t really the best way to discuss ownership costs. First, large on-premises software purchases, despite giving a depreciation advantage, affect the books negatively in other regards. If a customer buys a large on-premises deployment, it usually requires a large cash outlay, which isn’t so hot for the company’s cash position, or to take on a capital lease, negatively impacting the company’s debt position. Neither is particularly appealing, and from a sound fiscal perspective, might pose a larger negative impact on the books than not being able to depreciate SaaS licenses.

Second, large on-premises deployments are far more costly than “sticker price” They usually require server hardware, staff to manage it, risk-costs associated with the prospect of downtime (on-premises offerings experience way more down time than SaaS offerings). All of this adds up to balloon the real cost of the offering. Generally, these “supporting expenses” can’t be capitalized and fall in the same boat as SaaS licenses. This dilutes or even entirely negates and perceived positive impact of the depreciation of the on-premises software purchase.