Should startups write good quality code or just worry about delivering the product asap?

I've been obsessed with launching a perfect product. This meant tweaking the app time and again. But I feel that launching a product with just the right amount of performance would have been better for me. No user will care if the app is 0.5 sec faster or the query is optimized correctly or not. Nevertheless, it is still hard to control the urge to wait just a few days more before launching.

Assuming you are still in the phase of trying to validate your idea and assumptions: I think you will always get a vague, "do something in between" answer to this question because the meaning of an MVP changes drastically from idea to idea and based on the judgement of the founders, etc. At this point if possible try to avoid code that invites bugs but make other sacrifices like building a backed that doesn't scale, etc. If you have a validated idea and a growing user base, you cannot sacrifice the quality of your code anymore because that will most likely cripple your team in the future.

Just get the product out there! As long as it does what its suppose to - quality of code does not matter.

Delivering the product asap. After you know that people are willing to pay for your product, you can then write good quality code. Point is: you can always improve later. Writing good quality code in the beginning takes more time -- you should focus on making sure people want your product first.

This is dilemma... while you write a good quality code the environment changes or your competitor releases same thing in shit quality and get your users. So I thing the truth between this two statements

If you write bad code, you gonna have many bug. Bugs makes trust go away, and as startup we now needs to makes users confident you can handle the job correctly. Don't rush too fast, build less but make it good.

Ping @tdeneulin you must have an opinion on the question!

I think a lot depends on your idea. If it's absolutely unique like you've created a new type of neural network for object recognition that performs times better than any existing analogs, you shouldn't worry about bugs in your UI at the start. Users will forgive. On the other hand, if you are building a new project management tool it should look very well and complete. Also, you can make it simple, but it's better to make it right. If your code is terrible you won't be able to use it later. Or, what's worth, you can lose some user data because of a security problem and that may become the end of the story.

definitely product asap but you can balance both by prioritization through impact vs efforts in your strict product asap launch timeline

I think it is better to write a small amount of good quality code rather than just rush for the quantity. To my mind, good-looking code is a must since after you will receive market feedback and decide to change something or having to onboard a new developer - chances are that you have to fix tons of bugs or even build everything from scratch. That definitely will slow you down. But it is important to ship fast meaning not to spend too much time building features and save time by lowering the number and the complexity of the features

You don't have to write perfect code, you can write quick dirty solutions to validate as soon as possible. The caveat here is that it should be safe code.

I would lean towards faster shipping, but in certain cases high quality code/perfect product might be more appropriate (Cars, Medicines, Vaccines, Elitist products etc etc)

I think you should be working on improving product quality for the minimal version of the product. Make everything perfect for the first client. Then it makes sense to expand it.

I think startups should write the minimum amount of solid code that delivers a good experience. If the app is too buggy, users will leave

I'd say a good architecture foundation is a must. Then I'd put focus on core 20% features which is used by 80% of your audience and made code for it rock solid and well tested. Then to trade time for quality and move faster, I'd consider reducing the quality bar for the rest of less used features and get an MVP or proof of concept faster.

Agree with @johan_duus_terkelsen but the other side of the coin can be ... For me : code quality > more features Code quality should be always a priority, even if you are releasing your MVP version because scaling becomes a factor when your idea is really helpful. More and more people will start using your product if it is really solving some serious problem and saving huge time. so you won't get time to upgrade your code quality because you might become busy with programming new features for your customers. The only way to improve code quality will be a complete revamp. 😛

I think it depends on your ambition. The try fast, fail fast doctrine is good if you are testing the market (and in that case shit code is adapted). In case you do have a Product Market Fit, good code means less technical debts that can just kill you at the worst moment... What do you think?

I'd say it's also important to understand your target audience needs - if you code a B2B product got IT companies, then the quality might matter for them.

I'd say it all depends on where you are at with your journey. If you are still trying to validate your idea, see if you have a Product/Market fit or create an early prototype, then you may want to go 'quick and dirty'. Caveats on this though: the architecture should be properly done. It can bite you back nastily down the track if there is a critical architectural issue. And also, you have to keep in mind that the 'quick and dirty' will pretty much have to be thrown away and replaced by proper quality code to move forward. When in a more advanced phase, where you have your grounds and you are starting to grow and eventually scale, then I would say good quality code is absolutely paramount. Not only because as @mcflydev mentioned bugs are a total deterrent to users, but also - and probably more importantly - because if you do not do it right, you create "tech debt" for your company. As time goes that debt -like any other - can become extremely expensive and crippling.

As a developer with a lot of experience, I can say that it's a total tradeoff and the right answer is balancing. You want to wrote and process quick so you can wrote test that is very important and get also cover code. If you wrote bad code your velocity and your productive in the begining will be fast but after a while you will be slower and slower depend on your feature amount