Contracting – dealing with ambiguous requirements and liability

Question

I'm talking with a client who wants me to help integrate three pieces of software that are already in development. They are new to custom software and they contracted out each piece without specifying that each of the three should talk to each other. I don't think it'll be that bad getting these to all work, but I am concerned about specifying the liability. Who will be to blame if I write method doSomethingWithBoxesAndScissors(box, scissors), and the other contractors produce code that sends ill-formed scissors in as an input? I can't rely on a pre-written spec because there is concurrent development happening with very little of it pre-specified by the client. And I am a bit concerned that one of these teams will go rogue at deliverable time, cut some corners, get their piece accepted, and leave me holding the bag.The client says that I am allowed to direct each of the teams on what they must do to achieve the integration goal, and they must accept my direction. The client is also fine with me billing hourly, so I'm not worried about getting squeezed on a flat fee. But I am a bit lost on how to define liability. The client, understandably, wants me to accept some liability. But they are looking to me for guidance on this.Had anyone else dealt with this? How did you define the liability?

authorfly · Accepted Answer

You should not accept this contract.You are being asked to accept liability for people without an incentive to deliver good work of whose reputation you don't know.The more unspecified the liability and acceptance/delivery or services description is, the more likely you are to end up with an endlessly "unhappy" client who won't make more payments but won't say it's all finished.I suggest you run. Never take liability without responsibility, especially not without any large upside possibility. In the absence of clarity, clients will try and argue that you own the liability because you directed other people for the final product. You want to specify details and work against them with a healthy 20% buffer of extra quality/work to make sure the client can never argue you didn't fufil the work. This is the opposite of that. Don't do it.

codingdave · Answer

Reject all liability. Software is almost always sold as-is. You should stand by your work, fix defects, offer help, offer advice, be a decent human, etc. But that should be done as more hourly work. If they are unhappy with how it goes, they might never hire you again, but that does not put it on you to be liable for their operations.So you are already in a good place - hourly rates, define and communicate the specs to the other devs, and reject liability. If the client says no to that, walk away.

psyklic · Answer

Larger clients will often require you to have liability insurance. I was able to get some quotes for this as an independent consultant myself. However, given the extra expenses you'll have to charge more. I'd suggest using this higher cost as leverage toward the liability they want you to accept (for you, ideally as-is). I'd also explain since it's hourly if they dislike your work they can just replace you.IANAL but my understanding is that for contractual work in the US you can only realistically be sued for at most the amount of the contract (supposing non-negligence). Asking you to accept liability beyond this sounds risky.

cvz · Answer

If you are concerned about legal stuff, ask a lawyer. Do not follow advice from random strangers on the internet.That said, the way you've described this, it sounds like a disaster waiting to happen. Either this client really doesn't know what they're doing, or they're holding a hot potato and hoping you'll take it from them before they get burned.

Joel_Mckay · Answer

1. Bill by the hour, and don't sign a contract for any deliverables
2. Middle-ware can be expensive or impossible depending on the paradigms deployed
3. People that outsource with data-mining talent are usually as unreliable as they appear
Usually trust your instincts as they often warn you somethings off... =3