Perfection is a myth and it will never end, instead of wasting time, I prefer to put my product out and learn from people who at the end of the day will use it. That way I can constantly iterate and improve. To me, any product that closes a user loop (the user should get some value out of the product) can be launched. So there is literally no downside in launching.

I think it depends. You can never achieve full perfection, its not possible. However releasing a product with too many bugs will also scare users away, so the question to you is -- what is the level of buggyness that you can accept? My solution - release to a small group first - you must know a group of people that will try it out, offer it for free and start collecting feedback, honestly we did the majority of our improvement coding after people started using the app. We implemented a whole new feature after initial release, based on feedback and we are adding more daily -- the development journey never ends. Dont be afraid of bad reviews and failure either. My first business was a disaster, the first ever review was so bad, but we quickly moved things around, fixed the issues and people still used the product. First impressions may last, but its not the same people who see your product everyday. New people will come across your product daily, and to that new person -- it will be their first impression.

Users' feedback is probably your best ally in the pursuit of perfection... let's launch asap and start the journey towards the best version of your product!

So there's the school of thought that says release your MVP as soon as possible so you can start getting feedback. In my opinion, it really depends how buggy your product is because there will never be perfection. There's so many factors to consider but if you keep delaying the release because your product isn't perfect, you might spends months or even longer for a product that you don't know if it has market fit.

MVP There is no such thing as perfect product. There will always be bugs, there will always be new features you want to add, there will always be something you can do better. So build MVP and launch it!

It may sound like an easy question, but the truth (like always) is way more complicated. Everyone always says that you should launch as soon as possible, bugs and all included. I rather focus on VALUE instead of PERFORMANCE, and I'll explain: Launching a product that is super buggy and DOES NOT deliver any value, will not help you at all. On the contrary, launching a "perfect" product that does deliver value is most likely a waste of time. Try defining the bare minimum needed to deliver MAX value in MIN time, do that part well (in user experience terms) and set it out to the wild. As long as the product works for the user 80-90% of the time, I believe that's enough.

Honestly, it absolutely depends on how buggy it is. If it crashes when I try to launch it - definitely don't launch yet. Bugs are a very relative thing. I worked for a company that for 2 years straight had over 400 open bugs (they had a pretty heavy infrastructure in place) and those bugs affected the system very differently. The question is not how many bugs you have, or how buggy the system is, but rather how many of them are critical? If the majority are design/frontend flaws, then just go ahead, users don't care that much, as long as the core functionality is operational.

Well it depends on your situation: You have a hard deadline... Identify your MVP and what's needed to achieve it. Fix those critical bugs and focus on hitting your deadline. If your project is buggy to the point of not being very usable, then you may want to try to move your deadline back, but remember "perfection" is the enemy of "done". You don't have a deadline... If you have the opportunity to deliver a quality product, why not take it? Just avoid scope creep (adding "features"). Identify your MVP and focus on making it rock solid. If you have ideas for improvements, make a note of them and add them post launch - unless you are convinced that the feature will give you a significant competitive advantage or increase adoption (but that can be a slippery slope, so best to defer till after launch) Personally I don't subscribe to the "fail fast" mentality... if I'm not giving my idea an honest try, then it's really hard to identify what the problem was if it fails (was it a crappy idea, or crappy implementation?) My $0.02

In my opinion, it is okay to have bugs, but overall the main gist of functionalities should work fine. Otherwise, a user may get confused and lacks patience to keep using your stuff.

Same stage, same questions :) Our rule is: - bug that really disrupts the user flow: crash, not saving, destroying user created content etc --> needs to be fixed - slowness, fuzzy behaviour, timeouts... case by case but mostly: launch ! - UX improvement, beautifying... definitely on the backlog :)

2nd option.

We had such an experience. Our product was buggy and not user-friendly. We spent money on marketing but the result wasn't enough good. What did we do? We updated it 100 %. It was worth it.

Nice thread

I know there are different schools of thought on this; I think of it as a chart with 'critical bugs' on the x axis and 'size of launch' on the y axis. If you're launching to thousands of users and it's really buggy, probably not the best idea since you might turn away people + you just won't have the capacity to fix all tickets. If you have a buggy product and launch to 100-200 people, could be great to get the feedback you need to move it forward.

Depends on what kinds of bugs do you have. Definitely your app shouldn't contain critical bugs overall. Core featues should work correctly too.

I try to opt for “satisfied but not perfect” there is something to be said for someone who cares and takes pride in their craft and only puts something out that they can personally endorse. I think the technology community has a toxic idea about how it treats product and customers with the often used but misunderstood term MVP. As a creator you must know when something is done, what the product needs to achieve, but you should never put out junk for the sake of speed. Sometimes, it’s done, when it’s done. The hard part as a creator is knowing the difference. I was once told by a really great designer that “design is about constraints” it’s the decisions you make within these constraints that can make your product human and memorable even if you were striving for the illusion of perfection.

I wouldn't launch a buggy app. There is nothing worse than features that don't work. Instead, I would suggest focusing on a small feature, which solves a problem, making it work, and launching it ASAP.

Build a bug free product. If you were a chef entering a cooking contest, you wouldn't even think about cooking a recipe if one or more essential ingredients were missing. Lunching a buggy product will waste your opportunity to make a great first impression.