It's a spectrum, not a binary question.<p>If a startup writes software so poorly that it becomes too unstable, buggy, and unmaintainable to sell to customers, it's a severe problem. Some startups can use proof-of-concept quality code to secure funding and then throw money and engineers at rewriting it. Other startups aren't so lucky and end up sinking because they can't retain customers and the engineers are spending more time chasing bugs than making progress.<p>On the other end of the spectrum, many startups have failed to get off the ground at all because they were too focused on perfecting code that never ships. Usually you don't hear about these stories in the news because they rarely make it that far, but if you spend enough time in startup communities you realize this happens all the time. It's especially common among engineer-turned-founder companies where the engineers see their own company as an opportunity to code the "right" way without the pressure of deadlines and management. Unfortunately, early stage startups have perhaps the most pressure and the most pressing deadlines of all, which isn't compatible with endless refactoring and rewrites to make everything perfect.<p>The ideal balance is somewhere in the middle. Code should be good enough to get things done quickly without burdening the future engineers with impossibly difficult tasks. It's okay to ship code with shortcuts and compromises that are documented in the comments. It's usually not okay to ship code that works 50% of the time but you wrapped it in a retry loop so it mostly succeeds eventually.<p>The key is building a team that knows where to identify code issues and how to make note of them. The team shouldn't be using the startup as an excuse to hide bad work, but they should be using the urgency as an excuse to ship "good enough" code and document (in the code comments) how they would have done it differently if they had more time. Someone can always pick it up from the comments later.
When was the last time you used an app because its code was clean? How could you even tell?<p>Nobody cares about the code because it's not what they're consuming. They care if the end result, the application itself, is high quality. If you can achieve this with dumpster fire code, so be it.<p>There is some evidence that code quality is irrelevant to delivery schedules in the short term. In the long term, your poor architecture and software design decisions may come back to bite you. But that's for future you to deal with. Your primary directive as a startup is to make something people want. Do that first, then you can deal with the side effects.