If you are commissioning software, a written software development agreement is key to getting the product you want. Similarly, if you are being hired to design software, this written agreement is key to getting paid, preventing disputes, and resolving disputes if they develop. A well-written contract establishes the parties' respective legal duties, rights, and obligations, and can help to improve expectations and communications at the start of the relationship.
Fortunately, you do not need to hire an expensive lawyer to draft a software development contract. Whether you are the client or the developer, you can do it yourself. While this article does not cover all possible nuances of software contracts, it does provide an overview of some of the most important points that should be covered by any software development agreement.
Among the most frequent areas of dispute between clients and developers is the timeline. Thus, the schedule for work and benchmarks should be agreed upon at the outset of the relationship to avoid miscommunication and conflict later.
The agreement should clearly break the project down into discrete parts or stages, often called phases or "milestones." It should require the developer to deliver an acceptable product at the end of each stage in order to get 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 if the relationship is not working.
Advantage for software client. Getting the work in phases avoids the danger of getting an unsatisfactory product at the very end. It also gives the client the opportunity to comment on work, and keeps the project moving forward on schedule.
Advantage 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. Finally, partial payments with each milestone can ensure that the developer does not get "stiffed" in the end.
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 whether and when the software has been satisfactorily completed.
The more complete the specifications, the less likelihood of misunderstandings, which can lead to client dissatisfaction, withholding of payment, and possibly litigation. The specifications are the heart of any software development contract.
There are many ways to write specifications. One is to draft a "functional specification" in nontechnical language that the client can understand. 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.
There are two basic ways to pay a developer for creating custom software: an hourly rate (known as a "time and materials" agreement) or a lump sum (known as a "fixed-price" agreement).
Time and materials agreement. Under a time and materials agreement, the client pays the developer for the time spent and actual costs incurred in creating the software. This payment scheme is often favored by developers, since the developer is assured of payment even if the project takes longer than originally anticipated. Hourly rates are common for many professionals outside of the software industry, including lawyers and accountants.
Fixed-price agreement. Under a fixed-price agreement, the client pays the developer a fixed sum for the entire project. In theory, this payment scheme favors the client by providing 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, clients often agree to pay developers more money if the project takes more time than anticipated. Otherwise, the developer may quit or end up delivering a hastily completed and shoddy product.
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 developer and client, and can easily become a deal-breaker.
Developers own the copyright to software unless the developer is the client's employee or the software is part of a larger work made for hire under a written agreement. In order to own the copyright, the client must have an agreement transferring ownership from the developer to the client.
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.
For more on who owns a copyright, see Copyright Ownership and Rights.
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.
A warranty is a promise from the seller 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. Warranty provisions are included in most custom software development contracts. However, since this is an area of active bargaining between developer and client, these provisions vary widely.
Warranty of software performance. Warranties of software performance are typical in many contracts, in wihch the developer promises that 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. Developers should avoid making promises that their software will work indefinitely, or for multiple years, as the ongoing changes in surrounding technology can make such promises difficult to keep.
Other warranties. Others include warranties of:
Among the most important provision in any development contract is the procedure for resolving disputes. It is often advantageous to settle disputes without going to court, which can be extremely expensive and time-consuming. You can do this through a provision requiring arbitration or mediation.
Arbitration. In arbitration, a person or panel decides the merits of the issues and renders a decision, which may or may not be binding, depending on the language of the arbitration agreement. Many commercial contracts today include a binding arbitration provision. Be aware that, by agreeing to binding arbitration, you're likely giving up your right to go to court to enforce the contract.
Mediation. Mediation is less formal and 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.
For more on mediation, see the Mediation, Arbitration & Collaborative Law area of Nolo's website.
For detailed information on the laws covering software development, get Legal Guide to Web & Software Development, by Stephen Fishman.