Ask HN: How bad should the code be in a startup?
Heyo,<p>I&#x27;ve worked in very small and very large companies, though never owned a startup myself.<p>A few things I have seen and experienced, personally or from close friends:<p>* It&#x27;s ok to not be scalable from day 1 as long as you&#x27;re not certain who your customer is. Because you are likely to have to shift a lot left right and center and it might slow you down. But do keep in mind that it will become an objective at some point.<p>* Your code should be reliable and high quality enough that you can refactor it fast and without headaches. I have lived situations where a change in one part of the application was creating bugs somewhere completely different. I&#x27;ve also been in places where tests were forbidden (bugs never come twice at the same spot , RIGHT?!). Not having tests with f<i></i>* you hard because you wont be able to move without breaking stuff soon, but also because you won&#x27;t be able to easily expand your team.<p>* Tangential to 1 and 2, do try to keep abstractions layers in place. That will make your life easier.<p>* You shouldn&#x27;t be afraid to let new employees in the code, and to deploy. Otherwise you&#x27;re a liability.<p>* Security is a tough one. It&#x27;ll never be good enough, and it&#x27;s usually a cost more than a revenue... Make sure that all the data of your customer is safe though, that should be the hard limit. Because if you&#x27;re successful and get hacked you might never recover from it.<p>I have seen a brilliant company that had a nice business model go down not because the code was not high quality, but because lack of tests and lack of design abstractions made every step of the way 100 times harder a few years down the line.<p>You seem to have a pretty good idea where you&#x27;re going already :).<p>All in all you wanna move as fast as possible, while making sure that you&#x27;re not creating the shit of tomorrow. So if you write crap because reason, make sure it&#x27;s contained :).