Freelancer

L.Jenkins

Anyone else use it? Find it a little bit of a nightmare to get paid for projects done so I don't deliver them.

ChRoMe

Itzy wrote: »

I don't deliver them.

Thats probably why you are not getting paid.........

L.Jenkins

Well I've learned the painful mistake of providing the projects before and the person I've done work for has just dropped off the radar. So when I complete the project, I request a small fraction, 5 - 10% before delivery and the rest afterwards. If they fail off the radar or are not willing to pay based on their reviews, then they don't get delivery of the project.

tricky D

I haven't thought this through properly, but one possibility is to hold some stuff like scripts, css and some important images on your server. Only withhold some of the assets though as it needs to look like you've delivered the whole package. Then, when you've been paid, send an 'updated' version with the whole lot in it. If you're not paid, move the assets and their design breaks.

ChRoMe

tricky D wrote: »

I haven't thought this through properly, but one possibility is to hold some stuff like scripts, css and some important images on your server. Only withhold some of the assets though as it needs to look like you've delivered the whole package. Then, when you've been paid, send an 'updated' version with the whole lot in it. If you're not paid, move the assets and their your design breaks.

If its scripts,css and images why wouldn't they just go and download them?

tricky D

The idea is that they won't know what has happened until it's too late, as you will have moved them off the server*. Bear in mind scripts would be particularly awkward to get theirs hands on to. They could raid their cache if they're copped on - a fairly big if with most clients. *Mind you, thinking a bit further on that, you'd replace them with 1x1 images or almost empty css so that the 'bad' version gets cached. One hole in that might be someone else in their office might still have the proper assets cached.

Any other holes you can think of????

tricky D

Some other ways:

Kind of obvious, but if you've access to their hosting and still have access, delete stuff.

If they might be smart enough to get around that, create some of user account that they might not cop on to.

Before you deliver the assets, publish a version of the jpgs into a reserved, unlinked, but publically accessible, area of your own hosting making sure the jpgs have lots of copyright info in the EXIF including date stamps and perhaps at larger size if appropriate. Then deliver the jpgs with the later date stamp and a note in the copyright that they are as of yet unlicenced. The hit the host with a DMCA notice upon non payment.

ChRoMe

This is a solved problem, its called escrow.

fergalr

tricky D wrote: »

Some other ways:

Kind of obvious, but if you've access to their hosting and still have access, delete stuff.

Very bad advice. Don't go there.

That's not the way to bring things to a happy ending, is unprofessional, and is getting into tricky territory. If things went very bad, you could find yourself in legal trouble.

ChRoMe

fergalr wrote: »

Very bad advice. Don't go there.

That's not the way to bring things to a happy ending, is unprofessional, and is getting into tricky territory. If things went very bad, you could find yourself in legal trouble.

Indeed, if you tried to pull this sort of crap as a professional word would spread so fast no one would ever work with you.

L.Jenkins

Well I got stitched up one last time. I met the users requirements to the letter and delivered it. Now there whinging that they don't like it. Well fúck them. I'll be the last time I get screwed by some thieving little internet troll.

The Corinthian

Here's a few approaches:

Have a paper-trail. Have a signed contract. Have a technical spec signed-off by the client. Have any decision by the client in email - even if you are told something verbally, email them and seek confirmation. If you don't have it on paper, your options for getting your money are limited to none. This is the most important piece of advice of all.

Remain necessary. Cowboys will only stiff you if they don't need you again - it'll only be your last (or last few depending upon credit terms and delivery date) invoice that won't get paid. As such, if they need you in the future, for changes, maintenance, other projects or whatever, they'll not stiff you.

Get paid up front. How you do it is up to you; 50% on engagement, 50% on delivery, is one approach. Personally I prefer 40/40/20; on engagement, on delivery and on completion of a debug/maintenance period (typically three months) respectively.

Keep an eye on how much is owed. The above will only cover what's signed off at project initiation and as we well know feature creep will often come into play before long and this can build up quickly. Never let it get too big (the more they owe you, the more the temptation to stiff you), so keep short credit terms.

Avoid or overcharge cowboys. Ireland's small and some SME's have reputations. Even if they don't you can often tell if an SME is the type who'll stiff you when you meet the principles. In that case, either double your price and look for 50% up front (effectively getting paid in advance) or just walk away - if your instincts tell you they're cowboys, then there's a good chance they are and no matter how bad the market might be, working for free isn't going to help.

Retain ownership until paid. Any contract signed with the client should stipulate that ownership of any code, design or materials are yours until payment is completed, at which time ownership irrevocably transfers to the client, and that you are perfectly entitled to sue or take any other steps to protect your IP. So if you delete the code on their server or do something else nefarious (see below), it's within your legal rights - indeed, if they badmouth you for this, you can actually sue them for liable.

If the code is compiled, then source code is to be delivered only at this point.

If they refuse to sign such a contract, walk away; the only reason one would refuse is because stiffing the developer is an option, if not actually planned.

Harass them. Turn up on their doorstep every day. Contact their clients/partners/sponsors looking from your money (threaten to do so first though). Especially for smaller amounts (< €1,000), they'll pay rather than put up with this.

Plant a logic bomb. Not recommended in the vast majority of cases and you'll want to retain ownership of your code as cited above, however logic bombs can often focus a cowboy where it comes to payment.

How it works is you place a piece of code, deep in the solution, designed to generate a catastrophic bug in it that will surface about 90 days after your last invoice is issued. If you've not been paid, you leave it be until it manifests itself and you'll probably find your last invoice suddenly paid, with a follow up call about the bug less than a day later. 'Fixing' the 'bug' naturally is something that can be done in 10 seconds when you've been paid.

Sue the client or sell the debt. I've not a huge among of experience in this as bad debts have never been a serious issue for me and when they've occurred, such actions aren't worth the bother or cost. However, increasingly they are viable options - but only if you are above board yourself (tough if you're doing a nixer) and all the necessary documentation is in order.

tricky D

fergalr wrote: »

Very bad advice. Don't go there.

That's not the way to bring things to a happy ending, is unprofessional, and is getting into tricky territory. If things went very bad, you could find yourself in legal trouble.

ChRoMe wrote: »

Indeed, if you tried to pull this sort of crap as a professional word would spread so fast no one would ever work with you.

I agree. That part is plain unprofessional. The others fall short of ideal too.

Note, I did say I haven't thought this out. Thankfully I've never been in such a situation having successfully avoided problem payers.

ChRoMe

tricky D wrote: »

I agree. That part is plain unprofessional. The others fall short of ideal too.

Note, I did say I haven't thought this out. Thankfully I've never been in such a situation having successfully avoided problem payers.

Escrow doesn't fall short.

fergalr

The Corinthian wrote: »

Any contract signed with the client should stipulate that ownership of any code, design or materials are yours until payment is completed, at which time ownership irrevocably transfers to the client, and that you are perfectly entitled to sue or take any other steps to protect your IP. So if you delete the code on their server or do something else nefarious (see below), it's within your legal rights - indeed, if they badmouth you for this, you can actually sue them for liable.

I don't think thats true.

I don't think that the fact that someone is infringing the copyright on your code entitles you to delete the code on their server without authorisation.

That's all bad territory to get into.

The Corinthian wrote: »

Plant a logic bomb. Not recommended in the vast majority of cases and you'll want to retain ownership of your code as cited above, however logic bombs can often focus a cowboy where it comes to payment.

How it works is you place a piece of code, deep in the solution, designed to generate a catastrophic bug in it that will surface about 90 days after your last invoice is issued. If you've not been paid, you leave it be until it manifests itself and you'll probably find your last invoice suddenly paid, with a follow up call about the bug less than a day later. 'Fixing' the 'bug' naturally is something that can be done in 10 seconds when you've been paid.

'Plant a logic bomb'? Seriously?

Sounds like a good way of waiving your right to ever getting paid. And, if things go particularly badly, you get to pay someone to explain to a court why you thought it was an acceptable business practice to secretly 'plant a logic bomb' to destroy your clients server, causing their business consequential losses. Rightly or wrongly, programmers have been jailed for a lot less.


If you want to go down the road where the software disables itself if the client doesn't pay, why not explicitly set up copy protection, where it disables itself if it doesn't get the right response from a license server, and explicitly document this up front in your contract or terms of business. That seems to be the standard pattern.

Deliberately introducing subtle bugs, or logic bombs, or whatever you want to call them, is just asking for unnecessary trouble.


By all means, down tools if they aren't paying, or enforce whatever the breach provisions of the contract were, but stay away from dodgy areas, particularly if you are dealing with someone unscrupulous, they could use that as leverage against you, or cause you a lot more trouble than its worth.

And, as you say, the best approach is to just avoid cowboys that won't pay.

stevenmu

I don't do this kind of work, but if I did the two approaches I would take would be to either:

1) Let the customer test and verify everything on my own environment, and then get them to pay a substantial percentage before deploying it to their own environment.

2) Build in an activation mechanism. Let it run fine for 30/60 days without a license key, then put up a warning for another 30/60 days, then disable functionality. Basically a type of logic bomb but much more legitimate.

The Corinthian

fergalr wrote: »

I don't think that the fact that someone is infringing the copyright on your code entitles you to delete the code on their server without authorisation.

Unless the contract they sign gives you permission to do so.

'Plant a logic bomb'? Seriously?

Sounds like a good way of waiving your right to ever getting paid.

Moot point as such a routine does not activate unless you're not getting paid anyway.

Perhaps I didn't explain myself well enough. My own sole experience of this was accidental; I discovered a bug, shortly before delivery, that would make the solution close to useless and was triggered by a certain DB entry being 90 days old.

So I went to fix it (it was an easy fix) and then stopped... reality was that the client in question was a notorious cowboy and I had pretty much figured out that my final invoice would go unpaid. So I left it.

The rest played out as I suggested above. I didn't get paid, three months passed then suddenly a cheque arrived in the post and on the same day the client called about the bug. Once the cheque cleared I fixed it and everyone was happy.

As I said, it's not really an approach I would recommend, although stevenmu's suggestion of wrapping it up as a licence agreement is a good idea, but unfortunately without something like that, Irish SME's are a nightmare to deal with at the best of times and unless you want to spend hundreds of hours hoping to get some of your money through debt collection or dragging them through the courts, you will want to look at other options.

Were I to consider a logic bomb again (thankfully I'm not in a situation any more where this is even a consideration as I don't deal with many Irish clients), I'd make it a 'legal' one - using a licensing model or simelar.

And, if things go particularly badly, you get to pay someone to explain to a court why you thought it was an acceptable business practice to secretly 'plant a logic bomb' to destroy your clients server, causing their business consequential losses.

Who said anything about destroying any server?

If you want to go down the road where the software disables itself if the client doesn't pay, why not explicitly set up copy protection, where it disables itself if it doesn't get the right response from a license server, and explicitly document this up front in your contract or terms of business. That seems to be the standard pattern.

I agree, but it's still ultimately the same idea, just better executed.

By all means, down tools if they aren't paying, or enforce whatever the breach provisions of the contract were, but stay away from dodgy areas, particularly if you are dealing with someone unscrupulous, they could use that as leverage against you, or cause you a lot more trouble than its worth.

Too late to down tools, remember it's always the last invoice that's not paid.

And as for it causing you more trouble than it's worth, how? By that I mean, how can they know, let alone prove, that it is by design? I ask, not to justify such a strategy, but out of genuine curiosity.

Again, I believe that the most important thing to have is a paper trail (contracts, specs and communication), avoid the highest risk clients (not always possible though) and limiting your exposure.

fergalr

The Corinthian wrote: »

Unless the contract they sign gives you permission to do so.

I wasn't talking about the situation where you have permission in the signed contract to delete code from their server if they don't pay. Never heard of such a clause; even if there were such a clause, I'd be careful.

Its basically outside what most people would consider 'reasonable' for the contractor, who is disputing pay, to log into the server, delete all the code, and stop the business working.

You've got to think of the framing. The disputed pay issue, which seems straightforward to you, will be muddied and made complicated. Then 'After complex pay dispute, disgruntled contractor hacks into server, deleting all the code, destroying the business'. You don't want to be there.

The Corinthian wrote: »

Moot point as such a routine does not activate unless you're not getting paid anyway.

It is not a moot point.
If someone is refusing to pay, you still have a range of options - eventually solicitors letter, maybe eventually court action.
You effectively waive those options if you go down a dodgy road.

The Corinthian wrote: »

I agree, but it's still ultimately the same idea, just better executed.

A 'license protection module', which disables the system if the license isnt paid, and which is documented in the initial contract, is completely different than a 'logic bomb' which the client didn't agree to or expect.

One is documented in the contract, authorised, legit, legal, standard practice; the other isn't.

That is the difference that actually matters.

The Corinthian wrote: »

Who said anything about destroying any server?

Your 'logic bomb' stops the server working => server has been destroyed by your logic bomb.

I'd say it'd be a lot of fun explaining to a barrister how to explain to the court why that isn't the right way to think about it.

The Corinthian

fergalr wrote: »

I wasn't talking about the situation where you have permission in the signed contract to delete code from their server if they don't pay. Never heard of such a clause; even if there were such a clause, I'd be careful.

Neither have I, but I can see how it could be legally implemented - after all, if you can have a clause to 'disable' your software if its licence is unpaid, why not allow for a clause that deletes it altogether.

Its basically outside what most people would consider 'reasonable' for the contractor, who is disputing pay, to log into the server, delete all the code, and stop the business working.

If a client does not consider such measures, that only take effect upon failure to pay on signed off and delivered software, reasonable, then you don't want them as a client, TBH.

It is not a moot point.
If someone is refusing to pay, you still have a range of options - eventually solicitors letter, maybe eventually court action.

You can wipe your arse with a solicitor's letter - I've done so on a few occasions.

As for court, unless things have changed in the last five years, going to court is not a viable option unless you're owed a very healthy chunk of money.

Very often the legal option is simply not viable. Either you sell the debt, badger them or write it off.

A 'license protection module', which disables the system if the license isnt paid, and which is documented in the initial contract, is completely different than a 'logic bomb' which the client didn't agree to or expect.

From a technical standpoint it's much the same, all that changes is the legal justification (or lack thereof) - hence my saying 'better executed'.

BTW, the client still is unlikely to expect it; how often do they read the contracts, let alone specs, they sign off on?

Your 'logic bomb' stops the server working => server has been destroyed by your logic bomb.

No it doesn't. I described a bug in the business logic of the application. What's that got to do with any server?

I'd say it'd be a lot of fun explaining to a barrister how to explain to the court why that isn't the right way to think about it.

Given you don't seem to have understood what it actually is, I suspect you may have a point.

fergalr

The Corinthian wrote: »

You can wipe your arse with a solicitor's letter - I've done so on a few occasions.

Sometimes they get people to pay. That's why people send them.

The Corinthian wrote: »

As for court, unless things have changed in the last five years, going to court is not a viable option unless you're owed a very healthy chunk of money.

That would be my understanding as well.

The Corinthian wrote: »

BTW, the client still is unlikely to expect it; how often do they read the contracts, let alone specs, they sign off on?

Again, risk reduction: you warn them before hand. By e-mail or letter. Point out that the contract allows it. Manage expectations even when things are going badly. Try bring things to a happy end. Professionalism, etc.

The Corinthian wrote: »

No it doesn't. I described a bug in the business logic of the application. What's that got to do with any server?

Bug stops application working => the server is down.
Developer did it on purpose, calls it a 'logic bomb' => developer destroyed the server.

The Corinthian wrote: »

Given you don't seem to have understood what it actually is, I suspect you may have a point.

Tssk.
I understand the distinction you are trying to make. I'm a developer. Most people won't.

The Corinthian

fergalr wrote: »

Sometimes they get people to pay. That's why people send them.

If you've a mentality whereby you just stiff people if you feel you don't need them again, you're not going to be bothered by a solicitors letter. If you're in business a few years, the impact of a solicitors letter is all but neutered, TBH.

Again, risk reduction: you warn them before hand.

I didn't say it wouldn't be risk reduction, I said the client probably wouldn't bother reading it.

Bug stops application working => the server is down.
Developer did it on purpose, calls it a 'logic bomb' => developer destroyed the server.

Is the application the server now? So if a Web site is deleted from a server, for example, that means the server is destroyed?

I understand the distinction you are trying to make. I'm a developer. Most people won't.

And as I asked earlier, how will most people even know what it is?

fergalr

The Corinthian wrote: »

Is the application the server now? So if a Web site is deleted from a server, for example, that means the server is destroyed?

In my experience, even techies use the term 'server' quite broadly and casually.

The Corinthian

fergalr wrote: »

In my experience, even techies use the term 'server' quite broadly and casually.

I'm glad to say that in my experience I've not. In fact, I'd question the competency of anyone working in an IT (especially a WebDev) firm who made such a basic mistake.

Shesh... and you were the one going on about professionalism

fergalr

The Corinthian wrote: »

fergalr wrote: »

In my experience, even techies use the term 'server' quite broadly and casually.

I'm glad to say that in my experience I've not. In fact, I'd question the competency of anyone working in an IT (especially a WebDev) firm who made such a basic mistake.

Shesh... and you were the one going on about professionalism

wikipedia wrote:

The term server is used quite broadly in information technology. http://en.wikipedia.org/wiki/Server_(computing)

Our team of professional wikipedia editors is waiting for your call.

The Corinthian

fergalr wrote: »

Our team of professional wikipedia editors is waiting for your call.

You really should read the article before you post it.

ChRoMe

and.................. this thread is done!