How do you guys make sure you get paid?

Ro Nagey ro at runrev.com
Mon Feb 21 13:52:22 EST 2005


All of the advice on this thread is excellent. Dan's comments, below, 
are simple and to the point. Let me add some points touched on by 
others:

0. Make the customer happy.
This is really what we all should strive to do. While he's 
contractually buying a product, I find that everyone is really buying 
happiness - or trying to.

I've seen people get contracts who aren't as skilled as others, but 
they were great at making the customer feel happy about signing with 
them.

This leads me to rule 0.5 …

0.5 Talk to the client frequently.

I know a lot of people who initially make the mistake of viewing a 
customer 'digitally' - i.e. "I've got the contract, see you when I'm 
done".

The point they quickly learn is: You're not selling just the software 
specified in the contract, you're selling yourself. The client has to 
have confidence in you as a software author and in you as a solid 
professional.

So, in bidding a job, I would always factor in the number of hours I 
would likely spend at the client's offices building and maintaining 
confidence. This would be time going over the user interface or testing 
internal workings - it was never just 'hanging' out.

If he wants to add a feature after signing the contract, great! This is 
why detailing the project and specifying what happens if the project is 
changed is so important. If it's small, I might do it for free - but I 
will also send him an amended contract specification which lists the 
cost of the change and then credit him. This is a useful reminder that 
he was liable to pay for it! ;)

7. Add a clause that specifies what interest he pays if he is late on a 
payment.

I had a friend who did design work - he charged 20% interest on late 
payments. This worked well for him.

On Feb 18, 2005, at 5:27 PM, Dan Shafer wrote:

> 1. Typically get 1/3 to 1/2 of the project fee (or estimate) on 
> signing the deal.
> 2. Tie milestone payments to deliveries where possible.
> 3. Stop work if and when payments are late or stop.
> 4. Get it in writing.
> 5. Make sure the spec is clear and that any changes have to be in 
> writing and approved by both parties. It's even better if changes also 
> incur a charge and/or include the right to adjust the agreed-upon fee.
> 6. Leave a percentage -- 10-20 usually works -- to be paid N days 
> after final delivery or on acceptance of the project, whichever occurs 
> first.
>

Ro Nagey ~ ro at runrev.com ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools




More information about the use-livecode mailing list