Here are my 2¢.
If you're not passed the MVP stage yet and have no funding, it's not *necessary* to bring in a third person. However, that's assuming that you already have an actual developer working with you, which you mentioned you do. I'm also assuming that your current developer is fully committed. At that stage, you'll want to make sure that your current developer has a *get-$#!%-done* mindset to push out an MVP. That being said, bringing in another developer, at this point, isn't necessarily a bad idea. One big (if not huge) problem with that though is bringing in a developer who ends up actually slowing you down. An example is in order.
Say we have two people, Jonas and Rebecca. Jonas is the "business" guy and Rebecca is the "technical" lady. The two are building a startup that will change the world by turning acquired humans into airplanes, so that they never again have to worry about flying and travel. Just ... freaking ... awesome. Jonas and Rebecca are working hard to push out an MVP. While working on the MVP, they meet an awesome developer and decide to bring him on. One problem though, f( human ) -> new Airplane™ is not yet funded. Easy fix ... equity. Chuck is in love with the concept, so he accepts. Cool. Chuck very passionately begins to contribute. Jonas and Rebecca know a thing or two about project management, so they begin properly defining and assigning tasks to Chuck. It's March and the deadline for the MVP is in 14 weeks. For the first few weeks, Chuck is pushing out code like a shoe-less cowboy. Then something happens-Chuck has been ignoring many of his responsibilities in order to help bring this literally life-changing product to life, so of course, as life would have it, #teamresponsibilities starts trending. Chuck's commit chart goes from 20 commits a day to 12 then to 5. His phone no longer has storage space for missed calls from Jonas. The deadline is now in 6 weeks. Rebecca is freaking out because she added a couple more tasks to the project since someone else came aboard. 4 weeks left. Only 7 commits from Chuck and Rebecca is still waiting for that feet-transformation algorithm. Come on ... you know you'd never accept being that airplane with the human feet! And those stupid helicopter bullies ... let's not even talk about them. 9 days left. Chuck pushed in the feet-transformation algorithm. There's yet another problem! Ugh. Because Chuck wrote the code in a hurry, he left his precious unit tests sitting in a corner facing the wall. Had he given them another chance, he'd have caught that poor Mr. Big Toe never actually gets transformed. 2 days left. Shit ... Chuck still hasn't been able to fix that bug! Chuck isn't Tom Cruise and he has no fancy glasses ... he surrenders. They fail to meet the deadline. Everyone is angry. Investors are worried if Jonas can even successfully run a company if he failed so hard at a 14-week MVP. After trying again for 2 months, Jonas and Rebecca join Alice on a train ride to Wonderland.
Okay, I'm sorry I just made you read that. The point is, if you don't really need that third developer at the pre-MVP stage and you already have a competent developer, it may just not be worth the potential trouble.
If you're past the MVP stage and you (hopefully) have some funding (or you're successfully bootstrapped ... good for you), then I'd say "go for it", as long as you have a competent project manager and a competent engineering manager on board.
Again, this is all just my 2¢.
:) ... have a good one!