No, please do obsses over this while designing. The amount of times I have to say "you can't fix these performance issues without rewriting majority of your software" is too damn high.

I mean, I make a lot of money as performance specialist, but it's still a dumb waste when you see failing products and companies because their rockstar developers refused to spend 30 minutes thinking about how well their architecture and code performs. You can't fix everything later.

But most organisational failures are not down to performance - they're down to market fit.

You don't have performance issues if you don't have a product that people want. :)

I disagree (and have - sadly nonpublic - numbers to prove it).

Also, it costs you VERY little to spend some brainpower to design your product to perform well. I honestly really don't understand why so many developers behave like it's physically painful to think for a bit before starting to bash out code.

Noone expects you to write microoptimizations, but applying basic knowledge learned in CS classes and knowledge you can read in blogs should not be physically painful. And you can do that outright at the start, at __NO__ cost to your development velocity.

Agree there's a basic level, and as you say just spend a little time on it but that's table stakes.

My reading of "obsess over it" _is_ micro-optimisations which are a distraction if you've got no market fit

Obsessing about it when doing design/architecture but not caring so much in terms of raw implementation seems like a good idea?

Then if you detect inefficiency you can optimize the code and not the architecture.

I am building something with this mindset now, hopefully it will work

I think you're reading something I didn't write.

Nothing to do with architecture - rather ensuring you understand what decisions you're making, what other options you might have and why you're choosing not to do something (eg opportunity costs wrt delivery v time optimising)