"We'll deal with scale when we get there" is one of the most expensive sentences in software. Not because early-stage products need enterprise infrastructure on day one (they don't), but because certain architectural decisions are cheap to make early and brutally expensive to unwind later.
The decisions that are cheap now, expensive later
Database schema design is the clearest example. Adding a column later is trivial. Restructuring relationships after a few hundred thousand records already depend on the old structure is a project of its own, done under production pressure. The same is true for how services are separated: a monolith isn't wrong for an early-stage product, but a monolith with no clear internal boundaries becomes a monolith that's terrifying to touch by the time it needs to be split apart.
Scale is a business problem before it's a technical one
The right amount of scalability engineering depends entirely on what the business is actually trying to do. A tool used by 50 internal employees does not need the same architecture as a consumer app aiming for a million signups. Over-engineering for scale nobody needs yet is its own kind of waste: slower initial delivery, more complexity to maintain, for a future that may not arrive in the shape anyone predicted.
The actual skill is judgment: knowing which decisions are genuinely load-bearing for the next two years, and building those properly, while staying honestly simple everywhere else.