Selling SystemsForge

It is an interesting position to be in. We can build rich, custom web applications much more quickly than most anyone else as we've developed an extremely efficient process for doing so. The question then is how best to take this to market.

Initially we were focused on working with resellers, providing wholesale web apps. That is still a focus, but we are also considering other approaches to selling our services.

I've been doing a lot of work around a process for managing application development from concept to completion and believe we're now in a great position to develop web applications directly - specially in the $10,000 - $50,000 price range (we don't do tiny projects and as the scale and the amount of custom development and consulting required by a project grows, the benefits of our systems become less compelling).

The question then is how best to take our capabilities to market. In the early days I was very excited about the benefits that the software product line offered. Being able to "build anything, change everything" focused on the fact that we were able to get the efficiencies of off the shelf software while still providing the flexibility of custom build applications in terms of customizability. Of course, while that is cool and benefit focused, it isn't a benefit that most people building web applications care about. It'd be like selling application development based on the fact that you use agile processes or test driven development - unless you're selling to an extremely sophisticated client it simply isn't solving a problem that they know they have.

There are way too many website developers out there for me to be interested in positioning us as "yet another website firm" without a unique position. The question is what USP to choose . . . What are the problems that someone buying a web app has that we are uniquely able to solve?

Industry Experience
One approach we could take is to pick our key industries and either create micro-sites for each or to pick one and go with it. We most frequently develop content management systems for professional service companies, e-commerce applications for retailers and sites for not-for profits. It would be fairly straightforward for us to create practice areas around any or all of these and it would also be quite easy to market to these specific niches - from trade shows and industry publications to speaking at events. The downside is that this doesn't really take advantage of any of our unique benefits - it would just allow us to show that we were smart, capable and able to build better apps more quickly and at a fair price. We could definitely build a practice out of this, but it would take a while.

Smart Clients
We consistently do better when selling to more knowledgeable clients. We're really good at what we do (very few people with the skills we bring to the table are working on such inexpensive apps) and we're usually more successful selling to clients that value our expertise and knowledge and who have a better understanding of what can go wrong with a project and the value of hiring great people to build their applications. This isn't a bad point, but it isn't exactly a positioning or a strategy - just something to bear in mind when developing our initial client questionnaires.

Time to Market
One thing we can do that is very hard for most firms to replicate is deliver projects quickly. We're often backed up with other activities, but it would be fairly easy for us to restructure the business around building "websites in a week" - including capturing requirements and custom programming. The SPL really allows us to build rich applications quickly, so for the small number of people who genuinely need an app in a hurry we could offer a pretty compelling proposition. The issue of course is (a) that most people don't need an app in a week and (b) that most people who THINK they need an app in a week don't. For people who really needed an app quickly for a good reason it'd be great, but this could also attract the "hurry up and wait" crowd who need a quote tonight and the app live by Friday and then don't call back for another three months because they got busy with some other emergency.

Solving Business Problems
Another big story is the fact that we're capable of solving business problems rather than just writing code. We understand sales, marketing and the operational drivers for productivity apps and can help companies to ensure they're solving their business problems efficiently rather than just building them a buzz-word compliant site.

Reducing the Risk
One of the areas that interests me the more is reducing the risk of website development. From a clients perspective, website development kinda sucks. You look at a list of proposals by people you don't know to complete a process you don't understand and you hope that the one you pick will complete the project on time and within budget. Of course, as website developers we know that (unless we just work on an hourly basis), the risk cuts both ways. The risks to the client are that we'll not deliver, take too long, or create a buggy app. The risks to us are that the client will need a huge amount of hand holding, want a large number of revisions, or be unable to provide content and decisions in a timely manner - dragging out the project and therefore the time that it takes. One thing I'm thinking seriously about is a way of structuring the business to allow us to build a website and then the client only pays for it if they like it. There are a lot of details to iron out in terms of pre-qualifying the prospects and managing the risk, but if four companies are offering a proposal and we're offering a completed website, I've got to believe it'd be more attractive for the client to see what they're getting before they pay for it and I believe the extra production time would pay for itself in lower sales and marketing costs if we structured it just right.

How do you position your capabilities? What do you think of the above approaches? Input appreciated!