During the early stages, a start-up might as well be described as 'chaos'. Simply put there's a lot to do (how's that for an understatement?), and never enough hours in the day. Given such an environment, it can be useful to create some consistency; for product development, one area that benefits from scheduling consistency is the release.
Every team has their own style of release schedule - some more regular than others. I've even heard stories of the development-branch being the production version and deployed every day - the theory being it pushes new features out immediately in the interest of rapid iteration, and forces the development team to fix priority issues ASAP! How’s that for chaos? Regardless of frequency, creating a consistent release schedule helps set expectations among not just the development team but with everyone involved in the product. Users have a general idea of when to expect fixes and new features, sales and business development teams can provide some indication to customers when to expect changes without always bugging developers, and team members can better schedule meetings - i.e., they'll know not to set low-priority meetings on release days.
A regular release schedule also helps maintain momentum, and by extrapolation, morale. Even the best-intentioned project managers and developers have had to adjust a feature-based release schedule at some point. Depending on the scope and scale, such changes to scheduling can be demoralizing - which doesn't help future development at all. By prioritizing a date-based release schedule over a feature-based one, developers can establish a solid emotional "anchor" around which to pick release-items that will create the feeling of accomplishment for the release cycle. Even if a major feature gets delayed by weeks, a regular date-based release schedule helps set an internal, intermediate 'metric' to gauge achievement.
At myGengo we deploy our latest changes - be them bug fixes or new features - every Thursday. Some refer to this type of development as Scrum or Sprints; but really it's just about maintaining consistency and reducing surprises (negative ones, anyway; we like positive surprises!). Releasing on Thursdays gives us Friday to debrief, review, and make any last-minute patches before mentally settling in for the weekend. So far we have found this process has helped the team in general manage its energy, both physically and emotionally.
Whatever your release schedule and level of consistency created by your development environment, remember that shipping is a feature. You'll be much happier getting something that kinda works in the hands of users rather than a perfect solution in the hands of nobody :)
