But people do build 'models' on a small scale when doing development. They're called 'prototypes'. Except in this case, they're usually to prototype the functionality, to collect feedback from the users, and not to test the 'engineering' suitability of a given library or framework for the final product. Why? Because satisfying the engineering constraints is not the hardest problem - nor the most important one - and not by a long shot. You can replace pieces of your infrastructure, or write your own, if they don't scale to your needs - but if your product isn't compelling, that's a non-starter.
The 'design phase' of most construction projects is mostly about making engineering decisions. The 'design phase' of software products is more about features, usability, and scope. While engineering plays a role, it's not the biggest one - and you can have plenty of success with bad engineering decisions. The great thing about software development is that if you're successful, you can go back and revisit your earlier decisions - and fix them if necessary.
You can build a bridge that will last a thousand years, but with software it's more important to figure out where to build the bridge TO. Or whether people would prefer a ferry.