views:

174

answers:

8

Is it a good idea to have a website that is setup with basic functions like posting tutorials and registering, or wait until to you have a rating system, commenting system, RSS feeds and much more?

+3  A: 

IMHO it's better to have a site with basic functionality and let visitors see it growing through out the time (so they know that site is alive and someone is actually developing it)

Too bad though, that most of the sites i saw using this strategy never get further than first version with basic functionality. And then they day. In a few months.

Eimantas
Great advice just what I was thinking.
There has to be a balance with this strategy, as one bad experience with dodgy code that spits out errors, could put someone off for good.Remember most of your target audience are not tech savy and expect computers to just work.
Chazadanga
+13  A: 

Today's wisdom says "Release, release, release". I think it was Dharmesh Shah (www.onstartups.com) who said "If you're not embarrassed by your software, you waited too long to release it!".

Get it out there, get people using it and get people talking about it. You'll get invaluable feedback (especially if you can charge for it). Also, write a blog from day one so that you can interact with your users.

Years ago it used to be a case that we'd hold off because we weren't sure if we could overcome the technicalities and we wanted to do the hard bits to discourage anyone following us. Today it is much better to get an understanding of whether people will actually use your software as soon as possible. You could end up saving yourself a lot of time and money.

Chris Arnold
Great advice and info.
Exactly. Often, an early release will reveal a certain feature is more urgent/not as urgent as has been originally thought. The only people who can tell you that are the users.
ginozola
Agree. Develop the minimum functionality and get it live. You've gotta get your product live and see if it resonates with users. You will learn very quickly where to spend your resources.
pbreitenbach
+1  A: 

If the functionality you already have can provide for a complete project in the eyes of the users, publish it.

You will be adding new features continuously and thus provide the impression you're working on the improvement of your site all the time. New coming features will also keep users interested and motivated.

What is more important, even on basic features you will be receiving users' feedback which will guide you further and maybe somehow influence how you implement all the advanced features that are waiting to see the daylight.

Developer Art
another great comment.
Agree it should have enough features to at least be useful to the users.
HLGEM
A: 

Yes, in fact agile methodology which is so widely accepted these days suggests that you release in fully functional and well tested parts. Obviously your first iteration should include the essential features that make your service work. You can then add features in another iteration.

Sergey
+1  A: 

There's no one answer. Depends on the business situation. I do agile/XP development, and get the software in a stable and usable state as early as possible.

I encourage our clients to get it out there to start getting feedback. This is great, as it always affects how you view the software you are building. And it definitely makes sense if you have the ability to digest the feedback and react to it.

But there are marketing situations where you need to hold back. It's naive to think that there's only one way to release software in the modern world. There are risks inherent in releasing early, as you have to be careful to set expectations carefully with your audience, and you simply may not have the ability or inclination to do so. It may be easier to stick with more traditional release cycles.

I still believe strongly in early releases, even if they are password protected. They reduce project risk and stress. We know there are no hidden problems with releasing to production, since we've been doing it since day one. And it also helps keep developers out of the hot-seat, since we always have something up and running. Demos and PR moments aren't as stressful as they are just a regular part of the process.

So from a software development standpoint I recommend it. From a marketing standpoint... well this is SO and we shouldn't get into that here. :->

ndp
A: 

Start it as a Beta. Here is a list of the top 100 beta websites. Invite only can be a good way to restrict the number of users who can use it.

Marius
A: 

The real question here is, how do you know that it's fully functional already?

When StackOverflow was released in public beta there were a bunch of features that weren't here yet. If I recall correctly comment upvotes (if not comments altogether), indication of duplicate question on closing for "exact duplicate", Recent Activity, and a bunch of other stuff were not available at the time.

The only way that some of these functionality came about was because the public asked for it.

Until you come out with a public site, it's nothing but vaporware, and you wouldn't know how the take up would be. Releasing it in public beta would allow you to get valuable feedback piecemeal, and build word-of-mouth promotion.

It's also a lot safer. Remember Cuil? They were hyped to be some sort of Google killer and released their site live, fully functional, in a single day. Their servers crashed catastrophically -- not because their search software sucked (it might have been better after all) but because their infrastructure couldn't handle it.

Public betas on the other hand allow for slower, more gradual take-up until you have a better idea how your site performs (CPU/memory/bandwidth wise) and will allow you to respond accordingly.

So by all means, release that site (make sure that it's clearly marked beta) and start mining for that valuable user feedback that you need to make your site awesome.

Jon Limjap
A: 

No Software is ever fully-functional.

Use cases evolve as users come along and find new and interesting uses for your product.

You'd be far better off designing the site to be easy to update and with minimal downtime during update then trying to guess who your users will be and how they will use it.

sal