There's also the situation where you've passed your scalability limits, you have users, the system is falling down and the business has blinders on and simply won't accept that they need to invest in a better way.
Being overly speculative and ambitious early on is a great way to fail. Building on top of something past its limits and ignoring the (developer, customer, velocity) pain is yet another.
One great way to guard against this is to force teams to design for scaling up and down. I regularly give a "plan for success, and plan for failure" speech that covers this area.
If your service opex breaks even at 1k users because you designed for capacity up to 100k users, and you actually end up with 100 dedicated super-sticky users, you'll resent the users you have as they bleed you to death.
If, instead, you build a system that less efficiently, but still reasonably, scales to 100k users by ramping up cost to support 100k users by 4-8x... but has an opex break even at 50 users... Congrats! you've planned for success and planned for failure.
Go get those 100k customers, then optimize. But don't wait to optimize an unscalable system until you already have customers. That's a recipe for lost customer trust and "ahead of their time" epitaphs.
Being overly speculative and ambitious early on is a great way to fail. Building on top of something past its limits and ignoring the (developer, customer, velocity) pain is yet another.