Staged photograph of a hand pushing a piece of paper across a wood table with the word CONTRACT in bold.

When we negotiate contracts with large corporations on behalf of computer programmers, app developers, and website developers, it’s like playing chess with someone who’s very good at the gameyou have to assume that everything you write is going to be considered carefully. You’re not going to squeeze something by a big company; it has experienced, in-house counsel just for this purpose.

Let’s assume it’s going to be an ongoing relationship and not simply one project. In that case, you want to have a master agreement that has general provisions, and a task order or Scope of Work (SOW) for each specific project. Here are the top considerations that I like to see in a contract for a provider:

  • The most important part of a contract is to require payment of the costs of enforcing the contract in the event the developer isn’t paid. This insures that if the customer reneges, it will be cheaper to pay the developer than to not pay him. (Otherwise, at the end of any lawsuit, the developer’s customer has only paid the amount it should have paid, anyway; it has nothing to lose.) We demand the costs of collection, including reasonable attorney’s fees and court costs, and often also ask the customer to pay interest in case it takes a long time to collect.
  • It’s also important to negotiate limits on termination “for cause” and termination for convenience. It can be a challenge to work out a compromise that protects both the corporate end-user and the developer.

    The hiring party often wants the freedom to terminate for any reason—or no reason—and dictate when they can stop a project. (Sometimes, corporate projects are reconsidered through the lens of new management, or new budgetary concerns.) Obviously, from the developer’s perspective, the most important thing is to get paid—and ideally, to finish the project in order to maximize payment. So, we do our best to make sure that any termination doesn’t stop the responsibility to pay for work that’s been delivered, or work that’s been completed but not yet delivered. If the developer has already committed to pay employees or contractors for the project, or has ordered parts or software, the customer who “terminates for convenience” should remain obliged to pay for those commitments.
  • Ownership of the work product is another important consideration. Normally, for custom-made applications, the hiring party owns the work product because they’re paying good money for it. An ideal situation would be when the developer continues to own any copyright or patent or whatever else is at stake, but gives a license to the hiring party to use the product. That way, if it’s a less-than-unique work that’s being developed, the service provider can license it to someone else. This also maintains the value of the service provider’s portfolio, in the event that they sell their business down the road. We also try to require that the copyright is not transferred unless and until a developer receives payment in full.
  • Defining when goods or the deliverables are deemed to be “Accepted” by the corporate customer is also important. The corporation wants to have time for multiple levels of management to be satisfied with the project; the developer wants to compete the work on schedule, get paid, and move onto the next project. We want the the work to be “Accepted” after a short but reasonable time period, beneficial use of the work, or written approval—whichever is earliest.
  • When you’re dealing with corporations that have sensitive and personal information about their customers—really, almost every business in today’s world of data—the corporation often demands indemnification by the developer for any breach of personal confidentiality.  We negotiate for parameters within the developer’s insurance coverage to limit such liability and to avoid bankrupting the developer if something goes wrong.

If a large company is willing to spend the money necessary to buy quality services, its lengthy “standard” agreement shouldn’t stop a developer from negotiating and making sure that the developer is protected. The trick is to understand and respect the corporation’s concerns; solidify the deal (and the structure for future projects) with the substantial customer; and not “bet the farm” on any one customer.

If you are a developer or other service provider, don’t go at it alone. Seek out the help of an experienced attorney to support your negotiations when you go up against the corporate contract department.

About the Author

Kaufman & Kahn kaufman@kaufmankahn.com 10 Grand Central, 155 East 44th Street, 19th Floor New York, NY 10017 Tel. (212) 293-5556 Fax. (212) 355-5009