Best defense is to not be there. With new clients, they pay half up front or we don't start. I've refunded part of this amount a handful of times if some part

Best defense is to not be there. With new clients, they pay half up front or we don't start. I've refunded part of this amount a handful of times if some part of the process doesn't work out for whatever reason, so I don't spend or invest the money until the project is done. It's not just that you're losing less money if the client decides not to pay. It's also that your clients are more likely to pay: a client who is willing to pay up front isn't stingy with money. These clients are better in a lot of other ways, too. I think in 5 years of doing this, I've been turned down by 2 clients because of this. I freelanced a year before I started having this policy, I was turned down by 1 client after giving an estimate. Repeat clients, I don't make them pay up front. I might reconsider that if a client was significantly late on a payment, but so far that hasn't been a problem, possibly because the up-front pay half filters out clients likely to pay significantly late. I say "significantly" because I've on occasion waited as much as 2 weeks for payments, but in those cases I believe it was due to disorganization rather than any malicious intent. EDIT: One thing that I think makes clients willing to pay half up front is that typically I try to break the project into as small of chunks as possible, with a truly minimal viable product being released up front. The first contract is for the first chunk, and the half up front is for that chunk. This results in a smaller initial payment, as a lot of my initial contracts are in the range of $4000-$8000. This also incentivizes them to agree to breaking up projects--some clients want to sign one big contract for a $250k two year project, but balk at paying half of that up front--and when the project finishes faster and for far less than they initially wanted to sign for, I gently remind them how much money I saved them. Additionally, a lot of the value I bring to the table is this sort of process improvement. I've been in contact with a few clients a few years after we worked together, and found out that they were still doing the small-releases process I brought in. I'm not going to call it agile because a lot of these companies were doing "Agile" before--that word basically doesn't mean anything any more, unless you're really clear about defining it as defined by the Agile Manifesto.