There are already a lot of great answers to this, but thought I would share a relevant quote that I heard (can't remember source):

"If you're not embarrassed by your product when you release it, you've released too late."

Release when you've got enough functionality for Minimum Viable Product and remember you also need to be able to measure and observe the behavior - how much do people like it? Is it achieving the goals you set for it?

The combination of those two things and challenging yourself to release earlier than your comfortable with are the key to being able to evaluate and iteratively improve what you deliver.

When it's early, you don't know what's "right."

That's not just true of features; it's true of architecture too. Anyone who claims to already know exactly which DB queries will be responsible for the bottlenecks or exactly how tables should be designed is kidding themselves.

Also useful resource is Steve Blank's blog, where he talks about Customer Development:

http://steveblank.com/

For a much deeper (and dense) explanation of Customer Development, Steve Blank has written a book, called Four "Steps to the Epiphany"

http://www.cafepress.com/kandsranch

The answer is the minimum viable product. You should release with the goal of testing your assumptions. How can you get it 'right' without knowing what the marketplace wants? If you have already had successful products in this space, you may have a feel for what the marketplace wants but otherwise your guesses could be wrong.

Building a great architecture that supports functionality your users don't end of caring about is waste.

http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html

http://www.startuplessonslearned.com/search/label/minimum viable product

I always have in mind the 20/80 strategy.. Release the app with 20% of planned features that 80% of users will use .The quality of code is important for future development so this is a must.

You want to release as soon as possible, but you want to get the architecture right. Don't be a software purist but in the minimum have some sense of clean, robust, and modular code. That way, when you launch you can spend more of your time adding new features and less time fixing bugs.

I started my software almost 10 years ago. It's still in alpha.

So from my experience, I would definitely tell you NOT to do what I've done.

You should release as fast as you can to get a Version 1.0 that has the minimal capabilities you need to differentiate your product from what will be your competitors.

I'd recommend releasing early - you can use feedback to make your architecture better and get more realistic use cases.

It's a delicate balance, but with SaaS, I think you should release as fast as you possibly can without sacrificing the core quality of the product. Nothing is real until someone is paying for it. Once you're live, continue to make rapid releases -- preferably one release per feature -- to match the needs of your customers.

After you've got some customers on board and money is starting to come in, don't be afraid to slow down feature work when necessary to refactor and improve your code. Code quality and product quality are not synonymous, but the former leads to the latter. The easier your code is to work with, the faster you'll be able to roll out new bug fixes and new features.

Not only you need to release fast, and forget about features and scalable architecture...

First thing to do is to release a mockup and see what happens. Anybody finds your site? Anyone willing to leave her email address to receive a note when the product is released?

We do this, and we get hunderds, sometimes thousands of users before we even release anything.

while there needs to be a balance, however, for a startup I would agree with what most people are already saying. It is better to release fast than to try to perfect the architecture at first. It is instead better to release something in the market that works and is of reasonable quality and then get feedback on it and iteratively improvise on it. Focus more on the selling features and less on others. Architecture also can be improved as the need for scaling up happens.

Think Fast!

A company that you should look at, if you are not familiarly with them yet is IDEO. your question strikes at the heart of one of their rules to success: Fail faster to succeed sooner.

Develop in quick iterations. Don't get attached to your first model, it's going to change. If you don't get into the jungle, you'll never know the tiger.

this is why companies roll out with private Beta's. Understand > Observe > Visualize > Evaluate & Refine > Implement.

Do it quick and often and over again. You need to operate without a net, too much time deliberating is a harmful net.

I agree with Del Putnam above. It wouldn't let me vote his answer up, so I added this one.

Forget about getting the architecture right, especially forget about scability. Only thing you can't forget about is security, security problems can eat you alive.

First things first get it out. You can always fix it later. Also your customers will shape the product what if you spend scaling or designing "Y" feature and then see no one actually cares about it?

It's a web app so you can fix on demand, so release early, release often, forget about perfect code, scalable architecture.

But you need define the release as well. If we are talking with a launch and lots of advertisement then yes you need to think more about getting things reasonable right before release.

If we are talking about "a release" where people start to use your beta version then go for it.

FYI: This is not my first hand experience as I'm not in the business of web for quite a while now, but this is more of an observation and personal opinion on the subject

Releasing faster with bad architecture is definitely not advisable. You end up with support calls/bad name, migration issues etc etc. They just get added to waste/cost. I think the answer lies in getting a right balance between these two. From my experience i can say that more importance should be given to right architecture/performance etc rather than quickly releasing a bas software. The fact is when the right architecture is in place, your software can just takeoff from there! You can focus on features over a robust infrastructure.

Regards, Siddharth

Release fast and improve it on a weekly basis.

In my opinion releasing early and fast, with just enough features to catch user's attention and just as much bugs to not scare them off is better then waiting. Especially trying to polish the architecture is not that important.

Releasing a web application is a matter of balance, but architecture is something that could be fixed just any time. Focusing on delivering useful features for your users/customers usually works better then endless technical discussions.

Both are more important :)

It all depends of course. If you are launching your own product, you need to get it out and collect feedback, this is probably the single most important thing. If you delay it, you might be building something people don't want, and no matter how good the architecture, it will be a waste of effort and time.

On the other hand, you need something reasonably stable and good. If you know you will surely need some extensibility points from the start, spend the time and make it good. In general, if launching an app that would only be used by non-tech people, I would launch as fast as possible, they don't care about architecture - it's invisible.