Quote:
I'm assuming there's an industry standard set of steps for managing the development process.

Hahahahaha. /me wipes away a tear. Oh, that's rich.

Quote:
A freelance or hired developer may expect to work within that process and I don't know it. Learning it would save me from reinventing the wheel.

FWIW, I'd ask the developer how they like to work. If they're really capable, they should be able to guide you through their process. The current hype is to use the Agile method -- that's where the "sprints" come from. Essentially the application is broken into small chunks of work, each of which deliver some business value on completion. Each chunk of work should take no more than, say, 3 weeks (the length of a "sprint"). Every day you can get a 5 minute synopsis of what he did yesterday, what he plans on working on today, and any roadblocks he's facing. The point of this isn't to micro-manage, it's to find out about the roadblocks and problems as early as possible, so that you can remove them (or adjust your expectations). Note that it's the developer who will tell you how much he can get done during a sprint. It's your job to prioritize features.

As someone who has done a bit of telecommuting on a software development project, all I really needed was a) access to a code repository on a server somewhere (you should control this... I'm partial to git), b) remote access to any systems/resources that I'd need to do the work (in this case, if the developer doesn't already own an Android phone, you may need to provide him with one... no need to pay for service, however), and c) some of your attention when I need clarification of specs, or other feedback. The hardest thing to get was (c).