In Quality and DevOps circles, the concept of "Shift Left" encourages moving concerns, processes and practices as early into the software delivery lifecycle as possible. Even just saying those words probably conjures up some silly diagram of requirements followed by design followed by implementation, testing, maintenance and so on. It's not wrog
Software engineering is really just a series of risks.
A neat example of this is thinking about the load your application will have to support when designing the architecture, and having a way to test it so you haven't got to find out if you were right in production.
The chances are if you're trying to adopt this mindset in your team, you'll uncover lots of risks you hadn't thought about. You might want to add shiny new tooling that highlights security vulnerabilities and out-of-date dependencies. You might start thinking about observability up-front and decide you really need a new performance monitoring tool.
It would be easy at this point to get caught in analysis paralysis.
If you're in a start-up environment and the lifespan of the company so far isn't very meaningful, there are often other risks - product-market fit being the main one! The Lean Startup method is all about managing this kind of risk through the build-measure-learn loop and validated learning. Even if you're not in a start-up environment stick with me here.
If you shift everything left, you might end up with a high quality product that users don't care about. It'll be the best engineered system that no-one wants.
What about the other extreme? A move-fast-and-break-things attitude?