Take a step back, breathe and relax. Set it in your mind that the company you're working for has been running with or without you. Take the burden off your shou

Take a step back, breathe and relax. Set it in your mind that the company you're working for has been running with or without you. Take the burden off your shoulders and clear your head. After getting some peace in your mind, you can take action: The first thing you have to do is to tell your client/boss, without all the computer-techy talk, the situation you're in and how it's going to actually affect them. Clients get pissed off not because things don't "work" or the user experience is "broken". Clients get pissed off because they expected them to "work" and the experience is "nice". Clients have expectations, and most of the time (for non-techie clients), they have unrealistic expectations. Set their expectation and make them understand the ramifications of having ONE guy working on such a massive undertaking under your specific circumstances. After you do this you'll find that it's much easier to breathe in and actually work. In goodwill, they will set aside time and plan things to actually help you, because they know in the end it will help them. Next steps are usual dev protocols: 1. Get it in version control with a dead simple bug/issue tracking system. 2. Always write good commit comments. 3. As for documentation, do it incrementally. Write small bits each time you work with the app, or each time you deal with your build/deployment process. It will compile into good documentation later on. If possible get your documentation into version control as well. I highly recommend that you do these things and produce a consistent flow of routines in your work before getting other people to help code with you. It doesn't help when you have another person sitting around burning precious time figuring out things as he goes along the way. On-boarding them without those 3 things listed will be hard, and it will put off a good amount of time from things that actually need attention. If you're implementing Agile on a personal level, make sure other people are on-boarded with it. You'll find that adding people will be much easier. The cost of logistics regarding adding additional team members rises higher than expected if the development workflow and environment isn't established. You'll burn time on-boarding good developers, you'll burn even more time on-boarding mediocre developers (I've personally experienced this in my previous work). Hope this helps.