We use this method all of the time. We use an escrow account with our
bank though, versus using a third-party escrow. Check with them, and
if the client is amenable, go with it. Just make sure you can get the
money out, and that you add the "escrowing" of money to the
agreement. Good luck.
Robert Dempsey
http://www.techcfl.com
That is dangerous as "happy" is such a relative term. When we are
dealing with clients that have been burned we will usually split the
payments up a bit so that we still get paid up front (or bill them
weekly), and they get comfortable seeing that we are doing actual
work, and code is being created. Iterations can help with this as they
can "see" the results of your efforts as well. Regardless, it is
difficult with these types of clients as they have lost trust, and now
we have to work to rebuild it, through no fault of our own. A few bad
apples can definitely spoil it for the rest of us. Hopefully those
people will be Darwined out of the industry. Good luck.
Robert Dempsey
http://www.techcfl.com
>
>> "you will pay only if you are happy with our work".
>
> That is dangerous as "happy" is such a relative term.
Getting a little off topic here, but I agree - cold hard experience
shows that some clients are never "happy", regardless of what you do,
and it may not even be your fault, e.g. maybe they had a previous bad
experience with software developers who didn't deliver.
I take a similar approach to Robert, small, measurable progress
milestones and payments to match - at any stage, the client can pull
the plug and walk away with what's been delivered to that point. At
each stage, the client is getting what they've paid for to date, so
there should be no need for escrow as you are limiting your risk to
the current iteration, rather than the entire project.
Another technique I've found can be valuable, especially on smaller
jobs where there is only one or two milestones, is to offer a "free
fix" warranty period, over and above any warranty you are required to
give the client by law. This gives them the comfort of knowing that
if something doesn't meet the agreed spec, they aren't going to be
left high and dry by you. It also encourages keeping track of all
requirements from the client in *writing* and helps me to remember to
dot the I's and cross the T's so that I'm not fixing my own mistakes
down the track. :-)
Finally, it encourages the client to give the software a good workout
in the first X days - generally for me, X = 90 but it depends on the
client and the job.
Cheers,
Warren