A Process for Web Application Development

A friend and I were sitting at lunch one day discussing web application development. He was talking about the models that a number of these “fresh ideas” start with, “it needs to make money”. His notion was that this is the wrong approach. His point was that you should build an application that you would want to use, and then let your users drive a number of your features. You can find his post at Offbrand Turnips. What I believe is that his fundamental idea is right.

So many new ventures fall into the trap of wanting to make money or be the next big social thing or get into advertising that they forget to produce a quality product. As my friend says, “Most of the new wave of Web 2.0 apps are just social media spinoffs waiting to be bought out rather than building apps…” What is the point of making an application that doesn’t work. Sure any press is “good” press, but what about the users that expect your product to work? Thus, the idea is that while you need to make sure that you have a sound business idea, don’t jump the gun on wanting to make a profit or blowing your cash on marketing gimmicks. Make sure that you have a good sound product first. Make sure that your application can stand on two feet before sending it off to “fight the Persians”.

So how does one, or a small team, do this? Easy. Prototype your product. Put it into a closed alpha/beta. Generate feedback. Rework the application. Expand the beta or even do an open beta. More feedback. Rework once again. Then launch. By this point you have accomplished a couple of things. You’ve delved into viral marketing, you have some branding, and you have a userbase. If people come back for your expanded beta then you have a pretty good idea that your product has something to it. If not, time to hit the whiteboard.

This is the way I look at it. We developers view software development from a couple of perspectives. There is first the waterfall school of thought and then the agile school of thought. I’m a fan of agility. Thus, I feel it’s appropriate for many parts of a company, including product launches. If you look at the steps above as sprints then you involve people in fast paced ever changing iterations where they feel that their contributions are being taken seriously. When that happens, people will stick around to see what the next chosen feature is that will be released. Your clients, aka users, will be able to tell you what they like and dislike about how you do things. And, by working in these sprints they will see results almost immediately.

So, by the end of this post my goal was to point out that monetizing your product is not the most important thing when creating a web application. Making sure it works and that it is something you’d like to use is equally, if not more, important. Without the product, you get to monetize nothing. And, paying huge advertizing campaigns can be a waste with the social media market. Thus, closed betas are likely more productive in attracting the “easly-adopter” crowd. Once you have users and some feedback you can rollout your pay-for products/features and begin to pull in some revenue.