I think there are bits of false dichotomy in here. Writing optimised code from the get go and thinking about it at a later stage are not your only two options.

I think there are bits of false dichotomy in here. Writing optimised code from the get go and thinking about it at a later stage are not your only two options. You can always think about performance implications of your implementation and keep them in mind. This is typically the runtime, your infrastructure, your chosen level of abstraction etc. You know your implementation is not the fastest, but you know what your limits are and where the low hanging fruit is. To make it more specific - I implemented some economic model thingy and all I wanted was for it to compile and run correctly, so I wrote it in a way that I could swap the data storage for concurrency-safe structures without impacting the results - but since that added tons of complexity, I just designed it with a pluggable storage in mind. Then I developed it as a single-threaded program and wrote tons of tests. Once that and the external API were done and validated, I plugged in the concurrent storage layer and enjoyed great speedups. So no, my first prototype was not performant at all and I was okay with that.