SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Which Startup Deployment Model? (Avoid Muck and Brass, Look for Gold)

Posted by Bob Warfield on December 7, 2007

You have a brilliant new idea for a software product.  Customers will beat a path to your door if you can get it built.  You’re fleshing out your plan, and it comes time to decide on a deployment model, which will have consequences for your business model as well.  There are four deployment model options to choose from:

  1. Sell software that gets installed on customer hardware
  2. Package your code onto a hardware appliance and sell the box
  3. Package your code onto a virtual appliance and sell the appliance
  4. Sell a hosted solution

Phil Windley is busy asking exactly this question over at Technometria.  I’ve personally worked for or founded a LOT of businesses that sold #1.  More recently, I built and sold #4 at my last employer, Callidus Software.  We’ve also looked at the potential for #2 or #3 at various companies and at various times.  Lastly, I did a fairly elaborate benchmarking study where I went and met with a number of SaaS and enterprise vendors considering SaaS.  My conclusion from all of that is to recommend #4 exclusively.  That’s a very strong position to take, but I wouldn’t even hesitate about it.  Let me go through some of the issues Phil considers as well as some of my own thoughts on why I’m taking such a position. 

We’ll start with some issues that Phil brings up.  He launches his discussion with references to two eloquent articles on this topic.  Jason Fried wrote a great piece about why 37Signals doesn’t sell installable software.  Jason’s article focuses on the following reasons for choosing a hosted model:

  • It would require a larger less agile company to sell installable software due to the need for more technical support, documentation, and a slower development process.  This would also reduce control over the customer experience.
  • Having total control over the development and deployment evironment greatly simplifies the software.
  • Environmental issues at the customer’s site make it much more likely something can go wrong.
  • Upgrades are problematic and you wind up supporting lots of backward compatibility headaches as multiple versions coexist.

The comments on Jason’s article are also quite interesting.  Many seem convinced that hosting is simply a plot to extract continual monthly fees and ultimately make more money from customers.

The second article Phil quotes takes up the opposite argument.  Joel Spolsky responds to Jason’s article directly with some interesting comments:

  • Writing installable software is a gnarly problem, and solving gnarly problems is what you get paid for.  This is why his article is called “Where there’s Muck there’s Brass”.  The Muck is the Gnarliness.  The Brass is the Reward for dealing with it.
  • Joel’s company, FogBugz, offers both hosted and installable, but installable outsells hosted 4:1.  If they eliminate installable, they have to live with 1/5 the revenue and that’s just not tennable.

Joel adds some interesting disclaimers at the end such that he doesn’t claim 37Signals would sell 5x as much by offering an installable version because:

  • 80% of their customers opt for Windows Server, but 80% of support incidents are due to that 20% Unix audience.
  • The installable version has been on the market for 7 years and the hosted version for only 6 months.  If you look simply at new customers, the ratio of installable to hosted goes down to 3:1.

Joel’s comments are on reddit (interesting tactic, actually) and the very first one has the same reaction I did to the article.  Joel didn’t make a compelling case that you leave a lot of revenue on the table by not offering installable versions.  His own disclaimers already start to create doubt around the proposition, but what the first commenter brings up is that if there was only a hosted option, some of the buyers of installable would choose the hosted option.  In fact, Joel’s article is the first one I’ve seen that strongly made the case for a huge revenue downside of not offering installable software, particularly for a startup.

Consider the effects self-selection and expectation.  FogBugz has been on the market for 7 years.  By this time, how much of their selling is based on referrals?  Quite a lot I would expect, and those referrals are based on the vast majority of folks having experience with the installable version.  A new startup has no built-in expectation from customers.  It’s putting the word out for the first time about what it does.  The SaaS startups I talk to share a common theme when it comes to competing with companies that offer multiple models: simpler is better.  Simpler is easier.  Focus is good for a startup.  Not offering too many choices is good.  Save the choices for later, after you have successfully tapped into a real market with your initial offering and gotten it tuned up for a good product/market fit. 

What these pure SaaS plays tell me is that it’s just easier for them to sell than it is for the hybrid counterparts.  I’ve presented real data on real companies that makes this obvious.  Part of it has to do with the fact that many of the benefits of SaaS force you to speak to the disadvantages of installable software.  The hybrid vendor can’t do that.  They’re selling with one arm tied behind their back.  My interview with Concur’s CEO Steve Singh brings this out in an interesting way.  Concur is probably the largest company ever to make a transition from installable to SaaS.  During the transition they offered customers the choice.  Given that SaaS delivers accounting numbers that are short term less impressive than perpetual license sales (because you receive the revenue monthly over a longer time and not all at once), he originally incented his sales people to favor selling installable to cushion against any sudden impact on his numbers.  So long as he gave extra incentives to his salespeople to push the installable version, the breakdown was 50/50 in terms of what customers were choosing.  As soon as the sales compensation was neutral, customer’s started choosing to go 99% on-demand/hosted.  That’s a big difference!

As I’ve watched and talked to various software companies exploring SaaS, the story repeats over and over again.  It’s much easier to sell the SaaS proposition.  It’s much easier for customers to get started with it.  They have a better experience.  There is little needed for protracted evaluations.  Buy it, use it, and if it doesn’t work out in a month or two just cancel it.

Because of all this input I’ve gotten, I look at SaaS as having two huge advantages.  One is the ability to provide a superior customer experience and the other is the ability to sell much more easily on the basis of that.  The fact is that it isn’t easier to develop SaaS, but the problems you solve add more value and your company stays more focused on innovation and less focused on plodding through the mud.  This is an area where I differ with Joel Spolsky.  Writing installable software is not solving a gnarly valuable problem in the sense he intends.  It is dealing with a tedious and expensive problem.  Are you putting your best rocket scientists to work supporting new platforms and writing installers?  Or are those the first things you want to outsource and offshore?  Customers clearly do not pay more for those who have solved it.  They may even pay less over time for installable software.  Joel himself admits that a reason people want it is perceived lower price.  So why dive into cleaning up muck for brass?  Brass is not nearly as valuable as gold.  Muck and brass are common.  They are not differentiated ways to make a difference.  Look for mechanisms that are differentiated.  What can you do for your customers by hosting that is nearly impossible to do with an installable version?  That’s the really interesting question.

Aren’t there any cases where SaaS doesn’t make sense?

We can hash through the whole security and privacy thing, but it’s been done to death and frankly, it’s just not a real issue for most kinds of software.  Companies are nearly through that learning curve.  Companies large and small are entrusting their sales information, arguably the absolute crown jewels they own, to SaaS systems.  ADP has done this for years with salary information that results in cash outflows.  Read the interviews I’ve done on this blog with various SaaS CEO’s.  I ask them all about this and they’re all very clear that there has been a change.  Consider also that all the SaaS markets are still young, vibrant, and growing.  You don’t have to get 100% of the addressable market day 1.  There is time for the late adopters to come around to an understanding on this.

I’ve commented before on appliances too.  I personally see them more as transitional marketing gimmick than anything.  They’re neither fish nor fowl, and they are not silver bullets.  You can’t really get to the SaaS sales proposition I know with an appliance.  Nevertheless, they’re better than a pure installable solution if you’re determined to put something on-premises.

Beyond that, I think it really depends on the software.  Software that has to be on the desktop or inside the firewall for some reason is an example.  I just wonder how much longer software has to be on the desktop as I work with technologies like Adobe Flex, and I also wonder whether this is a time to create a startup around such software.  The world is in transition.

Go for the SaaS model and don’t look back.

6 Responses to “Which Startup Deployment Model? (Avoid Muck and Brass, Look for Gold)”

  1. marckickind said

    “Aren’t there any cases where SaaS doesn’t make sense?”

    There’s certainly one…

    “We can hash through the whole security and privacy thing, but it’s been done to death and frankly, it’s just not a real issue for most kinds of software.”

    That’s because you’re not considering classified military environments. While classified systems and environments are a drop in the bucket next to commercial IT, there are hundreds of millions–if not billions–of dollars going into these kinds of environments every year.

    It’s still a good market, and problematic for the Defense Department who can’t deploy latest and greatest SaaS solutions in such situations.

  2. smoothspan said

    Marc, welcome!

    Good example. For those working in that area, it’s going to be an issue. OTOH, there are companies today making a business out of sharing CAD/CAM and other information for highly classified projects like new jet fighters in the cloud. That data has to be shared so vendors can collaborate. Perhaps even in that sort of marketplace there are exceptions if the advantages outweigh the risks.

    I also know people who’ve worked for the spook world that had to report to their computer jobs inside a vault that was Faraday shielded against RFI. They could bring no removeable media (USB keys, floppies, or whatever) anywhere near the machines, and the machines could not be turned on unless the vault door was closed. I don’t think those guys are going SaaS any time soon!

    None of this applies to most corporations where the security risks from such things as outside contractors are every bit as great as entrusting their data to a SaaS vendor.



  3. marckickind said

    “I also know people who’ve worked for the spook world that had to report to their computer jobs inside a vault that was Faraday shielded against RFI.”

    This is a lot more common than you perhaps realize (though perhaps not the Faraday shielding). I’ve spent most of my 20+ year career working on one classified system or another, and there was nothing atypical about my or my coworkers experiences in the defense contracting world.

    And while there may be some portions of systems that may be accessible to the unclassified world, nothing that has a DOD or other agency classification will ever be (legally) accessible outside a classified environment.

  4. jwhitling said

    World in transistion, indeed. You want to see the desktop world go net centric? You want to kill 80% of desktops .. Let’s see a REAL robust spreadsheet app .. not a simple java grid but something to rival/exceed the desktop master .. Excel. When this is created (not easy) I can see the desktops going net centric is seconds. Have it work in WAMP/LAMP instead of platform specific languages. I’m sure you can imagine the desktops falling by the wayside for casual users and specialty apps as well. It will become an important part of every SaaS environment.

  5. friarminor said

    Speaking of spreadsheets, how about EditGrid? Anybody ever tried it?

  6. jwhitling said

    I had not heard of EditGrid before your posting, but now, a day later I’ve played with it and bumped into some of it’s limitations, so I’ll have to say for uncomplicated spreadsheet work it’s pretty impressive. Much better than any other net centric spreadsheet app I’ve played with.

    When you get into more advanced spreadsheet processes and large file sizes it’s quite limited. Maybe it would run better in a localized dedicated server environment. But it seems to be headed in the right direction. Check it out in a few updates.

    It claims to be able to use PHP forms and has a simple PHP autoform tool, etc and so I’m investigating using EditGrid behind the scenes as a tool for extensive calculations which could be displayed quickly in web pages and forms.

    Thanks for throwing it out there ..

Leave a Reply

%d bloggers like this: