Software Development Agreements Nashville TN

Writing agreements is difficult, boring, and often unpleasant. But, when your client claims that he or she can terminate your services on 24 hours' notice without paying you for the work you've already done, you'll be glad you negotiated and signed a written document containing a far more reasonable termination provision.

View a written development agreement as your lifeline. If properly drafted, it will prevent disputes. If problems develop, it will provide ways to solve them. If the parties end up in court, it will establish their legal duties to each other.

You don't need to have a lawyer draft a software development contract. All you need is a little common sense. All the possible nuances of software contracts cannot be covered in this article, but it does provide an overview of some of the most important points that should be covered by any software development agreement.

Work Phases

A client's worst nightmare is to pay a developer to create software and then to hear nothing until months later when the developer delivers a product that is unsatisfactory. The best way to avoid this scenario is to break down the project into discrete parts or stages, often called phases or "milestones." At the end of each stage, the developer should be required to deliver an acceptable product. Assuming this is done, the developer should be paid a specified amount. This makes it easier for both sides to monitor the developer's progress and resolve problems early on in the project -- or even terminate the project.

This type of phased development also has advantages for the developer. Having the client sign off on each phase of the project is the best way to avoid unwarranted claims of nonperformance or unsatisfactory performance by the client when the project is concluded. This approach also gives the developer an opportunity to deal with the client's changing needs and wants. Few software projects ever completely follow the original specifications. The project usually grows as the work is done and the developer and user get ideas for a better and usually more complex project. Developing in phases is a convenient way to meet and discuss changes and how much they will cost. The developer must make sure, however, that the delivery schedule is reasonable and provides some flexibility.

Software Specs

Software specifications are the software equivalent of a builder's blueprint. They attempt to define the software to be created and provide a guide for determining if and when the software has been satisfactorily completed. The more complete the specifications, the less likelihood there will be misunderstandings which can lead to client dissatisfaction, withholding of payment, and possibly litigation. The specifications are really the heart of any software development contract.

There are many ways to write specifications. One way is first to draft a "functional specification" in nontechnical language that the client has some hope of understanding. The developer may also prepare a prototype or demonstration program to show the client how the software will look and function. Later, the developer should prepare a far more detailed and precise technical specification.

Payment Arrangements

There are two basic ways to pay a developer for creating custom software: a pay-per-hour (time and materials) agreement, or a fixed price agreement.

Under a time and materials agreement, the developer is paid for the time spent and actual costs incurred in creating the software. This payment scheme is obviously more favorable to the developer than to the client. Unlike in a fixed price contract, the developer is assured of payment even if the project takes longer than originally anticipated.

Under a fixed price agreement, the developer is paid a fixed sum for the entire project. In theory, this payment scheme favors the client by giving certainty as to what the project will cost. Moreover, if payments are tied to the progress of the developer's work, it gives the client substantial leverage to insist on timely and successful completion of the project.

However, as a practical matter, fixed price agreements usually do not end up favoring the client as much as one would think. If it turns out that the fixed price originally agreed upon will not provide the developer with fair compensation because the project ends up taking too long, the client will probably end up agreeing to pay the developer more money. Otherwise, the developer may quit or end up delivering a hastily completed and shoddy product.

Copyright Ownership

The moment computer code is written, it is protected by copyright. At that same moment, someone becomes the owner of the copyright. Similarly, patent and trade secret ownership rights may come into existence. Many clients of software developers harbor the misapprehension that, since they are paying for the creation of the software by the developer, they will automatically own it. However, this is not the case. Without an agreement transferring ownership from the developer to the client, the developer will own the copyright in the software -- unless the developer is considered the client's employee or, perhaps, if it was part of a larger work and was prepared as a work made for hire under a written agreement.

One of the most important functions of a software development agreement is to establish who will own the intellectual property rights to the software to be created. This is often one of the most hotly contested issues between the developer and client and can easily become a deal-breaker.

There are many ownership options available, ranging from sole ownership by the client to ownership by the developer with the client's merely having a license to use the software. And there are many alternatives between these two extremes. Depending on the amount of money the developer is paid, any of these options can be satisfactory.

Ownership of Background Technology

Software developers will normally have various development tools, routines, subroutines and other programs, data, and materials that they bring to the job and that might end up in the final product -- for example, code used for window manipulation, displaying menus, data storing, and printing. One term for these items is "background technology."

If the developer transfers ownership of the software to the client, the client may end up owning this background technology as well. Developers should avoid this by making sure the development agreement provides that the developer retains all ownership rights in this material. But, in this event, the agreement should give the client a nonexclusive license to use the background technology that the developer includes in the software.

Warranty Provisions

We all have some familiarity with warranties. Whenever we buy an expensive product -- from a car to a television to a computer -- the seller normally warrants or promises that the product will do what it is supposed to do for a specific or reasonable time period, and that the seller will fix or replace it if it does not.

Custom software developers are naturally hesitant about giving a warranty for something that is not yet in existence when the warranty is made. However, no client in its right mind would agree to pay a large sum for custom software without some assurance that the product will work. Warranty provisions are included in most custom software development contracts. However, because this is an area of active bargaining between the developer and client, they vary widely.

One of the most important warranties typically found in software development contracts is a warranty of software performance. This means the developer promises the software will work the way the developer said it would and will fix it free of charge if it doesn't. Such warranties typically last from 90 days to one year after the software is delivered. Other important warranties include warranties of title (that the client will get good title to the software) and of noninfringement (that the software will not infringe on anyone's copyright, trade secret, patent, or other intellectual property rights).

Dispute Resolution

The single most important provision in any development contract is often the procedure for resolving disputes. If a problem develops and the other side turns out to make unreasonable demands, resorting to court litigation can be ruinously expensive.

Arbitration and mediation are two means of settling disputes without going to court. In arbitration, a person or panel decides the merits of the issues and renders a decision, which may or not be binding, depending on the arbitration agreement. Many commercial contracts today include a binding arbitration provision. (Be aware that, by agreeing to binding arbitration, you're basically giving up your right to go to court to enforce the contract.) There are a number of professional arbitrators' organizations which conduct arbitrations -- notably the American Arbitration Association, which has offices in most major cities.

Mediation is less formal and even cheaper than arbitration and, by its nature, is never binding. Typically, the mediator either sits the parties down together and tries to provide an objective view of their dispute or shuttles between the two sides as a cool conduit of what may be red-hot opinions. A mediator may be able to lead the parties to a mutually satisfactory resolution that will obviate time-consuming and expensive litigation.