Predicting position and velocity of little plastic balls tumbling inside some rotating container is a very different problem to predicting the behaviour of future API consumers. Specially if those consumers work in the same company you do and have shared objectives.

So no, he's not better using that "crystal ball" to predict the lottery.

Many applications run maybe 10 times on real data and then their purpose is fulfilled. You don't need to design a microservice architecture with redundant servers when a simple shell script could do the job better.

You need to foresee the scale of what you're building and how you would proceed to the next level. Some things must be solved right before the first deployment because you can never change them after the application is deployed. You must know what these things are and solve them right. You must also reduce their number ideally to zero if possible. You must use solutions that allow refactoring and later scaling in areas where your crystal ball is not sure. If the hard things are solved correctly you can use average workers to do the rest and it will work well.