Finding Legal Leverage As Sub-Contractor?

Arthur Rabatin writes "We are software developers in London, UK, and get most of our internet related business through advertising agencies and design agencies. The standard arrangements are that the agency is _our_ client (contractual counterpart) and they deliver our software to the client/end-user. Although we typically know and talk to the end-client [the agency's client], we have no contract with them directly." Read on for why this leads to problems, and a plea for help in clearing them up.

"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

[Anonymous Coward]

I have only a basic understanding of mysterious accounting rules, but if I understand anything, there exists a hard rule:

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 /one/ product from the intermediate guys. They can't get paid until all the product is completely shipped.
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.

[rapier99]

We have a similar setup with a PR firm here in the states. The end-client hires them to handle things like Press Releases, Marketing Brochures, Etc... the PR firm subcontracts us to do the web work.

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

[phutureboy]

Simply put, ask for a deposit, plus hook in the date of delivery to be legally binding for both parties.

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

[Tau Zero]

The proper terms are "client" (customer, ultimate owner of the work being done), "prime contractor" (your client) and "subcontractor" (you).

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

[javagurl]

Under no circumstances should you sign an agreement or begin work on a project when something as slippery as the "look and feel" of the website is still under negotiation.

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

[JediTrainer]

Simply put, ask for a deposit, plus hook in the date of delivery to be legally binding for both parties.

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.