techsoldaten's Journal: ASPs

So, you say ASP to a Web developer, they say 'Huh, you mean Microsoft?' Now, I deal exclusively with open source developers (except for the occassional Flash and Java guy) and there is a basic unfamiliarity with the term and the concept amongst many people in this area. It's not like I talk to thousands of developers or conduct any research on this, but the basic conversations I have with people always start this way.

I'm not trying to find a new way to phrase things here, only to point out that not everyone is an ASP developer. My company is starting a new line of business where we are going to be deploying 'ASP services'. When I say ASP services, what I mean is hosted applications built on top of existing FOSS products. In some cases, we are going to be deploying versions of these products with value added features we put in ourselves to make them 'better'. In some cases, we are going to be using them to deploy applications we build on on this platform to deliver specific solutions for various markets.

As a someone who has been a victim of good ideas in the past, I am entering into this with eyes wide open and looking at all the things that could happen. To start with, the company has become transparent about our plans with the greatest resource we have - our people. I made the entire development team aware of what we are looking to do and explained all good ideas are welcome. I have been speaking to SMEs with experience in the area, and found some good people locally who could fit the bill. There is a lot of enthusiasm around this push, and some developers have told me privately they would be willing to forgo extra salary to put in extra time.

All the people stuff is encouraging, but no substitute for proper business planning. I keep meaning to read that book on how to run your own successful ASP service from a manager's perspective but can't seem to find a copy (recommendations are welcome). In lieu of some plan someone else has already done, I am actually writing a business plan to guide our efforts. We are starting with a single application with the intention of using the lessons learned as a blueprint for what to do with the next one. We know that we are not going to get everything right the first time around, but we are going to learn enough to guide us as this service expands.

First off, we have performed ample amounts of market research, which has broken down into several categories of inquiry: attracting customers, understanding the competition, and pricing our products / services. As this is development on an open source platform, our market research has included supporting the community and evaluations of other companies attempting to use this platform in similar contexts. Our customers will be SOHO businesses and small agencies with a need for... uh... maybe that's too much detail. But we know there are about 700,000 potential customers domestically, more than that internationally, and getting just a small share of that sector will make this a huge success.

Our competitors are a collection of other ASP services with varying strengths and weaknesses. There are a lot of competitors in this market, at least 20 of them, and there are some big divisions in what people find useful about each one. Concerns generally break down into 2 camps and we are looking to provide enough features to avoid being classified in one or the other. This should serve to distingush the service and give us a place of special mention for people talking about the market.

In terms of pricing, we know the pricing policies of our competitors and think maybe kinda sorta we can do it cheaper. We are in a position where we don't need to make a huge profit off this to be successful and our plans are to price in line with the market and offer incentives to customers who sign up early that would put us below our nearest competitiors.

In terms of the community, there is an active community of 1000s of developers working with this platform. Our strategy is to provide the community with patches for specific issues related to scalability, new modules we have developed in house, and reports about our server infrastructure that will serve as guides for other shops looking to go this route. This should win us some points with the powers that be and generally evoke feelings of respect from the people who's hard work makes this all possible. Should the service actually make any money, we will start making strategic donations at that time.

Secondly, I am looking at the costs to deploy the service. This breaks down into 3 categories: development, scaling, and support. Development is the cost to build the version of the application you are hosting. To my great astonishment, off the shelf FOSS products don't always scale to meet the needs of thousands and thousands of concurrent users. We have had to scrutinize the platform in 100 different ways already just to figure out if this is possible, and we are satisfied we understand the challenges of deploying the core platform and have strategies in place for how to scale it. Beyond just the platform, there is the application being built on top of it. In a Web 2.0 world, everything has to be usable and include enough AJAX to make people go wow. We have worked through the issues surrounding functionality and interface design and gotten it to that 80/20 place. There is a good amount of development to be done, and much of it is going to be just centered on usability concerns.

But the costs of development, in this case, are not limited to the actual expense of building the application. My company has a core consulting service that also does a lot of business. Right now, we have close to $500k in work in the pipeline, and we get about 4 requests for more work each week. Having developers build the ASP application means we are going to have to scale back on the consulting work, and the question is how much do we scale back. We also have to hire people to work on the ASP, and we have to hire people who really are SMEs in production processes. It's a matter of finding the balance between payroll and infrastructure versus intentionally forgoing work to get there. The company has never taken any debt and we have worked hard to pay off occassional investments by principles (well, everyone except me). The idea of not being able to directly bill a client for each hour worked is new for us, and overcoming this mentality makes drawing this line a little more complicated. Basically, we want to stay far enough substinence levels we can make sure there is something left over at the end of the month, and avoid doing so much we have to hire too many new people to get there.

The second component of cost is scaling. Developers hear this and think servers!' Businessy types hear this and think 'FTEs!'. If I had to come up with a definition for this word in this context, it would be providing sufficient resources to ensure the proper operation of the hosted service and meet the demands of the market. We think we are going to have to hire 2 full time support people at the time the product launches, a marketing person who can actually talk to potential clients and get us some press, and a second product manager (one for UI, the other one for new additions).

There will need to be more servers added as time goes on and additional development, and these are parts of the cost of scaling. We are going to have special server installs running the applications and are currently evaluating the costs of doing it through a partner or building everything out ourselves. We have a choice of co-location providers who are willing to charge semi-reasonable fees.

The next thing is marketing. To make a product successful, people have to know about it. We plan on going commando on google ads and blogs to start, including a private beta to a number of bloggers in this area. We figure they are going to find it boring, which is why we have worked in some clever bits into the application that poke a bit of humor at other players in the market. There is an outdoors sports theme to the whole concept of the application that we are going to play off of to give it some class.

The product is going to have a bunch of distinguishing features that set it apart from the other systems. Hard to talk about what they are, but there's 4 of them.

Anyways, lots of work just planning it that I am not getting paid for. Biggest stressor about it all is doing the math around scalability, hard to predict and few case examples to work off of.

M