Documentation:
A good requirements specification will give all stakeholders the same picture of the software to be developed and can help resolve contractual issues later. Consult references on software requirements if needed (Software Requirements by Karl Wiegers is a good source). Be sure it is accurate and kept current--you will rely on this if the client feels the software is not complete and refuses to pay.
Software:
Get a rough idea of the work to be done (or if you have a complete spec, even better) and the development language. Of the requirements listed in the spec, determine which are supported by the language and which aren't. Decide if you will need to buy third-party libraries to complete the unsupported requirements (user interface controls, etc.). You will likely want to include the price for this in the contract. You don't want to get stuck paying the bill for these unless you think you can reuse them in other projects.
Also consider development software, database software, etc. For testing on different system configurations, virtualization software with operating systems licenses will be helpful.
People:
Having extra programmers can help, but adding a programmer does not double the output, especially if they are inexperienced and require your assistance. As your team grows, it becomes more important to have well-written requirements and a thought-out design to keep everyone on the same page. I wouldn't do this unless the job is big enough for it, since you will have to spend part of your time managing the other programmers.
Someone dedicated to writing documents (user manuals, help pages, some technical specs) can be useful. If a lot of documentation is required, this might be worth considering, since it will allow you to focus on what you do best. I have never had a technical writer work with me, but I would really like to try this and see if it pays off.