Anatomy of a Software Development Deal
Companies, large and small, regularly engage outside vendors to create software applications. According to a Gartner study, the demand for software in at least one area–mobile enterprise applications–is growing five times faster than companies’ capacity to develop the software internally. As such, reliance on outside developers seems to only be increasing.
Prior to approaching outside developers, companies should gain a firm understanding of the software they want created, regardless of whether it is a complex enterprise software program or a simple mobile application. Thorough preparation and an early understanding among the relevant stakeholders are critical. The foundation for the negotiation with outside vendors should be in place before the RFP and vetting process begins.
The size of the development deal will dictate the amount of market analysis and due diligence a company will perform in selecting a developer. Because no two pieces of software are alike, software development deals are often as much of an art as they are a science. For large software development projects, it is not uncommon to negotiate with two or more developers simultaneously.
Because no two pieces of software are alike, software development deals are often as much of an art as they are a science
Once a developer is selected, the negotiated deal points are typically reflected in an agreement, which may take the form of a master services agreement (MSA) with one or more associated statements of work (SOWs) defining the details of the particular software being developed. This article summarizes 10 deal points that should be contemplated in every software development agreement for the protection of both parties. While not intended to cover each and every aspect of software development, the discussion below summarizes key aspects that are universal in most development relationships.
Software specifications define the four corners of the program being developed. Like blueprints for a building, the specifications include the technical aspects of what is being built. Due to the unique and intangible nature of software, well-defined specifications are crucial. The specifications should include aspects such as diagrams, flowcharts, use cases, wireframes of graphical user interfaces (GUIs), and text describing the features, functionalities and parameters of the finished product. Customers will want the specifications to be set out in as much detail as possible, while developers may want to build in a degree of flexibility. If necessary, change orders can be entered into after the development has commenced in order to redefine the scope of development or the specifications.
The development process can vary considerably depending upon the complexity of the software and the development methodologies employed. Under the traditional “waterfall” development approach, the development may be divided into distinct phases or milestones. A target completion date may be provided for each milestone, at which time deliverables are provided to the customer for testing and acceptance (see below). Conversely, under “agile” development approaches, the development is more fluid and iterative. The development is broken down into a series of shorter, continuous cycles (commonly known as “iterations” or “sprints”) of two- to four-week durations. In each cycle, the design, coding and testing activities may occur generally simultaneously. Instead of rigid milestones, the agreement for agile development will focus more on user stories, project roles, planning and management meetings, visibility, and control.
Pricing and Payment
Under the waterfall development approach, a fixed-priced model is often agreed to, wherein the overall price is divided amongst the milestones. Frequently, at least a portion of the payment for each milestone is held back and its payment is contingent upon the customer’s acceptance of the deliverables associated with that milestone. Under agile development approaches, developers often seek to work on a time-and-materials (T&M) basis, while customers typically want an overall fixed price. A middle ground may be achieved in other pricing methodologies, such as a fixed price per iteration, capped T&M on an iteration basis, or a holdback for each iteration that is not paid until the entire project is complete. All in, it is not uncommon for the development of a mobile application to cost a hundred thousand dollars or more, while larger enterprise programs can cost into the millions.
Acceptance testing is performed throughout the development of the software to verify that the software meets the required specifications (see above) and to identify any bugs or performance issues. At various stages, the acceptance testing may be performed by the developer, the customer, and the end users. Under the waterfall development approach, the customer is typically provided an opportunity to test the deliverables at the completion of each milestone. The customer is often provided a specified period of time to test and accept the deliverables, or reject them if defects or bugs are identified. If defects are identified, the developer is typically given a specified period of time to make the necessary corrections. Under agile development approaches, the acceptance testing methodologies may vary. In one methodology, the project owner from the customer can continuously deliver feedback to the developer in a closed loop manner and may provide acceptance when the definition of “done” is met. Other customer stakeholders may be provided an opportunity to provide feedback during the review of the applicable iteration or sprint.
One of the most important functions of a software development agreement is to establish which party owns the intellectual property (IP) rights in the software being created. The general rule (subject to certain exceptions) is that the developer of a copyrightable work is the owner of that work, absent a written assignment to the contrary. Accordingly, when a company engages an independent contractor (nonemployee) to create software, it must make certain that ownership in the custom-developed aspects of the software is transferred to the company. In addition to custom-developed code, developers regularly include background technologies and pre-existing works in the software, such as routines, subroutines and development tools they reuse in multiple projects. Typically, the customer receives an assignment to the “custom” works and a nonexclusive, perpetual, royalty-free license to the “pre-existing” works.
Warranty provisions are included in most every software development agreement. In general, warranties are promises from the developer that the software and services will meet certain standards. Customers will want the developer to warrant that (a) the services will be provided in a workmanlike manner and in conformance with industry standards, (b) the developer has sufficient right and title to grant the assignments and licenses, (c) the software will meet the agreed-upon functional and performance specifications for a specified period of time, (d) neither the software nor its use will infringe or misappropriate the IP rights of any third party, (e) unless otherwise listed, the software is free of open source materials, and (f) the software is free of viruses and malicious technologies. Other warranties may be explicitly disclaimed. Because warranties are one way to appropriate risk amongst the customer and developer, they are often actively negotiated and can vary widely from deal to deal.
Indemnification obligations are common in all types of agreements, not just software development agreements. They are used to shift potential losses and costs, as well as obligations to defend third-party lawsuits. Indemnification clauses are often closely tied to the warranties (see above) set out in the agreement. Customers will want the developer to indemnify them from a broad scope of claims, including those relating to breaches of any warranty. At a minimum, many software development agreements include indemnification to the customer for any claims relating to the infringement or misappropriation of third-party IP rights.
Limitation of Liability
Limitation of liability clauses often place a cap on the amount of damages one party may obtain from the other, and also prohibit certain types of monetary relief (e.g., consequential or punitive damages). Like warranty and indemnification obligations, the limitation on certain types of liability is a yet another way to appropriate risk amongst the customer and developer. Therefore, these provisions are also often actively negotiated and can vary from deal to deal. In software development deals, damages and costs resulting from a party’s identification obligations and breaches of confidentially obligations are sometimes excluded or “carved out” of the limitation of liability.
Setup, Training and Hosting
Once the software is developed, either the customer or the developer will install and configure the software on the customer’s servers or the servers of the customer’s hosting service provider (e.g., Amazon Web Service, Microsoft Azure, and Rackspace). The details of this transition should be set out in the software development agreement.
In addition to software development services, developers often also provide training services. Such training services may involve the creation of user manuals, tutorials or videos, as well as providing in-person or remote training sessions. This is particularly relevant in the case of custom-developed software programs, which may not always be as intuitive as off-the-shelf software products. The customer and developer should agree on the scope and nature of the training, the dates and locations of the training, and any costs that may be associated therewith.
Software hosting could be the subject of an entirely separate post, as there are a number of aspects that should be considered. At a minimum, companies should be aware of the Service Level Agreement (SLA) they have in place with their hosting providers. The SLA defines the level of service and availability of the software (example: 99.99 percent availability or “four nines”). For software that is mission critical or collects sensitive information, companies should also consider requesting and reviewing the hosting provider’s independent audit reports (example: SSAE 16, SOC 1, SOC 2). If the developer will be providing maintenance and support services (see below), the developer will need to have access to the software wherever it is hosted.
Maintenance and Support
Due to their intimate knowledge of the inner workings of the software they’ve created, developers are usually in the best position to maintain and support the software after its delivery to the customer. Maintenance and support services include technical troubleshooting and correction of defects. Commonly, when a defect is identified, it is assigned a severity level (e.g., Severity Level 1, 2, 3 or 4) based on the impact the defect has on the software’s operation and performance. Depending upon the severity level to which the defect is assigned, the developer is usually obligated to provide an initial response within a specified period of time (example: 2 hours, 12 hours, 48 hours or 72 hours), and then provide a resolution to the defect within a different specified period of time (example: 24 hours, 48 hours, 4 days or 10 days). Maintenance and support services may also include the development of upgrades and additional features, although any substantial new development is typically handled under a new SOW.
Every development deal is different–or should be different–given that the underlying projects always address unique challenges and take place within unique contexts and circumstances. While each of the ten points above may figure more or less prominently in any particular engagement, they almost always come into play; therefore, a development checklist that takes account of these items is a good place to start in thinking strategically about working with an outside developer.