Legal Tips for New Jersey Tech Developers

In a highly competitive marketplace, many tech developers would do just about anything for a long-term technology development relationship with a stable Fortune 1000 company. Decision-makers in IT departments are keenly aware that they have certain leverage in this economic climate, and that their financial resources can provide them with significant bargaining power on price as well as in structuring the legal terms that govern the development relationship. The key for tech developers in this market is to aggressively close deals while ensuring that their technology development agreements provide legal protection. With a flexible technology development agreement, tech developers can increase the number of deals closed while addressing purchaser concerns in a timely fashion. This article discusses some of the key sticking points that often arise in negotiations between purchasers and tech developers.

1. Preparing for the Deal. At the outset, tech developers should make sure that they are organized in an entity that can minimize liability exposure. Tech developers often choose corporations or limited liability companies, which can help limit liability (with exceptions!). If a tech developer is signing an agreement in a personal capacity, a client may be able to sue the developer personally if the deal goes bad. While forming limited liability entities is a relatively simple procedure in most states, developers should make sure that they “observe the formalities” of the entity that they form. These formalities include holding meetings of directors or members, adequately capitalizing the entity, observing annual meetings and bylaws (or other operating documents) and keeping the finances of the principals separate from those of the limited liability entity.

Tech developers should also make sure that they have a handle on their intellectual property assets. First, tech developers should make sure that they own all of the intellectual property that they intend to integrate into a development project or have obtained the right to sub-license it to clients. Although in many cases much of the intellectual property for a project will be created during the relationship, tech developers often reuse significant portions of code in each project.

Tech developers should ensure that they have secured their relationships with any subcontractors that may work on development projects. These subcontractors often contribute intellectual property, and clients will want to obtain these rights as well. Failure to address preexisting intellectual property issues will result in potential claims by purchasers and developers for breach of contract and infringement. Ideally, tech developers will have standard agreements at the ready for clients and subcontractors prior to entering into negotiations. These standard forms can accelerate the business deal and avoid having to work with a purchaser’s “standard agreement” or worse, with the client’s attorney (ha!).

2. Get Paid. There is nothing more important to tech developers than prompt payment for services rendered. Many purchasers will want to tie payment to vague or arbitrary standards. Tech developers should avoid these types of provisions. Payment should not be left to the purchaser’s discretion or conditioned upon the completion of vague deadlines. Instead, tech developers should insist on payment in a method that matches the type of the deal. In certain cases, payments are made in stages based on clearly defined acceptance testing procedures, with an initial payment made at the start of the project and a final payment made when final acceptance occurs. In this model, once a tech developer has delivered a piece of the project that conforms to the agreement’s specifications (see below), the tech developer should receive partial payment. This process should continue with the final payment being made after the project is fully completed. Most developers are familiar with this type of payment structure, but in many cases other payment models are more appropriate. For example, many projects are billed on a time and materials basis, and where the parties decide to use Agile or other similar development methodologies, payments can be structured to occur on a more frequent basis.

3. Limit Exposure. Tech developers should ensure that their agreement contains provisions that are designed to limit their liability exposure. This can be achieved through a combination of contractual limitations that purchasers of technology services often leave out of their standard agreements. Most purchasers, however, will accept provisions that limit liability as they are common in the industry. A typical technology development agreement should include not only a limit on the total dollar amount of liability (or a mechanism for calculating an amount, or both), but also a limitation on the specific damages that a purchaser is able to recover. In addition, tech developers may want to consider a contractual provision that requires that the client exercise its legal remedies within a certain number of years after the project is completed. This will provide extra protection to the developer and ensure that any issues are brought to light as quickly as possible so that they can be addressed in a timely fashion.

4. Be careful what you warrant. Warranties for web developers follow a simple rule: providing fewer warranties will result in less potential liability for the developer. While savvy clients will demand certain warranties, web developers can often channel and limit these warranties to ensure that they are not unnecessarily exposed to vague standards and specifications. In addition to disclaiming implied warranties, such as the warranty of merchantability and the warranty of fitness for a particular purpose, developers should also put strict limits on performance warranties. Some purchasers ask for an absolute warranty that the development deliverables will “conform to specifications” that are included in an attached exhibit. Developers should make sure that the exhibit clearly shows the hardware/software configuration that the developer will use to create the environment. The developer should limit performance warranties so that they apply only to the deliverables as they were actually delivered to the client. And, if applicable, the developer should insert provisions to nullify the warranties should the purchaser modify the deliverables (except as provided for in the agreement) or use the deliverables outside of the scope of the specifications. In addition, developers must be sure that the agreement reflects the (key) conditions and assumptions under which they are providing development services.  In deals where multiple parties are involved (in addition to the developer and the client team), these issues are even more important to document and delineate.

5. Indemnify intelligently. Most clients will want your company to indemnify them for various matters in a technology development agreement. Indemnification provisions protect parties against potential claims that may arise out during the performance of a contractual relationship. An intellectual property indemnification is one of the most requested provisions in a technology development agreement. Basically, clients want to make sure that they will be made whole if they are sued based on the deliverables they receive. For example, a client will not want to deal with a third party that later claims that the software the client is using infringes on their rights. Clients also frequently ask for indemnification for personal injury and property damage claims that are caused by the developer or its personnel. Indemnification provisions are often heavily negotiated by parties, with some purchasers seeking indemnification for a long list of potential risk exposure areas. A tech developer should consider these areas carefully, and attempt to narrow the areas of indemnification and the scope of the indemnification obligations as much as possible.  In some cases, only a narrow indemnity should be provided and in others, a developer can have a strong argument that no contractual indemnification is necessary.

6. Give rights to the client while retaining the rights that you need. Section 1 covered preexisting intellectual property, but development relationships typically result in the creation of intellectual property. Typically, the development agreement includes a provision requiring that the developer assign all of their rights in the development deliverables to the client. Often this provision is coupled with “work made for hire” provisions. Unless the developer seeks to retain ownership and license the deliverables, the foregoing provisions are normally acceptable to developers. Many developers, however, forget to retain rights to reusable code that is developed through the relationship. In many cases, clients will not have a problem licensing this code back to the developer with the right to sub-license it in future projects. However, some clients do not want any of the intellectual property used again, mainly out of a concern that a developer will sell the same system to a competitor. These issues should be distinguished from the reusable code that the developer maintains from the inception of the relationship – the preexisting intellectual property discussed in Section 1.  In addition, if any third party materials (e.g., code, modules, libraries, etc.) are going to be used, they applicable agreements should be reviewed to ensure compliance and the appropriate language added to the agreement and, in some cases, to the deliverables themselves.

7. Specify, specify, specify. In many development relationships, a development company responds to a Request for Proposals (RFP for short) and provides detailed specifications and cost estimates as part of bidding on a project. These documents are often referenced in the development agreement and intertwined with its warranty provisions (see Section 4). While a developer may be tempted to provide scant detail in a specifications exhibit, this strategy often backfires in actual practice. Clients that receive defective deliverables often turn around and point the finger at the developer, accusing the devleoper of creating a system that does meet their expectations. A better solution is for the developer and the client to clearly delineate the scope of the system with specificity. If the system is supposed to operate on a specific hardware and software platform, the specifications should clearly indicate the combination. The drafting of a detailed specifications exhibit often uncovers areas that the parties did not anticipate, and addressing such issues in the agreement can help avoid problems during the performance of the agreement.

8. Get credit. Developers often want to use a client’s corporate name and trademarks to generate more business. To be safe, negotiate for a provision in advance to secure rights to use trademarks and corporate names solely for promotional purposes and within a range of specified uses (on the developer’s website, in press releases, etc.). Clients may want to approve any promotional materials in advance and developers should be amenable to negotiating such a provision.

9. Get insurance. There are numerous risks involved in running a technology business and performing technology-related services. Fortunately, things have changed a lot since the first Internet boom. Major insurance companies write policies that can provide certain coverage against claims and losses associated with technology development, online operations, data breaches and intellectual property infringement. These are in addition to other insurance coverages that a company should maintain (e.g., general liability, workers compensation, etc.). While some types of insurance may seem expensive, insurance can be a vital tool to protect your company when things go wrong.

10. Keep records and put it in writing. After the euphoria of closing a big deal wears off, parties often dispense with formalities. In addition to securing a copy of the technology development agreement and storing it in a safe place, developers should make sure that they keep records of important client contacts. Comprehensive development agreements have detailed provisions which require that notices of defaults be sent to specific parties. These provisions should be followed and a paper trail should be maintained by a project manager. This will ensure that the developer will not lose track of important issues, and also can assist in dispute resolution should the relationship go sour.

These are just some of the important issues that New Jersey tech developers should consider when entering into contractual relationships. Developers can gain a significant competitive advantage by thinking through and addressing these issues in advance.

(c) 2013-2017 Geoffrey G. Gussis, Esq. All Rights Reserved.