But how do you know how much you can handle without actually doing it first?
It's the problem, and one that can't be solved by just planning the game. Planning tell you how many alternative you'll have for a situation, and how many parallel situations you'll have at a given point. But it don't tell you the amount of works you'll need unless you already had to face this situation.
That's why authors should always start by a small and basic project. Not just to help them handle the creation process, learn how to use the engine and things like that, but also to discover their how limitations. By doing this, you'll know how much image you use for an average scene, how many time you need to create them, how many time you need to effectively write the scene... and how much works you can do each day/week before really needing to make a break.
Then, once you know this, planning the game become more than a coding guide. You'll also know how many works you'll have to do at "this stage" of your game and how many time you'll need to do it.
With this, you can do a thing that the majority of the authors seem to never do : Separate the release process and the development process.
Mostly, dev works on their game until the release date, and they publish what they've done. But it's not how it should be done.
Unless it's a pure visual novel, the more you advance in your game, the more works you have to do. When the game start, there's almost no difference between the different routes, and nothing that need to effectively have a variation for this or that scene. But the more the game advance, the more each route become independent. To the you need to add the small variations for each scene, because this or that happened (or not) before. Where you had a single scene at the start of the game, you now have 10 scenes to do, and so need 10 more times to finish this step of the game.
When you publish as release the game as it is right now, the more you'll advance, the less content the player will see. Because the player don't care that there's 500 new images, what matter is that there's only 50 images in his own play. Therefore, to satisfy the players, you'll works your ass out to give them more images and you'll reach the burnout limit.
It's
not how it should be done.
When you plan your game, you should also plan your release. Release 1 stop here, release 2 stop there, and so on. And you define this limits not based on the time you need, but based on the amount of content for a route. See your game as a stairway. Each scene (or whatever you prefer as reference unit) is a step, and each release must have x steps.
At first, you'll need two weeks to reach the release point. With a "one release/month" policy, it let you two free weeks. But don't stop. Pack your game, label it "release 1", put it somewhere, and continue working on it.
Two weeks later, it's time to publish your release 1, while on the devel side, you just finished the release 2. One month later, it's time to publish the release 2, and on the devel side you just finished the release 4.
At first, you'll be amazed by the advance you have. In 2 months of works, you've take 2 month of advance. But will come a moment where this advance will decrease, because two weeks will not be enough anymore to reach a release point. And slowly the devel process and the release process will start to synchronize. But you'll always have all the time you effectively need to give a "decent" amount of content to the players, even when you'll need four more time to generate this content. Simply because the advance you took at first is here to compensate the fact that you'll need more and more time with each release.
When you'll be near to the end of your game, you'll no more have advance, but like you planed it, you'll also not have more than one month of works to reach the next release point... The players will always be happy, you'll always be happy and you'll never be under too much pressure... What asking more ?