Your biggest issue is going to be if they want a fixed price for the projects. Invariably projects change (usual getting more complicated) and of course unexpected issues will arise. I have seen many people get burned by using per project pricing...not necessarily because the employer were bad people (though that can happen too)...it is just because all projects are fluid and dynamic things. Not to mention, you are going to be responsible for integrating other peoples' code in the first part and directly taking over someone else's code in the second part. While this could go incredibly smoothly, I think the odds are against it.
My suggestion is push (as hard as is reasonable) for a per hour basis (or at least per day, if it's fulltime). This way if the project goes smoothly everyone wins and if not, at least you are getting paid for all the work you do. Also, having them pay by the hour/day will ensure that they will take time and effort into consideration for any changes/enhancement (and especially design decisions) down the road.
If per project pricing is the only option, try to come to an (as detailed as possible) agreement on what constitutes the completion of the project. Everyone invariably has different ideas of what "done" means. Also, if possible, get a look at the code in part 2 (before giving a project quote) to get an idea of the quality of the code you will be working with. Granted, there is limited info you can gleen from the code in a short time, but very poorly written code (and/or unreadable code with little to no comments) will generally jump right out at you. Anyway, the point is, if you have to go with per project pricing, make an informed choice and remember the age-old rule of estimating a projects labor effort: "Make your best, most educated guess....then double it." More often than not, that old axiom tends to be alot closer to reality than you could imagine.
Good luck,
Q
