[condwanaland]

The mistake here is having an architect who is not shipping product. Architects who's job it is to define 'rules' and 'patterns' without actually impending anything are almost always a bad idea. Just focus on shipping. Have at least one experienced engineer who can guide the development but don't give those decisions over to some 'architect' who is not even going to write 10 lines of code in your codebase

[LucaMo]

> We had 4 backend developers and a DevOps guy who was already stretched thin.

The mistake here was having an architect full stop. The team is too small, a good tech lead can manage to plan a service with 50k MAU (and way beyond) without an architect. The problem with some companies that get millions in seed funding is that they need to spend the money and they do so by adding roles that shouldn't exist at that stage.

[sshine]

> and a DevOps guy who was already stretched thin

Another favourite antipattern: making devops a bottleneck. Don’t over-engineer production, don’t buy abstraction you can’t afford, and educate your colleagues to lower the bus factor.

Dedicated devops that aren’t co-founders are notorious for cv optimizing: working with cool, but time-consuming stuff they don’t yet master, at the cost of delivery-time risk.

[salomonk_mur]

Having members of the tech team who don't write code in some way or another is bad practice in general

[hinkley]

I vastly prefer architecture as a responsibility shared by all the staff+ or lead devs than as a role.

But that starts to fall down too any time too many people are talking about software they aren’t responsible for deploying or fixing.