What's more important: releasing early or getting it right?


From your point of view and experience, what is more important when you are building a web based app:

  1. release ASAP (eventhough it might not follow best practices) or
  2. release it rather late as long as you get the architecture done right

Currently I'm in the middle of the two. Somehow having background as technical person, I really want to get the architecture done right and follow best practices but sometimes if I have to adhere that, I would spend more time doing the research.

EDIT When I say getting it right, it's more to the underlying architecture instead of features. It's more to scalability, code maintenance, security architecture, best practices, DRY, etc. Sometimes I can get caught up with architectures & best practices without releasing any feature to the table.

Software Infrastructure Research

asked Oct 20 '09 at 17:26
1,342 points

24 Answers


Release your software earlier than you think you should. Then follow up with quick feature releases.

Software, like art, is never finished. But thankfully, due to the nature of software, what you put out theredoesn’t have to be static, especially if you are running a web-based business. It’s easy to roll out new feature updates after your launch.

Don’t let this need for speed push you into releasing something with tons of bugs. Release on quality, not on date. Instead, put fewer features into your initial roll out. You can always add more features later.

The beauty of this model is that it lets you get early feedback from your customers and allows you to make changes…maybe even before you implement a feature. So, listen to what they have to say. And follow up on it. Make your customers happy and they will stick with you.

If you have to prioritize, put your best stuff out front. Put your most interesting feature on the front page of your website. Make the best feature of your software completely obvious. Show everyone why you your steak sizzles.

I you get someone hooked with the really cool feature, they will hunt around for the more mundane ones. If you lead with the mundane, they will move on before they even understand what you are about.

Software is a journey, not a destination.

answered Oct 20 '09 at 18:20
Del Putnam
1,031 points
  • Addressing feature requests from paying customers is one way to take your mind off over-engineering. – Jeff O 14 years ago


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

answered Nov 17 '09 at 03:39
446 points


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.

answered Oct 20 '09 at 17:35
316 points


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.


answered Oct 20 '09 at 19:58
88 points
  • +1 I totally agree. Whoever said architecture doesn't matter hasn't worked on a critical project and had to deal with horrible code. With the right architecture in place you can release code faster and with more reliabilily. – Joe A 14 years ago
  • As a developer, this is sound advice, but over-engineering software no one wants to buy is the best way to lose money. At some point the business side has to prevail. Refactoring later may cost more, but lack cash-flow can kill a business. – Jeff O 14 years ago
  • Why not? Actually, you have a 50/50 chance that no one wants your product. So who cares if it was architected well? Cut your loses before your even release by not worrying so much on a clean architecture. The changes your users will force you to make if your product is successful will probably break your clean architecture anyway. – Alain Raynaud 13 years ago
  • No one releases with "bad architecture". You don't know it is bad until it is tested in the real world. I am not trying to say that you can't know if something is truly good or bad but really, if you have something that you think could be released, surely you don't think it has bad architecture. – Kenneth Vogt 13 years ago


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

answered Oct 20 '09 at 21:48
Scott Brooks
51 points


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.

answered Oct 21 '09 at 22:22
Oleg Kokorin
459 points


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.

answered Oct 22 '09 at 08:04
Nate Kohari
151 points


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.

answered Oct 20 '09 at 17:36
166 points


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

answered Oct 20 '09 at 20:12
The Dictator
2,305 points
  • The book "Dreaming in Code" is a perfect example of how impossible it is to know how much architecture is going to be needed at the start. – Jeff O 14 years ago


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.

answered Oct 21 '09 at 17:45
Adam Webber
314 points
  • Thanks man. That was really good and encouraging. – Jpartogi 14 years ago


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."

answered Nov 17 '09 at 08:25
298 points


If you write iPhone/Mac software for the appstore then watch out you don't get a poor rating because you had released too early. A 1-star rating sticks around forever. Polish core functionality until people have no reason for giving 1-star ratings and then submit it to the appstore.

answered Feb 21 '11 at 06:30
111 points


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

answered Oct 22 '09 at 08:30
Dan Finch
11 points


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"


answered Nov 17 '09 at 05:32
Darius Dunlap
256 points


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.

answered Nov 17 '09 at 05:42
16,231 points
  • +1 For avoiding premature optimization. Avoid all of the things you know will be shooting yourself in the foot, wire up measurement for both performance and business metrics. Care, feed, and improve your successes and eliminate your problems/failures. – Winfield 14 years ago
  • Wish you would expand on this. Especially the piece of when its early you don't know what's right so the obvious follow up question is so how do you know what is still viable as a minimum product to get feedback from? – John Bogrand 14 years ago
  • You don't know. I've asked Eric Ries that exactly question and he can't give you a formula either. Best to worry less about those definitions and just go. If you're working on code or talking to customers, you're doing something useful; everything else is probably a waste of time. – Jason 14 years ago


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.

answered Nov 17 '09 at 07:48
211 points


Many of the answers above talk about "releasing as fast as possible," which is too vague from my perspective. The principal choice you have to make is whether to let a certain date or a certain level of completeness determine when to release. My belief is that you should set a release date and stick to it-- even if it means stripping out features that were intended to be part of the release. This will create a precedent for all future releases being linked to specific dates and assuming missing the release deadline is not an option, it will allow you to determine which projects and teams are able to produce significant, functional releases versus those which are not. This practice will also create a culture in your company that missing deadlines is not tolerated which will force people to prioritize and come up with the features that will matter and be delivered on time. Naturally, the notion of iterating and releasing often still applies, but always on the basis of fixed release dates.

answered Feb 19 '11 at 02:29
871 points


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.

answered Nov 13 '09 at 14:43
1,471 points


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.

answered Oct 21 '09 at 21:39
96 points


Release fast and improve it on a weekly basis.

answered Oct 20 '09 at 17:49
333 points


Release fast and release/update often. And yes care and attention should definitely be given to the fundamentals.

answered Feb 21 '11 at 11:07
121 points


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.

answered Nov 15 '09 at 04:19
Joe A
1,196 points


This is a great topic. I'd agree that releasing faster is better and getting user feedback from a basic set of working features is much more valuable than fretting over all sorts of future scenarios. I'd devote a bit of time to envision the blue sky a bit at the beginning, especially for the non-technical stakeholders. If your business folk see a feature or change very quickly, it can really mess up your ability to manage expectations down the line, e.g., something like "well we built this secure, private thingy with all that encryption and stuff - now how do we put it on facebook?. What's that...about a week?"

answered Feb 19 '11 at 03:31
840 points


Deciding when to release is a balance of many factors. By putting off the release of your product you may start a vicious cycle of continuously redefining your goals, re-doing work and therefore never releasing the product at all.

You should ask yourself the following questions:

  • Do I have a consistent definition of 'right'?
  • Am I adding additional features rather than releasing versions?
  • What feedback am I getting on the work I have done?

You should start by writing out a roadmap for the product development project. You should ensure that you set realistic 'barebones' features for the first version. Get the architecture right on this, but don't worry about including non-core features. Stick to the goals, and release once the product is of sufficient quality.

You may want to release to a small number of people or segment of your market. This will give you feedback on the core product, and allow you to refine your future roadmap. Feedback on your project is important, so make sure you plan in time to analyse what you are doing after you have released.

Prioritise your development. Security is important for most projects. Scalability may not be initially. After the initial release then user-feedback can help guide your priorities.

Don't let perfection be your enemy!

answered Feb 20 '11 at 03:11
111 points

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics:

Software Infrastructure Research