I subscribe to the same idea that Martin Fowler talks about when it comes to diagrams and documentation - essentially only do what makes sense, and use them when they can convey ideas to your customers and team mates - which are both (at this time) YOU.
I've done the same thing - created projects on the side or at home. And the following has helped me, hopefully, take what you like - leave the rest:
1) I still subscribe to the datacentric view of building software. The data (for business apps) is still king. What is the data, and what are the relationships - build an ERD and understand your "business" (for the lack of a better term).
2) Write up a high level list of "Stories" - the things you want your application to do. you can use an individual agile approach and prioritize them and work on them in priority order. First things first, for example - you will need error logging, data plumbing, UI infrastructure, membership services (etc.) before doing your core modules.
3) Layout a good high level design. It doesn't have to be fancy, but put it down on paper and refer back to it occasionally. It can sometimes help you see the forest through the trees when you are working on a fine detail later.
3) Build your core modules. Follow good practices. I won't go into too many details here - you know what they are (e.g. unit testing, separation on concerns, etc)
4) Test it - OK...this is the hard part by yourself. Get a friend or two (my wife is a great tester - bless her heart). Buy them pizza for their time. But you need to have someone who isn't you do this - you know too many of the tricks, and your friends are good testers.
5) Make a plan for deployment or distribution. Marketing and distribution is not normally our cup of tea...so you may want to seek help with this one too.