Build it, release it, analyse it and only then decide if it needs optimising. I often share a similar sentiment with teams I work with: Don't throw solutions

Build it, release it, analyse it and only then decide if it needs optimising. I often share a similar sentiment with teams I work with: Don't throw solutions at undefined problems. That commonly applies to performance and premature optimization. I'll agree that there needs to be some thought as to what's being built before, and while, doing so, but spending time resolving as-of-yet-undefined problems means decision making based on high levels of uncertainty. Get something working and let problems define themselves. Often times, they do so in a way that makes them easier to fix vs. relying on the speculative solution making I mentioned above.