Ask HN: How bad should the code be in a startup?
In my experience, &quot;code quality&quot; vs &quot;features&quot; is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time <i>in the short term</i>. It&#x27;s pretty simple:<p>1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-go. People avoid writing quality code because they don&#x27;t have and don&#x27;t want to build these habits, not because it&#x27;s inherently harder.<p>2. After the initial push, code quality makes it much easier to make broad changes, try new things and add quick features. This is <i>exactly</i> what you need when iterating on a product! Without it, you&#x27;ll be <i>wasting</i> time dealing with production issues and bugs.<p>The only reason people say startups don&#x27;t fail because of code quality is that code quality is never the <i>proximate</i> cause—you run out of funding because you couldn&#x27;t find product-market fit. But would you have found product-market fit if you had been able to iterate faster, try more ideas out and didn&#x27;t spend 50% of your time fighting fires? Almost definitely.<p>Pulling all-nighters dealing with production issues, spending weeks quashing bugs in a new feature and duct-taping hacks with more hacks is not heroic, it&#x27;s self-sabotaging. Writing good code makes your own life easier, even on startup timeframes. (Hell, it makes your life easier even on <i>hackathon</i> timeframes!)