Based on that interaction we had in the comments, I'll go with the assumption that you didn't drive your only developer away because of personal things. However, basing on that conversation, I'll make another guess that this setback is still mostly your responsibility as a hiring manager. As you mentioned you don't have AT ALL any experience with developers, but then how do you make a decision on how to hire one?
It sounds like you did your best, but you hired somebody who simply couldn't handle the scale of this project, he built shaky foundation which crumbled under him and then he simply left. Unfortunately, the difference between developers and entrepreneurs is that the former get paid hourly/salary but they can choose to come and go as they please. He got paid for the hours he worked and he left when he chose not to get paid anymore. Nothing you can do about that.
So what now? It seems like you started going down the path of replacing people with process. If only you had enough documentation, people could leave and others could pick up where they left off. IMO that doesn't work and if it does work, it'll still be way more expensive than having a reliable team of permanent employee(s). Management at various companies over the last 30 years have tried to replace people with enough documentation (including my last job) and they failed every time. That's why I decided to switch jobs and now they are stuck with their outdated and never accurate documents, while I'm having the time of my life in a new startup.
What I would do if I were you would be to try to find the right person with enough skills and experience to pick up this project and carry it to completion. This not only includes coding skills, but also design, architecture as well as basic project management. Do not try to define how he does his work, or how many documents he needs to produce. Just focus on finding the right person and be prepared to pay accordingly. When you do find him, make sure your role is to support him and remove obstacles from his way, not monitor/micromanage. I'm not implying that you did that before, but I do know a lot of managers tend to do that and that's just counter productive.
Talk to other entrepreneurs, possibly those with more software engineering background. Read these forums and come up with a set of questions to ask your prospective hire. Present the problem and ask what the approach would be. If he is the right guy (and assuming he didn't see this page), he should be able to suggest a lot of the things that other people already suggested in terms of what should be done in your company as you start recovering. Ask him to define a plan from the time he is hired to when your v1.0 will ship. How will he get you there. Ask for help interviewing such a person.
Just few of my own thoughts: Bug tracking is a must (Jira costs $10 for a team of up to 10 people). Source control is a must (git is free. perforce costs peanuts for a team of up to 5 or so people). Your code is your documentation. Not your written word documents. He should review the code and keep what is salvageable; throw out the rest and focus on writing maintainable and readable code. Save documentation for few high-level, few-page design docs. He must know the technology you are working on. Don't hire someone with just good intentions; you can't afford to have them learn on your time. Ask them what other projects they've done (unfortunately you or someone you find might have to keep up with technical aspect of things). You are looking for someone with enough experience but at the same time not too much that that spark of excitement has already burned out. Find someone who is hungry to make an impact. The methodology he proposes or follows should allow you to see work on regular (one or two weeks periods) basis and to provide instant feedback. Don't hire ANYONE who says, it'll be ready in exactly 7.4 months, I'll let you know when it's done.