INAL. Of course, that acronym is always followed by bad legal advice. So for entertainment purposes only...
I suggest that taking something away from a client is more trouble than it's worth, even if they haven't paid for it. So to use your ideas with mine, don't formally deliver the completed work until you are paid.
A few suggestions:
1. Be very clear about the fact that the software is "in acceptance testing" state until formally signed off as complete and monies have been paid. It is not "In production." Agree in writing that when you are paid that you wipe any databases involved and start from scratch. This establishes quite clearly that the client is not expecting to run their business on software that is not in production yet, they are just testing it.
2. If this is hosted software, host development code yourself until you are paid, at which point you can deploy it to their system.
3. You're using source code control. Great! Establish a formal "production" branch separate from development. Bug fixes have to be performed in both branches. This is a good practice in any event, but when you're fighting with a difficult client later, they will often complain that the software doesn't work and you have to fix issues with software that is already in production before they will pay you for work you're doing on new features. Now you can fix issues on the production code while witholding new features until they pony up the lettuce.
Even with that, I've known clients come back a while later (disclaimer - I was the grunt coder, not the boss) and insist there had been verbal agreement to put in large extra features, or that the feature they'd spent some time engaging with you to specify clearly wasn't anywhere near correct adn needed completely replacing..... In one of those cases I knew exactly where the person concerned lived. Tempation.......
A lot of clients are just fine, do what they're supposed to and pay for it. A percentage will try to scam you even with an agreement if they sense an opportunity - even with what you thought was a detailed bill of work - because they realise you need them more than vice versa, they've screwed up and need the extra to cover themselves, or because they're just plain crooks. Shouldn't happen but it does; deal with it and move on.
0.a. Get a legally binding signature and include a written-only clause. Make it crystal clear that if something doesn't appear in that definition of services that everybody signed and that has a price tag on it, that it isn't covered by that price tag.
I've translated roughly 3.2 million contracts for services since switching from programming to translation, and I'm pretty sure I could survive as a programmer now, just from that alone.
Getting screwed works both ways. I know I'd uncomfortable paying the final invoice before receiving the final source code deployed and working. What's stopping the developer from never quite getting around sort out the final deployment after I've handed over all my money. I know people who've experienced more or less just that.
Perhaps there is a market for some sort of third party source code escrow service, for software contractors.
Excellent question. As a developer, I suggest asking for everything. But some clients have asked this exact same question, and two things that have worked for me have been:
1. Agree on a %-age of the money as a 'hold back.' The client pays within a set period, e.g. 30 days, if there have been no problems or when all problems are resolved. I wouldn't agree to more than 10% hold-back, personally, but it isn't a big issue.
2. Agree that for each deliverable, there is a milestone for "accepted" where the client tests it on your development or acceptance system, and another for "deployed." There is a payment for each milestone. There could be other milestones leading up to "acceptance," of course, and there would be payments for each of these.
I suggest that taking something away from a client is more trouble than it's worth, even if they haven't paid for it. So to use your ideas with mine, don't formally deliver the completed work until you are paid.
A few suggestions:
1. Be very clear about the fact that the software is "in acceptance testing" state until formally signed off as complete and monies have been paid. It is not "In production." Agree in writing that when you are paid that you wipe any databases involved and start from scratch. This establishes quite clearly that the client is not expecting to run their business on software that is not in production yet, they are just testing it.
2. If this is hosted software, host development code yourself until you are paid, at which point you can deploy it to their system.
3. You're using source code control. Great! Establish a formal "production" branch separate from development. Bug fixes have to be performed in both branches. This is a good practice in any event, but when you're fighting with a difficult client later, they will often complain that the software doesn't work and you have to fix issues with software that is already in production before they will pay you for work you're doing on new features. Now you can fix issues on the production code while witholding new features until they pony up the lettuce.
JM2C. Did I mention that INAL?