One of the fundamental principles of agile programming, and something that’s leaked out in to other less trendy development methodologies is the notion of “release early, release often”. In a nutshell it says you should release your software product quickly and then update it when you have a new feature or two. It’s fundamentally different to the old style approach of releasing an application when it was finished and everything was complete.

On the whole it’s a great way of doing things. It limits scope creep. It allows you to get feedback very early in the project. It ensures you’re moving forward. This is all brilliant. But that’s not to say it’s perfect.

The problem with “release early, release often” is that users often expect to see more than you’re giving them. Someone signed up as a “beta user” still has expectations that the product they’re using is going to work; releasing before your feature set has the minimum number of things required to make your product useful will put off the users who are most likely to be enthusiastic adopters of the product once it’s complete.

Broken things, ugly things, even experimental things are features a beta tester will take in their stride. Missing things though, especially things that limit the functionality of the product to the point where there’s no reason to use it, mean there’s no reason to carry on trying. The user will walk away.

That’s a key problem for a start-up. Coxing users back after they’ve given up on your app is far more difficult than getting them in the first place. I’m not going to mention any start-ups by name, but it’s something I’ve seen several times in the past month, and I have given up on the app each and every time. As yet I’ve not been back. I wish those apps well for the future, but I also know that the start-up I’m a part of at the moment will be learning from their mistake.