Flowgram Follows Coghead into Enterprise Software SaaS History

Dennis Byron

Is it the economy? Is it just bad timing, irrespective of the economy? Was the functional idea flawed? Is the "give away the razor" idea flawed? All these questions come to mind as I read on June 12 that Flowgram (about which I posted last fall) has announced that it has

" decided to terminate the Flowgram service as of the end of the month (June 30th, 2009). The service received excellent reviews and had an enthusiastic core user base. However, we were not able to demonstrate (especially in these economic times) that Flowgrams would ever be prevalent enough for us to adequately monetize the business, either though ads or subscriptions.

The demise of Flowgram, created by Abhay Parekh (who had a good track record of founding and building IT companies), follows the much publicized collapse of Coghead in February 2009. Coghead's intellectual property and some assets were purchased by SAP.


There are three generic lessons to be drawn by IT management and staff in these software-as-a-service company corporate failures. You have to vigilantly monitor all three if you depend on such on-demand/cloud-based/SaaS services (pick your buzzword), even from such well-funded firms as Google with its gmail and other aspects of Google apps. They are:

  • The viability of various non-traditional software funding ideas such as "try it you'll like it" and ad-supported software
  • The extent to which the SaaS offering is supporting mission critical functionality, and
  • The status of your "data" if the SaaS service ends, if you depended on the cloud for storage of the data maintained by the service.


On the first issue, you get what you pay for, as they say. But as I wrote last December in The ERP/SaaS Conflict Is a Myth:

"SaaS-delivered ERP has been popular in health-care delivery, community banking, professional services, construction and other services industries since - since back when we called it timesharing.

Most is subscription-based, but some such as construction-oriented software is sponsor-supported, and there is no reason these models will not continue to work as well as they have for decades.


The second factor is to determine how critical the SaaS-based functionality is to your enterprise. Videos and PowerPoint-like presentations like Flowgram enabled are probably never going to be that critical. As I wrote on December 8, 2008, there are in fact many functions that are better served by IT-enabled business services -- and I suspect, but not based on any market research, that videos are one of them. If you were depending on a service such as Coghead's as an application development platform, even for situational applications, the criticality level goes up a notch. Now you run the risk of having to redo months of development work depending on how the SaaS-based platform service worked. At the highest threat level, when it comes to your core applications, there's nothing to say that such applications cannot go SaaS. But I don't think that approach will be accepted until the Facebook generation takes over IT.


As for the third issue, protecting your investment in IT done over the ether is the most important thing to watch. There are not only the almost weekly reports of Gmail outages, but there is the issue of losing the information the SaaS service "stores" for you. It's that information that is key, not the enterprise software that processes and manipulates it. When it comes to your core applications, there's nothing to say that such applications cannot go SaaS. But just as with on-premise core applications, you want to have backups on your backups. To the extent you are doing app development or something less core in the cloud, you want to have the same kind of versioning control and check-in/check-out back up as with on-premise development. Even for mundane things such as Powerpoint presentations, make sure you keep the information in standard file formats so that you can get at them in the future with another application if need be. That's true even if you use an IT-enabled business service to develop the information.


This is all common sense, of course. But it takes an unfortunate business failure every so often to remind us. Flowgram is working hard to encourage all its users to get their presentations off its servers so that the users do not lose their information.

Add Comment      Leave a comment on this blog post
Jun 13, 2009 9:55 AM richard rabins richard rabins  says:

I agree with key point you make below:

"protecting your investment in IT done over the ether is the most important thing to watch"

There however a distinction between solutions like Coghead and Quickbase where your development is done in the cloud and there is only 1 cloud for your application. In this case it IS risky because all your IP (your application) and your data is subject to that Cloud staying in business or staying in business and offering service at an economic price that makes sense.

On the other hand if you build a web app locally and then have the option to deploy it to any ISP or any Cloud - then you have the benefit of cloud computing without the risk!

(Full disclosure - the reason I am passionate about this is that we will soon release Alpha Five v10 that lets you build codeless AJAX apps on your machine and deploy the apps on the web at any ISP or on Amazon AWS. We thought long and hard about the app itself being built in the cloud and hosted in the cloud and concluded that this was not the way to go because we did want our customers to be "locked in."

richard rabins




Jun 16, 2009 5:01 AM Dan Gutierrez Dan Gutierrez  says:

By Dan D. Gutierrez

CEO of HostedDatabase.com

The demise of Coghead hits to the heart of my industry, SaaS. What happened is the typical scenario, the revenue projection models used to driven the firm were overly optimistic against the burn-rate. It is very easy to delude yourself into thinking your sales will grow at the projected rate, when in fact gearing up a new product is harder than anyone will admit.

My firm pioneered the Database-in-the-Cloud industry back in 1999 with the launch of our first product. The VCs at the time wanted to see stellar growth that Coghead probably yielded to. We're glad we resisted that kiss of death.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.