I know a contractor generally owns the code being developed until final payment from the client. If using GitHub, does this mean the contractor should pay for a private repo on GitHub, work on the project from his/her account, then transfer ownership of the repo once final payment is received?
There are a couple reasons why I would not recommend the approach you're entertaining:
- In many cases, the client expects you to collaborate with their own employees while you are working. You may even need to work in a repo that they already control. Though it sounds like you aren't dealing with that here, since such scenarios are common, you ought to have a way of working that accommodates them.
- You will be much more successful as a consultant if you can establish relationships based on trust rather than distrust. Keeping the repo to yourself may provide you with the leverage to ensure that final payment, but it doesn't create the "warm fuzzy" that will get you future work, recommendations, etc. (See reference below.)
Instead I would suggest adopting the stance that the client owns the code from day one, and make sure they have visibility, access, and even the ability to boot you out when they want to. The idea is to make yourself easy to fire. (Again, see reference below.)
Then do other things to increase the chances of getting paid:
- Bill incrementally.
- Demo your work regularly so that if there are concerns, you catch them early.
- Charge enough so that if the client stiffs you on the last payment, you'll survive.
- If the client is smaller and you don't feel comfortable that you'll be paid, you might ask for a reasonable advance payment. (Larger clients won't typically do this, just because you shouldn't have to worry that a large client won't pay.)
Finally, related to the points above (including the "warm fuzzy" idea, the idea of making yourself easy to fire, etc.), I can't recommend this article highly enough:
I mostly agree @willie. I think all those points are valid, but I also think it is reasonable to maintain some control over the work product. This should be clearly stated in the contract as well.
I did some work that was back loaded on payment and got burned. My next contract clearly spelled out payment points. 1/3 up front, 1/3 at beta demo, 1/3 on final delivery.
My contract clearly stated deliverables and what form they would take. I did not really state what technologies I would use for source control, just that I would turn over full access to the source after final acceptance and payment.
If the client is very concerned about access to the servers and access to the source code and wants to do payments backload, these should be red flags about a client that may likely stiff you.
If you are doing any work that will be available to the client (or client's employees) then you might consider not doing ANY work unless you receive a deposit as a guarantee that the client doesn't disappear with your work-product. (this happens every day)
If you're starting a four-week project, get a deposit for the first week and bill weekly. DON'T start week 2 until you've been paid for it. This minimizes the risk to you.
It is perfectly okay to explain to a client that part of your business practice includes minimizing risk to yourself. You don't have to be a jerk about it and declaring this up front gives you a platform to compromise with, according to how you're feeling that this client will perform (in terms of paying your invoices) in the long term.
Overall, just don't walk in with a blind eye. Everybody's not honest. Keep your Github repo private and if the client is asking to dig into it, make sure some money changes hands first.