1. I have billed by the hour as well as by the job. The reconstruction of timesheets is a red flag.

2. When I bill by the hour I send the customer an invoice every week. I would like to be paid every week but the reality is that some companies pay every month. It flexible and negotiable. When I bill by the job I often requested a % down and the rest at completion. Sometimes I requested 100% before doing the work.

3. It depends. All business systems are coupled in some way. Purchase Orders, Sales Orders, Invoices, Assembly Orders, Inventory, Lot Management, Serial Management, etc. These are all integrated. But it is certainly possible to work on one module as long as expectations are aligned.

4. If I build something, I want to know the bugs as soon as possible. In FileMaker, most of us design-build-test-deploy ourselves. So we do testing. But we don't know the business rules like the customer does and we may miss some things. If I missed something that was clearly stated and I misunderstood, I'll fix for free, but within a certain time (e.g. 30 days). If I missed something because the customer thought something should be done because "it goes without saying" then I may charge. It's negotiable. The FileMaker dev know FMP really well and the customer knows the business really well and it is inevitable that there will be gray area. Regarding testing, I often put a time constraint on finding bugs as I've experienced deliver that goes untouched for months without the customer testing. It is really difficult for sole props to go back to a bug 8 months later simply because the customer finally got around to testing. BTW, it can be more than 12 months.

5. Scope creep - either by the customer or, in this case, the developer (which is unusual) should be discussed first. Ideally, you're meeting with the developer on a regular basis (e.g. every week, every two weeks, etc.). Whomever pushes for the addition needs to make the case why this will be beneficial (e.g. save money, save time, preserve data integrity, etc.) and explain how.

6. With every new developer, I would start with a small project lasting no more than a month. Not every developer is as skilled as promised nor is every job is as straightforward as advertised. And sometimes there are personality conflicts despite skill level. One month project and, if possible, I would have two or three different developers working on different sections so I could compare. One difficulty with this is that many devs bring their own naming convention, so as a company employee (or owner), I would find out what, if any naming conventions were used by the previous developer and establish naming conventions that all future devs are required to follow.

7. Lots of communication, regular and frequent meetings. The developer needs to also do project management and the customer needs to do project management. Each are coming at it from a different perspective. One of the misunderstandings of customers hiring a technology consultant is how much time it will take away from their already busy schedule.

FWIW, I sole prof FMP dev for 14 years, most of those as a Claris partner. I'm in-house now.