Thursday, August 28, 2008

10 Benefits of Building Software as a Service (SaaS)

SaasDefinition: "Software as a service [...] is a model of software deployment where an application is hosted as a service provided to customers across the Internet." (Wikipedia)

Software as a Service (SaaS) can be a very attractive model for software vendors. Here, I share my experiences of transforming the desktop application FeedJournal to use the SaaS model.

FeedJournal was born into this world as a .NET desktop application; a fruit of Microsoft's Made In Express Contest that ran in 2006. After the contest (First Prize, thank you Microsoft!), I took some time off to learn ASP.NET and port the application to the web. The port itself wasn't too cumbersome; most of my time was spent learning the development platform and web development patterns. Today, FeedJournal Publisher employs the SaaS model throughout, and users can run it from their web browser, or by using a REST API. Below, I count 10 obvious benefits that came from this transition:

1. Fear the Hacker

"FeedJournal will not be reverse-engineered!"

My initial reason for turning to the web was purely technical. FeedJournal was (and still is) unique in the way it automatically orgainizes articles in a slick newspaper format. I was worried that someone would reverse-engineer, copy and rebrand my invention as a competing product. It is particularly easy to reverse-engineer .NET and Java applications, because they are distributed as intermediate byte-code and not as machine code. By providing a free demo download of FeedJournal, the stage was set for any evil hacker to play copycat.

By instead deploying the application to a web server, the binaries are never exposed to the end-user. This is a huge benefit for anyone who does not trust the power of utilities to obfuscate byte-code. Now, my build process is also simpler because I do need to run the application through an obfuscator on each build.     

2. Fear the Cracker

"FeedJournal's registration system cannot be cracked!"

Many people will never pay for software. And not because they opt to use free software, but rather because it is relatively simple to get hold of pirated copies. Sadly, it is often more simple to use pirated software than to hop through the loops of registering a product legally. 

Some people argue that pirated software is beneficial for the industry. They claim that pirated software gets exposure that will generate more sales. Be that as it may, I take my chances by eliminating the risk of anyone cracking my piece of software by using the SaaS approach. No cracks or keygens will work to gain illegal access to FeedJournal. And even if it such a crack would be possible, I can easily patch the security hole for all users at the same time. No old crackable versions would be available anywhere.

3. Finance

"The monthly sales are stable!"

Having users subscribe to use a product is very attractive from a financial point of view. The earnings become less erratic and it is also more attractive to users who only need to use the service for a shorter amount of time.

Charging subscription fees for locally installed software is not practical. Many software vendors instead charge a running support fee, which seems to be working quite well for larger companies. On the other hand, support still costs money for the organization and it doesn't fit in with the attractive software utopia where you build a product once and sell it forever.

But, by having the software hosted on your server, it suddenly becomes acceptable to charge a subscription fee for access. This is perhaps the most attractive aspect of SaaS from a business perspective!    

4. Usage Statistics

"I know how many users generate a newspaper each day, and which functions people use!"

For a desktop application, you know how many users have downloaded and registered your product. But it is more difficult to know how many people have installed it and actively use it. Ping-back solutions, where the application secretly sends a message to the author's web site, is frowned upon and can be disabled by users with a firewall.

For a hosted application you will get a huge amount of statistics at no cost at all. It doesn't matter if you host it on your own server farm/basement or use a hosting provider - you are guaranteed to have more data than you could shake a stick at. This data can of course be used to improve your marketing focus (where are my users from and from which sites did they arrive?) and product development (which features are most popular?).

5. Catching Bugs

"If something bad happens in the software, I'll be the first to know!"

Software is difficult to write. Sometimes things go wrong and the application throws an exception. If the user sees an exception, he will obviously think less of the software and perhaps stop to use it. When desktop applications crashes, the author will find out about it only if the user takes the trouble of submitting a bug report. Even if the user submits a report, it is likely to miss the detailed information the developers require to pinpoint and squash the bug.

A hosted application can easily catch and log all exceptions directly to the server. Additionally, you could send exceptions to an e-mail or instant messaging address to be notified right away. This ensures that you have a complete image of all problems in your software, and it will be easier to assess which bugs affect users the most.

6. Deployment

"Prospects can start to use the software within 20 seconds of landing on feedjournal.com!"

The barrier to entry for a web application is of course much smaller than that of an equivalent desktop application. No download and installation of the product are required. Simply register a new user account and you are set. Also, dependencies can cause problems in desktop applications, where different applications require different versions of the same DLL or framework. All of those headaches are gone in the SaaS world. Additionally, it is much easier to manage and deploy resources (fonts, images, etc.), because they only need to be installed on the web server.

And, as a big bonus, you don't need to worry about users running ancient versions of your product - the product is only installed on the server and the vendor updates it whenever he wants!

7. End-User Configurations

"Linux or Mac? No .NET/Java framework installed? I don't care!"

FeedJournal can be used by anyone with a modern browser and PDF reader. In short, basic software that is available on all desktops configurations.

FeedJournal was initially available as a Windows .NET application. It wasn't long until requests started to pour in for supporting Mac OSX, Linux and older Windows versions. It is difficult enough to develop software for one platform, who needs the headache of supporting a multi-platform product?

A web application still needs to pay attention to different web browsers on various operating systems, but these problems are tiny in comparison - especially when using cross-browser libraries such as JQuery or Yahoo UI.

8. License Registration

"The serial number will never again be caught by the spam filter!"

FeedJournal Publisher users don't have to worry about registration, because registration is automatic on payment approval.

Anyone who had to deal with the business end of product registration knows that as soon as registration keys need to be handled, the headaches grow. Users mistype the serial, they copy and paste the wrong section, or generally need someone to hold their hand while registering the software. Using SaaS, you eliminate the step where the user registers. Simply provide a PayPal link and set up some simple automatic or semi-automatic flow where the user's subscription expiry date changes accordingly.

9. The Multi-Computer User

"Users can generate their newspaper from any Internet café!"

It is more and more common that people use multiple computers during the day or week. Perhaps they have one or multiple computers at home and another at work. These users do not want to buy one end-user license for each computer, but they would still want to access the software from multiple workstations. Again, SaaS solves this problem that would require some hard thinking from the developer of the desktop application. 

10. Always Connected

"The end of 'Cannot connect to the Internet' problems!"

There is no longer any need to handle issues with end-users behind proxies or firewalls. As soon as they can access the web, they can use your web application. You know that your application will always be able to access online content.


In summary, the Software as a Service architecture and business models can be very attractive choices for people trying to make a living from building, maintaining and selling software. Saas is not a model that fits all applications, but you should keep it in mind for your next software product!

Sunday, August 10, 2008

Back from My Vacation

It's been quiet around here lately. The reason is that I've been on a 3-week long vacation in Sweden, visiting family and friends. I am back home now, and eager to get started working on FeedJournal again.

I'm grateful for all votes, comments and suggestion that have been streaming in to the UserVoice page I set up before my vacation. A lot of people want to get their new issues automatically by e-mail. I'm sitting on the fence on that one, because it will put a lot more strain on the web server and I will risk winding up with a lot of wasted bandwith if people sign up with temporary e-mail addresses and then just forget about the service (which I do myself, all the time). The current architecture for FeedJournal Reader also make good use of the client browser for fetching feeds; logic that would need to be moved to the server. On the other hand, FeedJournal Publisher already implements all the feed handling server-side so it's not that I would need to reinvent the wheel here. I see the benefit of e-mailed issues for Kindle users especially, but I need to spend some more time thinking through the solution.

This week I plan to improve the handling of unavailable feeds in FeedJournal Publisher. Today, as soon as a request to a feed URL is not responding, I simply abort the generation because I considered an incomplete issue to be undesirable. However, this approach has disturbed some of the gold members, and I am now going to keep generating the issue while reporting unavailable feeds in the return message.