Your current developers should have a source code control database (SCC) that allows any number of developers to work on the code at a time. They should also be willing to show you how to use it so that you can see the source at any time (assuming you have been paying on time). The code that is committed to the SCC should compile without problems and therefore you can hire additional developers at any time. If your current developer does not use an SCC or is reluctant to provide access, or reluctant to provide a copy of the source code, you should be concerned. Basically, if they are not willing to let you go elsewhere, then you really should go elsewhere.
"The code is not stable." If your developer doesn't use an SCC, then they might not see how it is possible to let another developer modify the code and they will claim that it must be "stable" before they hand the code over to someone else. This excuse could also mean that they are in the middle of changes that are taking a long time to finish. Developers should avoid these situations.
"It needs to be documented." Usually software doesn't need any documentation. The new software developer must figure out what the application does, and then they will have no problem figuring out how the code works. Most developers will attempt to figure out what the software does by reading the code. This is difficult to do and when the developer has problems figuring it out, they will blame the code and tell you it needs to be rewritten.
The new developer should not spend several hours reading the code to get to know it. They should follow these steps.
One of our customers came to us frustrated in the lack of progress by their current development firm. We discussed their business plans and therefore had a good understanding of what we expected to find in the software. Unfortunately for the customer the code was not usable. The previous developer did what we call "copy/paste". The developer copied existing code to each page that needed that look instead of referring to the single source for that look. This is fixable, but the database schema was incapable of handling their needs. Both of these problems meant that all the code would have to change significantly, and that meant that there was nothing to gain by using the existing code.
The customer came to us because he could tell they were not creating the functionality that he wanted. The developer did not understand the general business goals and therefore could not properly interpret the customers detailed instructions.
A serial entrepreneur, always fascinated by solving complex technical projects ranging from small to enterprise.