It's funny, as soon as you have a system that has to take into account human behavior and variety of possible inputs/states, it gets massively complicated if your goal is to try to have people not be dissatisfied with it. (and if you're trying to do it right -- or alternatively, NOT making the right decisions about that goal). People just don't behave like you think they will/should.

As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple?

No, it turns out that you have to also take into account people whose orders got delayed by the human-based shipment system, people who got coupons and they expired/want to extend the coupon, people who returned the merchandise and never got any confirmation that it was received back. Or what if someone modifies the meeting location after people accepted -- does a minor change to the meeting description trigger a re-invite or update, or not? Can meeting rooms be held by more than one person at a time? Or what if you want to tie it to the email marketing system that wasn't properly integrated or planned to be integrated -- that's another couple of engineers who have the thankless task of maintaining ETLs that constantly break whenever a change comes along.

Or in the case of Yelp, I'm sure there's small teams who are responsible for the mundane tasks of how to keep track of when a business closes, or reopens, or temporarily shut down due to virus situation -- how are the entries for those businesses supposed to be updated? We never had a field for "closed by mandatory government order" -- that's gonna take a refactor of xyz to implement, etc. etc. We have users who review things, and then those users someday die/go idle/get banned. What happens to the ranking of their reviews? It goes on and on.

(and usually, the people who take the time to think about these things in advance set themselves up for much less pain, and far fewer people needed to fix it, later)

I don't mean to be flippant or unnecessarily mean, but my anecdotal experience is that many EHR systems are pretty widely derided by healthcare providers (i.e. end-users).

Maybe it's not a good thing that only 50 engineers were working on that system.

There is a whole bunch of stuff behind the scenes that you wouldn't be exposed to as a consumer, such as analytics data pipelines, ad sales interfaces, etc that in many ways are more complicated and do more than the consumer facing thing itself.

An old EHR system from years ago does none of those things, doesn't do engineering heavy things like live updates with thousands of A/B/C/D tests running simultaneously with multiple clients for multiple operating systems and so on.

Often this comes down to how much money you're making. Any product has a long, long tail of work you could be doing to improve things. When you're a scrappy startup with few engineers you wouldn't even think of spending time on that stuff. But when you have substantial revenues, why not hire more engineers to work on it?

The problem is edge cases take a shitload of work via pareto principle. And if your company is small, edge cases can be ignored because they affect 1-2 users. When you're serving millions, those are thousands of users. You might be the only entity in that industry at that scale and have to custom build everything.