Software Development Agreements -- Just Hold Your Nose and Write One
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.
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 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.
This type of phased development also has advantages for the developer. Having the customer sign off on each phase of the project is the best way to avoid unwarranted claims of nonperformance or unsatisfactory performance by the customer when the project is concluded. This approach also gives the developer an opportunity to deal with the customer'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.
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.
However, as a practical matter, fixed-price agreements usually do not end up favoring the customer 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 customer 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.
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.
