Drafting a software contract is like designing a car. Writing the contract’s different specifications is like picking out the panels, seats, doors and lights for a new vehicle. Similarly, the hiring party sits down with the developer to go over what specific elements and functions they want in their app. There are going to be some components that both parties will agree on as feasible objectives, and others that the developer and hiring party will struggle with and come to a compromise. Understanding the definitions of common terms in these software contracts can help both parties craft a contract that they’re both happy with.
1. Work for Hire – Intellectual Property
When developing a contract, it’s always important to cover your bases, no matter how rudimentary the issues at hand might be. The ‘Work for Hire’ portion of the contract addresses who owns the Intellectual Property that the developer produces. Here is where some disagreement can happen. The developer usually holds the rights to the software they develop for the client. It is common for the first time hiring parties to want to keep 100 percent of the software rights to prevent the design from being adopted by competitors. However, the developer’s design is usually based on a template they built for other clients. Skilled developers usually spend months or years building software from the ground up, and it would be impossible for them to create fresh infrastructure for each new client. That is why the developer wants to keep the ownership of the code and to give the hiring party a perpetual, unrestricted right to use it.
I counsel my clients to have the developer agree not to use the code for a competitor, but, they can use it for another industry. The way that is accomplished legally is that developer can be considered the owner of the software and the hiring party is given a perpetual, unrestricted license to use it. The other way is to do the opposite, the hiring party owns the code and grants a perpetual license to the developer. I prefer for my client to be the owner; however, it is not a reason to refuse to hire a good developer.
1. Scope of Work (SOW)
This term encompasses the project’s mission and is the most important part of the agreement. It should address the time frame, tasks, deliverables, assigned roles, quality of work, and fees to the more complex and debatable issues such as minimum viable products (MVP), benchmarks, and milestones. The Scope of Work also determines the specifications of a project including the coding language used and the precise technical functions of the software.
The Scope of Work section is typically broken down into three stages:
Stage One: Minimally Viable Prototype (MVP)
MVPs are the beta versions of the software elements. They are components that have been tested by the developer but are still not sufficiently viable to be used by the public. Once the hiring party receives the MVP, they can evaluate and test it to make sure it meets their expectations and decide if its features are appropriate for their customers.
Stage Two: When the app is fully developed for commercial use
The MVP often will not tie into a backend database, and some of the peripheral functions will not be coded in the MVP. Inevitably there will be changes and the issue becomes, is it in the original SOW or does it constitute a Change Order? Change Orders are billed separately according to the terms of the agreement. Reasonable minds can differ on some of these changes, and it is the area that causes the most problems as the project develops. I counsel my clients to build into the SOW that some significant changes will probably be needed at this stage and to set some reasonable parameters that protect both sides against surprises.
Both parties must cooperate here for the project to be successful. The complaints you hear most often from developers is that the hiring party makes too many requests for changes that can make the project never end. I counsel my clients to think through carefully any significant change and be cautious about asking for changes that are of minor importance. Inevitably there will be a need for a significant change, and the developer will be more cooperative if you haven’t requested a lot of insignificant changes along the way.
Stage Three: Maintaining the Software
This falls into two categories. First, is when the product is launched commercially and is used a lot, bugs will be discovered. That should be covered in the SOW of the primary project. After the bugs are worked out, then the software will need to be maintained. Often, the maintenance component is addressed in a separate agreement, however, generally you want the developer to do the maintenance because it is hard for one developer to fix another developer’s code.
As with most contracts, it pays to do a lot of planning up front to reduce the number of problems you will have in the future. Then, as problems arise, you will have a framework to deal with them.