.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
Join the tribe of top tech executives
If you’re in a hurry and might not read the whole article, here are the top three areas you should pay attention in your software contract.
One of the most common causes that terminates negotiations. Check what happens if the vendor doesn’t fulfill their obligations. Check if the liability covers 1) only damages or 2) damages + benefits lost. In our experience only damages is the standard; benefits lost are hard to prove in a court of law.
The whole point of the cooperation is to produce an app, which consists of source code. Pay attention to how the rights to the source code are transferred, whether that’s upon creation or upon payment. Read more about it in the “IP ownership” section below.
Avoid very general and open clauses but also beware of very detailed (often unrealistic) waterfall scope specifications. Find a balance. Make sure to consider the process of exiting from the cooperation as well.
A lot depends on your project methodology. There are two main options here:
The common types of contracts at your disposal are:
Sellers are legally obligated to complete such contracts, with possible financial damages if they do not. So the risk of non-performance is on the sellers side.
Buyers need to precisely specify the product or services being procured. If the scope changes, the price will likely increase and the timetable will extend. Negotiating the new scope also takes time and money. Because of this, any changes in the scope of work can be dangerous to the buyer’s budget and the project timeline.
There are specialized types of fixed-price contracts that can serve you in specific situations.
Fixed Price Incentive Fee Contracts (FPIF) give some flexibility. Parties agree on performance metrics (such as fast delivery, technical performance) and if the goals are met, the seller receives additional remuneration. Such contracts still have a price ceiling; all costs above the ceiling are the responsibility of the seller, who is obligated to complete the work. It’s important to choose the performance metrics carefully to avoid paying an unnecessary premium.
Fixed Price with Economic Price Adjustment Contracts (FP-EPA) are useful for long-term relationships. They have a special provision allowing for predefined final adjustments to the contract price due to changing conditions, such as inflation changes, or cost increases/decreases for specific materials.
If you don’t define the scope properly, you either won’t get the software you envisioned or you will have to go through costly (and time-consuming) scope changes.
While the risk of non-performance or exceeding the budget is on the seller’s side, keep in mind that you will pay a premium for the vendor accepting this risk. The overall cost of the project may be higher because of this.
Fixed price contracts are often used for waterfall project management, when you make a big plan upfront and then execute it in a linear fashion, hoping there won't be major changes in the plan.
This model should be used only when:
Needless to say, not a lot of software projects will meet such conditions.
Under a cost-reimbursable contract, the buyer pays the seller for all legitimate actual costs incurred for completed work, plus a fee representing seller profit.
Cost-reimbursable contracts may also include financial incentive clauses whenever the seller exceeds, or falls below defined objectives such as costs, schedule, or technical performance targets.
The biggest risk related to this type of contract is exceeding the budget; there’s no guarantee that you will obtain the required result for the money you are ready to spend.
Cost Plus Fixed Fee Contracts (CPFF). The seller is reimbursed for all allowable costs for performing the contract work, and receives a fixed-fee payment calculated as a percentage of the initial estimated project costs. A fee is paid only for completed work and does not change due to seller performance. Fee amounts do not change unless the project scope changes. Used often when the seller performs consulting and coordination only.
Cost Plus Incentive Fee Contracts (CPIF). The seller is reimbursed for all allowable costs for performing the contract work and receives a predetermined incentive fee based upon achieving certain performance objectives as set forth in the contract.
Cost Plus Award Fee Contracts (CPAF). The seller is reimbursed for all legitimate costs, but the majority of the fee is earned only based on the satisfaction of certain broad subjective performance criteria defined and incorporated into the contract. The determination of the fee is based solely on the subjective determination of seller performance by the buyer, and is generally not subject to appeals.
Time and Material contracts resemble cost-reimbursable contracts in that they can be left open ended and may be subject to a cost increase for the buyer. The full value of the agreement is not defined.
They can also resemble fixed unit price arrangements when certain parameters are specified in the contract; the cost per hour of developer work can be preset, for example.
Although cost-reimbursable and T&M contracts carry a risk of exceeding the budget, this risk can be controlled by implementing some safety measures:
Cost-reimbursable and T&M contracts work well for agile methodology projects, when the time schedule is longer, the result is not so clear and the flow of the project is not specified upfront.
Avoid using one type of contract in each situation and adjust the contract template to your level of knowledge about the project.
If you are a start-up building an MVP, you shouldn’t go with a fixed fee contract—it’s impossible to define the exact scope of the project beforehand. It’s very likely that the scope will change, at which point you lose the benefits of fixed-price contracts.
Consider setting a budget cap, where the buyer pays for the exact number of hours of the services provided by the vendor (like in T&M contracts) but the parties also set a fixed amount that the buyer is willing to pay for the vendor’s services in total.
Implement the right to verify the quality of the services after each sprint in your contract. This helps you oversee the quality of development.
As a buyer, you can’t expect to pay after all the work has been performed. The market standard is regular payments, likely on a monthly basis, even in fixed-price contracts.
You also can’t expect to pay the vendor after a client pays you, or pay after you get the next round of financing.
Deposits and prepayments are standard, especially now when the economic situation can threaten the liquidity of many companies.
The amount of the deposit generally shouldn’t exceed the amount of 3 months’ remuneration.
It’s a good idea to have a separate agreement for the terms of the deposit, including the amount of the deposit and the events in which the vendor has the right to apply the deposit as payment.
Typically there are two options here:
Both options are legally justified but have different pros and cons. Choosing the option often depends on the purpose of the cooperation.
Be prepared that the vendor would like to make the transfer upon payment. If so, make sure that the vendor grants the buyer a temporary license to use the software until payment.
Remember that from a legal point of view, the first owner of the copyright is the programmer who created the software. This programmer transfers the copyright to the vendor under a separate agreement, and only then the vendor transfers these rights to you, the client. It might be worth asking if your vendor makes sure that the initial programmer-vendor copyright transfer takes place.
To understand the risks and benefits of using open source code as part of the product, we need to take a look at the alternatives.
There are typically three types of software deliverables:
From a legal point of view, using individually created code is safer because you get the IP rights to the fullest possible extent (you purchase the IP rights and become the owner).
But from a practical point of view, individually created code has several drawbacks:
On the other hand, open source code has its advantages:
Considering the above, it makes sense and it’s generally accepted to use open source software—but you can still mitigate the IP-related risk.
There are steps you can take to reap the benefits of open source without causing problems for yourself down the line.
First of all, check the license that comes with the project and look for:
The most popular open source license is MIT, and it’s a good fit for commercial projects. Apache works too.
Avoid copyleft licenses (such as the GNU GPL license). They allow for derivative works but require such works to carry the same license as the original work. Adding such software to your app influences the license of your entire app! It can force your app to become open source software, limiting its commercial viability.
You can also mitigate the risk by asking your vendor to take steps such as:
The end of a cooperation is usually the time when a lot of the stipulations of the contract come into play. It’s important to cover this scenario well in the contract text. To help with that, one concept that we introduced during the webinar is that of an “agile exit”.
An agile exit means an exit where you are left ready to scale the product, to include other teams in further development, to pivot or use the source code for a different solution, or to adjust deliverables to new market conditions.
You should include clauses that allow you to suspend the work or scale down the vendor’s team to be replaced by another agency or your in-house team.
To make the exit from the contract agile:
No matter how small the software, it’s always good to have it documented. Make sure that the vendor is obligated to produce and maintain the documentation; you will be grateful for it at the end of the project.
There are three types of documentation that may be generated for the IT project:
Both technical and user documentation should be transferred to you as often as the copyright to the software, and project documentation should be available for you at all times.
Lastly, your vendor will probably want to include a termination period in the contract. Keep in mind that termination periods are an industry standard, and the vendor will likely want to make terminations effective at the end of the calendar month, allowing their developers to switch to a new project in the following month without spending time on “the bench”.
2020 has had no shortage of surprises, and some are calling the pandemic a force majeure that should release contract parties from certain stipulations of their contracts.
Let’s take a look at whether this would apply for software development contracts.
Force majeure clauses commonly include acts of God such as floods, fires, earthquakes, as well as other events such as wars and government orders.
The law often doesn’t provide a legal definition of force majeure. It was courts that shaped the definition by establishing three conditions:
All three of these conditions must be satisfied to say that the event may be treated as the force majeure.
For software development services during the COVID-19 pandemic, the third condition likely won’t be met. The vendor’s programmers can still work remotely to get tasks done.
In general, you should make sure that your contracts include a force majeure clause.
Assuming your contract includes such a clause, the parties need to follow the rules set in the contract. Very often the first step is to notify the other party about the inability to perform and the cause. The party affected by the event must provide evidence that there are no alternative means of performing their obligations.
When there is no force majeure clause in the contract, a party invoking force majeure may be found as the one that is in breach of contract. General rules of law shall apply then.
To get the fullest picture of software development contract standards, make sure to watch the replay of the webinar at the top of this article. It includes additional comments as well as answers to the Q&A.
We hope this article will be helpful to you when dealing with your next software contract.
But the contract is just one part of choosing, vetting and hiring the right software agency. We have a full guide available with everything you need to know to prepare for a cooperation with an external vendor. Read it here:
Outsourcing Software Development: A Practical Guide to Getting Business Results Fast
If you’re ready to take the next step and accelerate your software projects, we can help you just like we helped Mastercard, Unity, and Volkswagen Bank. Click here to hire us.