And rule 0 is: if there's nothing to measure, there's nothing to optimize. In my career, the worst "oh shit this doesn't scale" problems have been encountered

And rule 0 is: if there's nothing to measure, there's nothing to optimize. In my career, the worst "oh shit this doesn't scale" problems have been encountered in systems that were grossly over-designed - to the point that development had a noticeable "tax" due to dealing with it - and then the first time they encounter actual load (a customer writes a tight for loop on our API, or a customer decides to make 100000 of our widgets via automation, etc) it immediately shits the bed because they had no idea something would need to scale along a certain axis. And mind you, that's really no ding on the original devs. Except for 2 points: they'd been banging on about how big-brain the original architecture is, and now the unanticipated scaling axis is orthogonal to the one we had originally invested so much in scaling along and it's significantly hampered by it. It's really just best to write something simple that works and just doesn't commit any obvious sins. Then when you learn your REAL requirements, it'll be easy to adapt the code to them.