I think sometimes developers just have trouble conceptualizing ‘performance tiers’ at the low to mid end.

One example is thinking that horizontal scalability of the persistence layer is necessary before you get to even perhaps Series C/D scale. For instance, I had a serious epiphany when I read that Braintree managed to vertically scale a two node (“HA”) Postgres setup to transaction volume in the millions and a massive valuation. Stack Overflow has had a similarly lean footprint for much of its history.

Most developers usually need to focus a lot more on the 20x more relevant task of product engineering. Unfortunately, a product focus usually means pretty boring or repetitive coding work that doesn’t widen your skillset as an engineer. These competing incentives are how complexity gets introduced, how more code than necessary gets written, and how poor/premature technology choices are made.

The right attitude to have in a small to medium size tech company (and particularly one that doesn’t have product-market fit) is that every LoC introduces marginal risk, every additional package is another dependency that needs to be grokked (so it better be delivering serious ROI), agility is paramount, and innovation should only be happening where it’s necessary to deliver on the company’s unique selling point.

But the most important thing is agility; and moving fast (contrary to what the industry generally believes imo) is less a function of rockstar talent than of simply making the right choices, having the right processes, and persistently reexamining and refining things to go even faster. It’s just a completely different mindset from the norm at a large tech company. At a really early stage, you might even be better off hiring a prodigious hackathon talent than your average Google engineer.