Indeed, the larger the scale, the more impact (including the costs of operation) a piece of software has. In a dozen^W^W OK, a thousand places where the scale i

Indeed, the larger the scale, the more impact (including the costs of operation) a piece of software has. In a dozen^W^W OK, a thousand places where the scale is large, engineers shave off a percent or two of resource usage, and this saves company money. But most places are small, and engineers optimize the time to market while remaining at an acceptable levels of resource consumption and support expenses, by using stuff like next.js, RoR, etc. And that saves the company money. There is also a spectrum in between, with associated hassles of transition as the company grows. My favorite example is that eBay rewrote their backend three times, and they did it not because they kept building the wrong thing. They kept building the right thing for their scale at the moment. Baby clothes don't fit a grown-up, but wearing baby clothes while a baby was not a mistake. Ideally, of course, you have a tool that you can keep using from the small prototype stage to the world-scale stage, and it lets you build highly correct, highly performant software quickly. Let's imagine that such a fantastical tool exists. To my mind, the problem is usually not in it but in the architecture: what's efficient at a large scale is uselessly complex at a small scale. The ability to express intricate constraints that precisely match the intricacies of your highly refined business logic may feel like an impediment while you're prototyping and haven't yet discovered what the logic should really be. In short, more precision takes more thinking, and thinking is expensive. It should be applied where it matters most, and often it's not (yet) the technical details.