Ask HN: How bad should the code be in a startup?
Never forget that your startup customers aren&#x27;t buying your code. They&#x27;re paying for whatever the product does for them.<p>They don&#x27;t care if the code is good or bad, as long as the app does what they need it to do and does it well.<p>So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn&#x27;t work properly.<p>This can be a shock if you&#x27;ve been raised on a steady diet of HN posts and comments, Medium articles from opinionated and often highly critical programmers, and open-source projects that only accept the best quality code. No one likes to brag about writing proof-of-concept grade code, so you won&#x27;t be hearing about it online or in public.<p>a) Yes, startups have failed because their product doesn&#x27;t work properly or the product is full of bugs. However, startups don&#x27;t fail because the codebase is ugly, or convoluted, or not following best practices. You might be surprised at how hacky many early startup codebases are.<p>b) Regarding the calculation of code quality vs. feature velocity: When in doubt, consult with the senior devs and your manager. Knowing when, where, and how to strike this trade off is one of the defining features of being a senior developer, in my opinion. In most cases, it comes down to estimating the negative impacts on future development. A core component that touches every part of the app should be more carefully designed than a single-use feature only 1% of your customers might ever use.<p>c) Regarding tests and clean code for V1: In short, the only thing that matters is getting traction in the early stages. Every day you spend writing tests or refactoring code to feel cleaner reduces your chances at getting that next funding round. In the early days, it&#x27;s all about a proof of concept and getting customers so you can grow the company. You can&#x27;t grow the company if you don&#x27;t have investors and&#x2F;or customers, so that perfect code may be doing more harm than good in the early days.