Hello,

Recently I've been recieving alot of client requests requesting work to be done before payment has been set, as like I'm an untrustable programmer or something. I understand the fact that some customers have been burned in the past, but I have an established website and a reputation to protect and can't seem to get clients to trust me fully. Usually we follow a policy of accepting payments in full before work on projects under $100, and we do optional half before and half after payments on projects over $100. However, lately I have been getting clients who do not want to hear any of it. They want work 100% done before sending payment. Now, all of them agree to allow me to keep the scripts hosted server-side on my end before transfering over to them until payment has been made. However, I hate this working method, as I'm always afraid of getting burned by the client after doing hours of work.

Anyway, sorry for me rambling, but what I want the opinions of other PHP developers out there... Do you make sure you get some sort of payment/deposit before working or do you accept the work now pay later method?

Having done both pre- and post-project recently, I don't plan to ever do post-project again.

If you do this full-time, I would suggest getting a lawyer to draft a fillable contract for them to sign. Append the project specs and have them sign it before work begins. That's something you can send to a collections agency or court should they lose interest once you start working.

Yeah, I concur.

The thinking on their end in a scenario like that is usually "we'll see if I like it prior to paying for it. If it sucks, we won't pay." I've been on both ends of that.

Approach it as an IBM consultant would. Ensure that you clearly define both project scope and deliverables. Both parties should agree to what will be done. No more. No less. They're not paying you to spend your days building them a fancy try-before-you-buy.

Complete a Statement of Work. Get an authorized signature on the Statement of Work.

But - from my experience - the very super-duper-most-extra-important thing you can do on ANY deal, is to CLEARLY define success critieria. Don't leave them the wiggle room. Don't even give them to GROUNDS to back out because they don't believe you've done what they've asked of you. For example:

Application will execute at a minimum 500 signups an hour.
Application will meet all requirements in attached specification.
Application will make coffee every other hour...

As an added bonus, you're 100% clear on what you need to deliver.

Then, should they decide to pay you post project - it's a minor speed bump. You both know exactly what defines a successful project. Meet that.

On hourly projects, provide a good faith work estimate and define exactly what the risk factors are. An unacceptable risk factor, of course, is "I didn't think it would take that long." You'll wind up eating that cost. If your scope creeps or they change it once a week, you need to take the time to revise your SOW and include the new estimates, criteria, and sign-off.

As a bit of advice - make it a pain in the *** to change scope all that often, they'll think twice about pushing it on you. Infrequent changes are inevitable.

Edit.. I got burned on this pretty bad. A friend of mine hooked me up with a shop that needed some SQL server modifications. We agreed that I'd change a lot of the IPC code to do "x." Halfway through the project, I realized that there was a world of changes needed in the networking code to support the new "x."

When I approached them on it, I was told "well, that's your responsibility now." We had quoted them X hours. The problem we found required 3X hours. When they refused to pay the additional hours because we "underestimated the project", we backed out. They threatened to sue us. Us accepting 1/2 of the agreed upon payment was the only way we got out of getting sued.

We spent a good 3 hours going over the project prior to digging in. I was told that the remaining fixes are "small" and should only take a "few hours." Based on their input, we took the project.

Had I defined proper criteria, we wouldn't have had that incident.

</rant>

I've had quite a few bad experiences with post-project payments, and will never consider that as an option in the future.

Regardless of contracts signed and terms agreed upon beforehand, make sure that you're willing to persue legal action should they decide not to pay. Often times you'll be located in completely different countries which makes any legal action infinately more complicated, and often times not worth the time it would take you to recover any losses.

In general, I tend to give people the benefit of the doubt, and this has done nothing but get me into trouble with others who look to take advantage of it. I have turned down more work than I'd have liked to simply because the client refused to pay the required 50% up front.

I have adopted the attitude that if someone can't commit at least 50% of the projected cost to a project before it's started, then they apparently don't need it that badly. At least not from me.

I was surprised to find that some of the "non-pay" or "late-pay" clients were active in certain industry related communities, even as moderators. I guess it just goes to show that you really can't trust anyone and watch out for yourself at the same time, no matter how much you'd like to.

I'll admit that this attitude has cost me some work, however it has also saved me a ton of time in chasing down late and non-paying clients. To me, the reduction in stress is well worth the lost work.

However, as always, YMMV.

I would never, not ever, do work for someone that I purely know online without pre-payment of some sort. Chasing down post-payment, imo, is not worth the hassle.

Throw in the anonymity of online transactions, and then you might as well kiss your payment goodbye. How are you going to enforce a contract (if you had one signed in the first place) in a foreign country, where the contract might not hold any legal weight? How can you be sure that you are signing a contract with someone that has the legal right to be in a contract?

I also agree with Rman2003 that if someone can't commit 50% to a project, then they aren't serious about it, and neither should you be. If its a real high value project, have the money put into escrow for both your sakes.

I have only done post-payment for online work once, and it was a great success, but only because the person had quite a reputation, and I was glad to do it for the client.

well ive been doing php and mysql programming for a few months now, and i have had bad experiences with work as this one person asked for a system of an online bank this took months to make trust me, as it involved setting up a credit card payment system aswell as trying to customise paypals payment system and after 2 1/2 months when it was finished he said ok then right i'll pay you now he went offline and didnt show up again but i used this to my advantage i am now customising it for a project of my own ;)

Something you may consider (which I've actually started doing), is providing encoded scripts with a "self-destruct" method until payment is rendered. This is particularly useful if the client needs a "work in progress".

Simply encode a core file that is required, such as a function file..and include a function to unset all files related to the project upon visitation of a specific url. This has come in handy a few times.

For a small project, self-destruction, or keeping it on the author's server, works fine. For larger projects, that's still a lot of your time invested, even if they don't get the script, either.

Try to use an escrow service such as www.escrow.com.

In two years freelance, I have almost exclusively done work before payment. Only where the work is very substantial AND the client gives me a slightly bad vibe do I take progress payments (50% deposit, 30% delivery, 20% at conclusion of testing).

In that time I've only been burnt once, I just wrote it off and used what I could in other projects, no big loss.

I prefer post payment for two reasons, firstly is that it makes the customer more comfortable (and less impatient if schedules are tight), secondly, well I just don't feel right about taking payment for work not yet completed - that's just me. Also means I can delay invoicing a while if it would be beneficial (tax wise) to do so.

In all cases use your best judgement. I often turn down jobs that I just don't feel right about, if the client is unconcerned about cost, that's a warning, if the client is overly concerned about cost, that's a warning, if the client thinks they know how to program, that's a big flashing red light, if they seem picky, or completely unconcerned then you'll have problems... get to know the client and thier business before accepting a job, and do protect yourself by ensuring that the work you do can't ever be considered thiers until it's paid for - that way if they do a runner you at least have (parts of) the work available for resale (you should also at least try and disable or delete it from thier server, if you still have access).