SaaS Blogs

Yesterday, Will Price of Hummer Winblad wrote a terrific quantitative analysis comparing the upfront funding needs of SaaS vendors, or application providers, with the funding needs of traditional software firms. In case there was any doubt, his data shows that funding a SaaS endeavor requires substantially more money – on the order of 3.65 times more capital, in fact. His article is titled “The Economics of SaaS: We Need a Platform.”

Mr. Price’s funding breakdown consists of data for publicly traded software companies in both the enterprise client/server space, and those that have reached IPO with primary SaaS offerings. His numbers add substantive clout to the prevailing, though often questioned, thought that starting a SaaS company or moving existing business to the SaaS model costs more than the traditional client/server model. Mr. Price deduces that the way to reduce SaaS development costs is to speed up development time - to get to revenue quicker. But how? Well, it’s no surprise that Mr. Price provides the platform as the answer. Solving the time to market and infrastructure overhead hurdles for SaaS vendors is what us platform developers refer to as ‘The Problem’.

The information below is a qualitative technological mirror to Mr. Price’s article where I hope to identify the sources of increased funding needs and where they lie on the timeline of bringing a SaaS application to market. The fixed costs of delivering SaaS can be amortized as a cost-to-service expense once everything’s up and running and subscribers are paying access fees, but it still takes a huge amount of initial capital to build a SaaS company capable of reaching the point of deployment. The diagram and explanation below are contained simply to the pre-deployment stages of a SaaS company.

So, where exactly do these additional costs lie during the ‘get to scale’ or pre-deployment phases?

In this graph, the red line is SaaS, and the blue line is traditional software development. I’ve broken pre-deployment efforts into five general stages – Bootstrap, Engineering & Development, Functionality Testing, Reliability Testing, and Go To Market Ramp-Up. From a development standpoint, these are the five higher level requirements that the two approaches (client/server and SaaS) have in common; however, I’ve color-coded the stages where the SaaS model introduces added costs (red). After these five stages are complete, a company can start making money on their offering. To be clear, I’m addressing the period of time that spans from zero to public availability of the software. As you can see by the graph itself, the two models vary greatly in their get to market requirements.

Bootstrap – I’ve encapsulated expenses into the Bootstrap phase that are typically required to establish a company and lay the groundwork for software development. This includes incorporation, real estate, initial assets, licensing, developer tools and so on. All companies require these things which, of course, present the sharp initial rise in expenditures.

Engineering & Development – This is nose-to-the-grindstone time. This stage tends to incur a moderate, but consistent, amount of operational costs like salaries, utilities, and so on. Often times specialized training and 3rd party tools come into the mix, but for the most part this stage happens sans any extraordinarily large expenditure. Note that SaaS does require skill sets and knowledge that can are scarce in the industry at this early stage in the game, and some additional costs may be incurred in order to acquire the proper development teams.

Functionality Testing – I’m not going to single out any one technique for testing the functionality of your software; but a safe generalization is that all software companies must do some form of testing. This is early stage functionality testing, nothing SaaS-specific yet.

Viability/Reliability Testing – Here’s where things get interesting. You’ll notice on the diagram above that this is where the expenditure lines start to split. That’s because in this stage, the developer must measure the ability of their solution to not only function, but to execute the precise tenets of SaaS. Of utmost importance here is the answer several differentiating questions: Can it scale? Does the SaaS application buckle under load? How well does it accept new subscribers? How dependent on hardware resources are the scaling algorithms? Does the application function better scaling out, or up? All these questions will eventually lead directly to a discussion about the cost effectiveness of the solution.

To accurately answer these questions requires a real world environment. Traditionally that meant running the application against various hardware specs, testing single-tenant load, running through use cases and so on. SaaS introduces the notion of scaling to support not one, but potentially thousands of tenants. Testing this requires a hosting infrastructure, bringing the cost of testing reliability far higher than traditional testing.

Go To Market Ramp-Up – As expected, expenditures start to shift from development to deployment, and sales and marketing engines are revved in unison. When a traditional software company ramps up operations and flips the switch on their RTM product, the costs incurred tend to lean towards initial production (media) and marketing. SaaS, of course, requires a ramp up of infrastructure, outsourced or in-house, that certainly doesn’t go away once the vendor starts selling the product. The production of delivery mechanisms - CDs, DVDs, downloads – to facilitate selling traditional software is an upfront cost that goes away after a certain number of sales. Maintaining an infrastructure to provide a hosted application is the true test of the application’s scaling capability because cost of service per subscriber must be driven down by efficient scaling in order to keep margins manageable and facilitate revenue growth. This weighting game (pun intended) will go on long after the vendor has deployed the application for public use.

The bottom line is that SaaS forces application developers to become application providers. They become responsible for the bringing the product to the end user further down the delivery chain. The additional costs required for that transition require a larger amount of capital up front.

However, given the right platform, SaaS development doesn’t need to be all that disruptive. The ideal platform will let developers be developers, and will aggregate application provisioning in a way that achieves optimal economies of scale. Remember, this is the worry of the platform, not the vendor. Off loading this burden through technological means translates to lowered fixed cost for the vendor and quicker time to market, allowing them to become established and grow in a fashion that tightens the parallel between SaaS developers and client/server developers.