"During this time there were also plenty of negative experiences. GitLab suffered from terrible performance, frequent outages (almost every week some), poor management, and many other problems that startups face. This lead to "GitLab is slow" being the number one complaint voice by users. Especially on Hacker News people just loved to complain about it, no matter what the original topic (e.g. some new feature announcement) might've been. Of course GitLab was aware of this, and in fact one of the reasons GitLab hired me was to resolve these problems...During this time, GitLab started to realize you can't solve these sort of problems by just hiring one person, especially if performance isn't a priority for the rest of the company...At the same time, writing performant code (or code that at least isn't horribly slow) wasn't at all considered a priority for the rest of the company. GitLab also had a tendency to listen more to complaints on Hacker News than internal complaints. This lead to an internal running joke that it if you wanted something to change, you'd have better luck complaining about it anonymously on Hacker News instead of bringing it up through the proper channels...After the first rocky 1.5 years, things started to improve. Performance had improved greatly, and GitLab was starting to take it more seriously."

Hooray for Hacker News, then, if performance was one of its biggest problems for users and yet the 'proper internal channels' were ignoring it in favor of other priorities which didn't matter as much to, y'know, the users.

Interesting perspective.

As someone who’s used GitLab, it always felt like he says - too much focus on random features that weren’t that interesting, while core functionalities that needed a bit of refinement got left in the dust.

> I (..) removed GitLab's production database by accident.

Oh, I remember this. I vaguely remember there was also a live stream video of the recovery from GitLab's offices. That must not have been even more stressful at all!