I completely agree. But I also think that these problems never emerge in a big-bang way. By year two, or engineering hire #30, or some other heuristic, you shou

I completely agree. But I also think that these problems never emerge in a big-bang way. By year two, or engineering hire #30, or some other heuristic, you should probably be replacing some of that stuff, refactoring other stuff, and certainly thinking about refactoring teams or hiring to fill specific functions that didn't need to exist at the start. There were so many red flags at that company, and inability to scale was just one, for sure. But these things sometimes come as a complete package. I think my problem with the article is that it thinks it's selling some generically applicable advice. But the wrong type of company with inexperienced engineers can take the wrong message from that article and totally fuck up an otherwise promising product.