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

Test the startup and validate the product asap - if that's possible with low-quality coding then go for it! Do things that don't scale :)

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.

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.

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

A very interesting question @andrei_gal. The most important thing is to build the audience who will be the users of your quality product. Quality code is great, but if the product doesn't serve your customer audience it wouldn't matter how quality it is. Focus on your customer first, deliver the product that you think they want as early as you can. Often people will not want what you think they want, and you will have to take a pivot after launch one. PS what humans say they want, often isn't what they want in practice.

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.

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 think startups should write the minimum amount of solid code that delivers a good experience. If the app is too buggy, users will leave

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.

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?