From the earliest days of requirements gathering. Not just for test planning. Good QA thinks about interaction between components in a way that developers (particularly teams of developers, where each might have their own area of focus) frequently don’t.
Every edge case that can be documented in the original requirements, every conflict in priorities identified, (“Let’s make it easy for the customer to create an account and not require profile information. Let’s personalize the site for the customer and use their name everywhere!”), every point of failure when integrating with another service covered (“so what do you want to happen when your address autocomplete service isn’t working?”) is hours and hours of worked saved down the line.
Developers thing about how to make things work. QA thinks about how to break them. You need both in project planning.