I guess it really depends on what your company is doing, experience of the team and the language/tech you are using.
somewhat political perspective: if the org doesn't value testing or software quality, wait until there's obviously a business need to lift quality. E.g. the CTO is saying things such as "constant defects in component X are destroying most of the value of our product", users complain that the Y feature keeps getting broken in successive releases, customers refuse to renew subscriptions or upgrade to a new version until Y feature works reliably. Then propose the plan to improve QA by setting up an automated regression test suite, to allow refactor-to-test of the offending code to happen in a controlled, low risk way.
That said at my last company after 12 months we hired a few engineers so we had to transition to requiring tests for new functionality. This was just to stop regressions and make sure we could continue moving quickly.