I launched TweetAfter.me with a minimal feature set. I had (and still have) many ideas to enhance the service, but made a conscious decision that none of them were necessary on the very first day. This allowed the service to get in front of users faster, allowing feedback to be received quicker, which ended up changing my view of which features were more important in my backlog.

Besides deploying with a minimum feature set, I also felt it was important to reduce recurring costs until higher revenue is generated. Let’s face the facts. A new product or service has zero users when it launches (TweetAfter.me went live on 02 January 2011), and no product or service is guaranteed to increase users. Therefore, it makes sense to lower your recurring costs to reduce your overall burn rate.

Sometimes that includes making tough choices regarding features. While sometimes, you completely remove a feature, tailoring the feature may be the only solution. A real example from TweetAfter.me is that tweets are currently scheduled in one hour increments. The goal has always been to provide a lot more flexibility in duration between tweets, default schedule durations, etc. However, right before deployment, I made the tough decision to reduce the initial scope of these features. Why?

To achieve my initial goal would have had a recurring cost 12x more expensive then current recurring costs. With zero users on day one, it made little sense to pay 12x more money for features of a just-launched service. The truth is that startups should test the market to verify those features are needed. If they’re needed, then users may pay for them, increasing your return on investment for these features. 

Therefore, just don’t assume you need expensive features on day 1. Higher costs give you less time to validate decisions with customers. On day 1, one of your highest priority goals should be to give your startup enough time and money to reach customers. If you spend the money now, you lower the chances of succeeding regarding that goal.