What you wrote actually raises a number of red flags suggesting the only viable solution is changing your job. You wrote your manager ignores the importance and value of unit tests, I assume it's the same with the analysis and design as those misconceptions usually come in bundles. You also say that he thinks adding a temp dev for a month will bring anything else than a further delay. Apparently your manager has little idea how the software development project should be run and there are little to no chances that he's going to change his mind
Yet, you can try.
While a 9 women to deliver in a month is a popular way of "proving" that adding people doesn't necessarily expedite work it usually doesn't work on someone who is not into real understanding the problem but knows better instead. Rather than that use the example of digging a well.
Let's say you need to dig a well that is 1m in diameter and 15m deep.
One man needs 15 hours to dig it. How many men will it take to do the task in 1h?
The answer most managers (and most people in general) will give you will be that it'll be 15 men but that's not true and it's simple to show to anyone who has no idea about the
coding well digging at all. Just like in coding you can replace one digging person with another one. You can (to some level) share your work. But only one man fits in a hole 1m wide to work at all. If you add second person inside, the first one will be obstructed by them and won't be able to do their work.
You can expedite work a bit swapping an exhausted person with a fresh one so a second person will help a bit. It'll not be 1/2 of the time, a save will be probably no more than 1/3. But adding a third man most probably won't help a bit. The two will be exchanging every hour or so, having time to regain their stamina. So if you insist on using the third worker inside the hole, the only effect will be that you lose more time when they swap or simply more men are waiting for their turn, being paid but not bringing any extra value. No gain at best, a loss at worst.
So, you can use the third person on some auxiliary tasks, like removing the excess of dirt from the well neighbourhood. Fine, it adds maybe 5% time save for the cost of a full worker.
But how can you utilise a fourth man, not to mention another 11? If you really insist on using all of them, you'll start having additional costs like communication, time for swapping etc. So starting with the fourth man you're going to add only delays with no benefit at all and additional extensive cost of people.
And that's assuming all workers are skilled. What if digging a well requires an extra precision and you hire an untrained temp for that? You need to teach them so you'll spend the first hour on showing how to properly make well walls so that they do not fall apart and how to achieve that perfectly round shape. Then they'll be working at 50% of the trained man speed and their work will still not be perfect so the perm guy will have to do the fixes, losing some time of his work. In reality before the new person can bring anything but delays the well will be ready. And it will take longer than if the skilled worker digs alone. You can still use a temp for those auxiliary tasks or the simple ones (while I'm having a break dig in the middle, leave the walls untouched) but that's still 5, maybe 10% gain at best. And if the temp hits the wall the trained worker have to fix all that and it is no longer a gain at all.
And it's something as simple as swinging a spade. Coding is way more complex.
Summarise it with something like that:
It's obvious that you need to train a dev and 1 month is a minimum
to make them run at the basic productivity level if they are
skilled. During the training you need to invest time of one regular
dev into the training and the work of temps has to be reviewed anyway
so adding anyone to the team for less than 4-6 months is nothing but
The other idea suggested you could be involved in the hiring process. That's a good advice to reduce the time of introducing a new person into the team and limiting number of errors in their code but it'll still require training (a lead in). So a temp, even a skilled one, for one month is a waste. At best, you can use them to write auxiliary things. Like unit tests ;-)
If your manager can't comprehend such comparison, your last option is to hit the job market again.