Finding Legal Leverage As Sub-Contractor? 6
"Our problem is that more often than not, projects get delayed because the design company can't agree with [their] client on the visual aspect of the site; although the functionality is often better defined (we write detailed specs), because the project is held up, the [end] client does not pay the design agency and hence we don't get paid -- often not for months. This despite we (a) are not able to deliver only because we do not get the HTML stuff from [our] client to actually put it up or (b) we do actually finish the software but end-clients refuse to sign off because 'the site' is not finished.
How do fellow programmers in similar position handle such a situation? What would be the best way to structure a contract so that we can't be denied our (IMO) fair deal? To some extent shall we accept our client's (the design agency) 'difficulty' they have with the actual client? How do you deal with situations that you need clients [of our clients] to sign off specs but the design agency just delays things because they don't understand it and think the colour of their submit buttons is more important than the software behind it?
As we all know, even if one has every legal right to do so, one can't just sue every client ( ... that's an idea :-), but we are at a point where we are putting our own business at risk.
Please help!"
Phew! -- I hope I've corrected followed which "client" is which with my brackets above. Does anyone have good advice when it comes to this kind of multi-tiered I'm-not-responsible business dealing?
accounting rules (Score:1)
You can only cound a payment as a credit when you have fufilled all your contractual obligations; meaning when you have shipped everything.
The reason that's a little weird is that someone can purchase a service from you, and you can't count the credit when the service is sold, only when the service is used or provided. I have heard of getting around this by giving the client everything they need to use the code when you sell it.
It sounds like your code is getting binned into the design guys, so that the end-client is buying
So, it seems to me that if you can sell the license to your code to your client (the intermediate guy), then you should be able to get paid from them immediately. If not, then you're really not selling to the intermediate guys; you are using them as some kind of agent to negotiate on your behalf. You should not continue to deal through them if they keep involving a 3rd party (the design guys) and fscking up a deal on your behalf. Maybe you could insist that the end-client pay you instead of the intermediate guys, and you give the intermediate guys their fair share. You ought to be able to count that as income when you send the end-client the code, regardless of the design guys' debacle.
Contractual Structuring. (Score:1)
First up I would recommend getting a deposit at the outset of the contract. We designate this as non-refundable so even if the client changes their mind we still got something for our efforts.
Secondly, since you are actually contracting with the intermediary agency. Your due dates and payment dates should not be tied into the contract they have with the end client. This way, even if they haven't completed their obligations, or decided on the color of the submit button, you should still get paid.
Re:ask for a deposit (Score:2)
Bingo. I've dealt with enough clients who are slow to get me the materials I need, or slow to sign off on a finished site, or slow to send me a check, that I now require 50% up front. If its a really large project I'll accept 1/3 up front, 1/3 halfway through, and 1/3 on completion.
Guru.com has a lot of good advice on client management and contracts.
--
Demand to be paid by work units (Score:2)
If the front-end appearance and the back-end engines are separate issues, you can always put in your contract that you get paid when your work is complete and demonstrated to function according to spec. This means you have to have some criteria, agreed with both the prime contractor and the client/customer, which states what the software is supposed to do so that you can demonstrate that you have actually delivered something.
The acceptance tests are essential. If you can show an acceptance test result file to the prime contractor (or the client), you have good leverage for demanding payment. Don't forget to require penalties and interest charges for late payment, and make certain that the payment date is the date that you get your money; if someone mails you a check but it bounces, you haven't been paid unless and until they make good on it. Failing that, if the prime contractor gets tied up in a dispute with the client over the font and table widths, they have to pay you out of their cash on hand. This gives them a very good incentive to settle with the client.
--
Look and Feel comes FIRST (Score:2)
The pages should be designed and the client should have signed off on them before any programming work ever begins. That way you're never caught in a pickle with a complete product and a client who can't make up their mind about whether a button should be red or blue.
The best approach, in my opinion, is to divide your project into phases. Before each phase begins, the users sign an agreement that says they will pay when that phase has been completed to their satisfaction (with a conditional clause that says they have 24 hours to respond and 3 weeks from the time the product was delivered to be "satisfied" without implying satifaction or incurring additional costs.
In a nutshell, always put the agreement on paper and make sure its signed before you ever turn your computer on.
Let the games begin!
ask for a deposit (Score:2)
This way, if you don't get moving at all, then you have the deposit and you can keep it, even it the project never gets going. If the project is nearly finished, then you've got the deposit and you don't have to deliver any finished code until you receive the rest.
I guess this gets you about half-way, but I think it's a decent compromise. If you have the feeling that this sort of thing will happen, then do it.
Alternatively, get your own designers, and have them work together with you as part of one larger org. That way you have more control over the process.