How to Build a Custom ASP

In 1999, there was a huge surge in interest in ASP’s for enterprise software. By 2001, pundits declared the model a failure. One analysis was that ASP’s wouldn’t be able to effectively service enterprise customers, because the systems needed to be customized and integrated, and doing so would …

In 1999, there was a huge surge in interest in ASP’s for enterprise software. By 2001, pundits declared the model a failure. One analysis was that ASP’s wouldn’t be able to effectively service enterprise customers, because the systems needed to be customized and integrated, and doing so would destroy the favorable economics of the ASP. It’s now obvious that the ASP model wasn’t a failure. It just didn’t quite keep up with the extreme growth forecasts. Our ASP packaging at PowerSteering continued to be the leading version of the product, and companies like Salesforce.com delivered ever-better and more configurable products. ASP sales volume, market share, and sophistication continue to grow every year.

So what about customization and integration? Is that a shortcoming of the ASP model? Is there a way to combine the favorable features of an ASP - instant startup, always on, invisible upgrades – with the customization and integration that more sophisticated customers want?

A coincidence of timing last week highlighted the questions for me. I had lunch with David Skok of Matrix Ventures on Wednesday. Matrix claims to be the most successful venture firm ever when measured by consistency of returns and ratios of winners to losers. They make a rigorous analysis of business opportunities, in the selective style of an east-coast VC firm. Skok himself is a successful software company founder and CEO with more than one IPO under his belt. So, when Skok criticizes an approach, he probably has a very good point.

In this case, he took issue with my opinions on customizations. I was claiming that the facts on the ground for enterprise software customers are that they are supporting custom configurations. Instead of avoiding the issue, vendors should take the lead in delivering code, processes, and infrastructure to support these customizations and the related upgrade cycles. Skok argued that:

1) Vendors should be “market driven, not customer driven”. They should stick with a 12 month development roadmap and not get thrown off course by inevitable customer requests.

2) Customers don’t want customizations to the core product. They want a clearly defined and separated area of customization and configuration that goes against a defined API supported by the vendor. They know this will increase quality and reduce their integration and upgrade expenses.

3) It’s just too hard to support customizations and upgrades, so vendors are smart to avoid it.

In leaving, Skok said “I’m really interested in the ASP model.”

That’s where the coincidence of timing comes in. On Thursday, I went to New York to start an advisory engagement with a company called Foothhold Technologies. They make software – delivered as application service – which is essentially a Web-based ERP system for agencies that serve the homeless.

I was amazed when I learned two facts. First, that they have more than 50 ASP customers, and that a majority of them have some level of customization. Second, that they try to address every customer bug report and UI request in one day. They do a production release every day.

This company somehow swims against all of Skok’s objections.
1) They are totally customer driven. Virtually everything in the product was added incrementally in response to some customer request or planned customization.
2) Customers ask for changes in every aspect of this type of application
3) They have been doing this for years with a high level of reliability and one day turnaround.

Even more amazing, this level of service is delivered with a software and development architecture that was not explicitly designed to suport it. They have a four-person development team supporting a 500 screen, 200 table application with dozens of variations. Their application has grown up incrementally over eight years from a set of Progress 4GL scripts, that at one point became funneled through a Web gateway to create a homemade Web application server. All of the customizations are inserted directly into the same codebase, which is riddled with statements of the type “if Customer X then do Custom thing for customer X”. It’s a small team working with what has become haphazardly designed spaghetti code, currently being re-engineered.

Yet, it works. They are succeeding. They have more than 50 customers, have reached profitability, and are gaining market share. That’s a harbinger of the future, an existence proof for custom ASP’s.