Before you write the first line of code for any project, you better have a plan! Better still, you should have full documentation for the project, including requirements documents, design documents, and most importantly a contract that defines the project scope. To me, defining a project scope includes finalizing how you will be paid, how much, what you will do, what the project encompasses, and perhaps a schedule that's subject to change. How do you get there?
I usually start by understanding the project scope. Through emails and coffee shop meetings, I seek to understand what the product from the project is expected to acheive (the goals) from a non-technical perspective. Usually, it is business-minded people you will encounter first, and most are good at expressing their ideas and what they want. Take good notes because it's your job to translate all their blurb into something that makes sense technically. The results of this analysis will tell you whether (a) you have the skills and resources for the project (b) what is involved so you can adjust your price, or (c) whether the project can be successful at all. This has to last a short period because you are doing it for free.
Next you draw up a requirements document that explains what you understand and how you intend to acheive the solution/product. I use a modified IEEE-recommended software requirements specification (SRS) template, providing an overview of the project, breakdown of the project into phases, cost analysis, and a contract. Before you start the first phase, this has to be agreed to by all parties, because it locks down the scope.
As soon as the project spec is agreed to, you may now start paid work. I usually prepare by setting up my development enviroment (laptop, libraries I'll need, tools - including IDEs and analysis and test tools, test bays, and brand new notes book). The first day is spent testing a development process I'll use: I prefer end-to-end agile-like development of features including requirements analysis, design, implementation, and test/integration. You build documentation as you go along. The foundation infrastructure in place, you are ready for the first phase.
