I think a good strategy is to get your minimum viable product out as soon as possible and call it a beta. Don't charge for the beta and provide plenty of warning to existing clients by signalling early on your intention to charge for some/all features when you are out of beta. After a private beta period, this is how I'm planning to handle Mighty CV, a resumé building app with hacker leanings that I've been working on. I'm looking for private beta users to kick the tyres a bit, so if you feel inclined then you can sign up for the private beta at http://www.mightycv.com.

I always remember being impressed with the way Heroku did things in the early days. After beta feedback it must have become clear to them that it made sense for them to rewrite from the ground up. This left them with a beta platform which they gracefully continued to support, renamed herokugarden, whilst also rolling out the paid for service. They then provided plenty of info on how herokugarden users could migrate to the new Heroku platform for free too. I'm sure they learnt a lot early on about what direction they needed to take the Heroku platform. Anyone remember the web based code editor? Without the early feedback from beta users perhaps they would have pushed more in that direction instead of changing course towards the Heroku we all know and love today.