The late movie producer Samuel Goldwyn, a Russian immigrant with a shaky command of English, was famous for his malapropisms. Perhaps his most famous, and wisest, was "An oral agreement isn't worth the paper it's printed on." What was true for the film industry of the 1930s and 1940s is equally true for the software industry of the litigation-happy 1990s. Oral agreements to develop or modify computer software are worthless at best and are usually invitations to disaster.

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.


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

Let's Phase This In
A customer'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.


No Blueprint Spells Disaster
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 of misunderstandings that can lead to customer 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 way is first to draft a "functional specification" in nontechnical language that the customer can understand. The developer may also prepare a prototype or demonstration program to show the customer how the software will look and function. Later, the developer should prepare a far more detailed and precise detailed technical specification.

Paying the Developer
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 customer. 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 customer 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 customer substantial leverage to insist on timely and successful completion of the project.


Who Owns the Software?
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 customers 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 customer, the developer will own the software's copyright -- unless the developer is considered the customer's employee or, perhaps, if it was part of a larger work and was prepared under a written work-for-hire agreement.



The Developer's Background Technology
A software developer will normally have various development tools, routines, subroutines and other programs, data, and materials that he or she brings 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."


Promises to Keep -- Warranty Provisions
We all are somewhat familiar with warranties. Whenever we buy an expensive product -- a car, television, or 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.


One of the most important warranties typically found in software development contracts is a warranty of software performance. This means 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. Other important warranties include warranties of title (that the customer 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).

Testing, What Testing? Don't You Trust Me?
Testing is one of the most important phases of the software development process. The purpose of testing is to determine whether the software does what it is supposed to do and is reliable. Particularly where safety is involved -- for example, software implemented in a "911" service or designed to run an elevator -- the software should be tested as thoroughly as possible.


  • Test the software itself, assuming it has personnel qualified to do so
  • Have the developer test the software under the customer's supervision on the customer's hardware at its place of business
  • Have the software tested by an independent testing lab

Can't We Resolve This like Gentlepeople?

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. There are a number of professional arbitrators' organizations -- notably the American Arbitration Association, which has offices in most major cities.


No one can be forced into arbitration or mediation; one must agree to it, either in the contract or later when a dispute arises. Commercial contracts today frequently include a binding arbitration provision. However, this is not a matter to be agreed to lightly. By agreeing to binding arbitration, you're basically giving up your right to go to court to enforce the contract.

Copyright Â© 2000 Inc.