Software Development Agreements -- Just Hold Your Nose and Write One
Oral agreements to develop software are worthless. When you make a deal, write it down, and include these important terms.
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.
Page 1 of 5
Next Page
Copyright 2007 Nolo
