Check this article that was submitted earlier http://googlesystem.blogspot.com/2008/02/gmails-humble-begin...
Gmail had nothing when it launched, but kept on adding features as the need from user arose.
This is generally the way to go, I think that the way you describe is stalemate at best, and disaster at worst.
However, changing one thing at a time is a good suggestion. Adding features helps improve the usefulness of your site and allows you to appeal to a broader audience. And if the users hate your new addition, they will sure as hell let you know.
I think most users accept, like, and even expect some evolution in your startup's product or service. The thing most users don't like is when you change something drastically, when it already worked well.
Justin.tv comes to mind. When they started, their site was about 4 pages, with the home page hosting the video feed and a few others for information. This worked for those who were interested in watching Justin and crew doing whatever it was they were doing. I remember the day they radically changed the design and layout of the site. The entire background changed, some buttons were missing, others were added. They had prepared viewers already, but the initial reaction was largely negative.
The reason for this change was to shift the direction of JTV. Users would browse through hundreds of feeds instead of only one. They would even publish their own feeds, and the site was redesigned to accommodate this.
This was a major change in direction for those who were watching originally, and many didn't like it. What JTV had before worked for what they wanted to do: Watch Justin. Now it became more difficult, but JTV took a calculated risk in making the change, and I think in the end it payed off because what they have now serves more people in more ways.
The difference is between improvements and overhauls. Improvements are expected and encouraged. Overhauls are only for radical changes in direction or to fix something incredibly broken. If it was broken, your users will thank you in the end, it it's a change in direction, you're taking a risk, and good luck with it.
1. The small but sometimes vocal group that hates all change. 2. People who don't need the extra features and who now have more work to do for the same results. 3. People who are using my programs a little differently than I intended, and whose functionality I broke.
With the sometimes exception of #1, if I'm honest with myself, these are all problems caused by my lack of creativity not my users dislike of it. Your experience may be entirely different.
The statement, "...they would not appreciate any major changes no matter how clever/creative/useful you think they are" seems to indicate that you might think the best source of ideas is you-- not your users.
IMO, the majority of ideas that you implement should come from your users. If you have a great idea that didn't come from your users (and you have an active/vocal userbase) you should ask your users what they think of it before you implement it.
There are probably several reasons for this:
* understanding change requires mental effort
* users have already evaluated your service once and don't want to keep reevaluating it
* users bring their physical world expectations online (e.g., imagine buying a sports car that is then transformed at some point into a family car because the manufacturer decided it would be a good idea)
If only.
Frankly, I have trouble remembering a single time that has ever happened to me.