Software Development Contract Standards: How to Sign Win-Win Contracts with Vendors

Time to read
10 min
Software Development Contract Standards: How to Sign Win-Win Contracts with Vendors
No Results Found
Table of Contents
  • What are the general areas to pay attention to in software development contracts?
    • Liability
    • Intellectual property transfer
    • Clauses related to the scope and development process
  • What are the differences between a fixed-price contract and a time-and-materials contract? How can they help minimize risk?
    • Fixed-price contract terms
    • Useful types of fixed-price contracts
    • Fixed-price contract risks
    • Cost-reimbursable contract terms
    • Useful types of cost-reimbursable contracts
    • Time and Material Contracts (T&M)
    • Our main practical tips regarding contract types
  • What terms of payment should I expect? Should I be worried about deposits/prepayments?
  • When should IP ownership be transferred?
  • From a legal standpoint, what are the risks of implementing open-source libraries in my solution?
    • How to mitigate the risks of open source code
  • What is an “agile exit”? When and how can it be applied to contracts?
  • What is force majeure? When does it apply? What happens if a contract doesn’t have a force majeure clause?
  • Final thoughts

This article is based on our recent webinar with Michał Jackowski of DSK Legal and our very own Paweł Dudko; huge thanks to them for sharing their knowledge!

Watch the webinar here...

...and read the recap below:

The future is hard to predict these days. If you’re a tech leader you probably need to make big decisions fast—but in a way that still protects your business. Postponing decisions is a decision in itself—and a risky one.

This definitely applies to software development projects, where time to market can mean all the difference. More and more often, tech leaders are turning to external agencies to fill their development capacity gaps. In such circumstances, signing a software development contract is an unavoidable step.

Knowing software development contract standards helps you decide faster and with greater certainty about what should be in your contract, so you can sign it sooner, kick off your project on time and ship your product before the competition.

From our experience, managers are now looking at contracts differently and some clauses that were “red flags” before the pandemic are now heavily considered.

That’s why we prepared this guide for you so you can know what to expect from your software development contract, which parts are “industry standard” and which ones are often subject to negotiation.

What are the general areas to pay attention to in software development contracts?

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.

Intellectual property transfer

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.

Clauses related to the scope and development process

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.

What are the differences between a fixed-price contract and a time-and-materials contract? How can they help minimize risk?

A lot depends on your project methodology. There are two main options here:

  • waterfall projects where you have a clear vision of the project, its detailed scope, schedule, and budget;
  • agile projects where you have a general view of the expected solution, a very general timeframe and possibly also a budget.

The common types of contracts at your disposal are: 

  • fixed-price contracts, good for waterfall projects;
  • cost-reimbursable contracts, good for agile projects;
  • Time and Materials contracts, a hybrid of both of the aforementioned types, good for agile projects.
Fixed-price contract terms

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.

Useful types of fixed-price contracts

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.

Fixed-price contract risks

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:

  • the requirements are very well known, clear and fixed,
  • the product definition is stable,
  • the technology is understood,
  • there are no ambiguous requirements,
  • ample resources with required expertise are available freely,
  • the project is short.

Needless to say, not a lot of software projects will meet such conditions.

Cost-reimbursable contract terms

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.

Useful types of cost-reimbursable contracts

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 (T&M)

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:

  • budget caps, 
  • not-to-exceed values, 
  • time limits with risk share,
  • budgetary projections,
  • official notice on the exhaustion of projected budget (e.g. “You have spent 30%/50%/90% of your budget.”)

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.

Our main practical tips regarding contract types

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.

What terms of payment should I expect? Should I be worried about deposits/prepayments?

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.

When should IP ownership be transferred?

Typically there are two options here:

  • rights transfer upon creation of the code,
  • rights transfer upon payment.

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.

From a legal standpoint, what are the risks of implementing open-source libraries in my solution?

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: 

  • code individually created for the client under the contract, which is usually transferred with all the IP rights;
  • pre-existing IP rights to reusable components; in this case the vendor remains the holder and grants the client non-exclusive rights to use the components;
  • open source code, where the IP is under the rights of a third party; the vendor can’t transfer such IP rights, they may only grant you the license in the fullest extent possible within the scope of the original license terms.

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:

  • It is much more expensive; you pay a premium for individual work.
  • Development is much slower; using open source and pre-existing libraries can speed up development many times over.

On the other hand, open source code has its advantages:

  • Open source code is often higher quality, because it’s developed and verified by programmers from all over the world with experience in different technologies, industries, and projects. Bugs in open source software are identified very quickly as the code is being constantly reviewed by multiple developers.
  • Open source software is more secure. The community promptly finds and reports security flaws which the software owner usually fixes right away. Open sourced products cannot misuse and abuse users’ data intentionally like some proprietary software companies do. The community would discover this abuse, and the reputation of the software and its owner would be ruined.
  • Open source software is usually developed to be easily customizable. Because the source code is open, a developer can easily add changes to the functionality of the interface. 

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.

How to mitigate the risks of open source code

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: 

  • consent to commercial use; 
  • the scope of the license: territorial, time, and scope of exploitation;
  • information if the license allows for modifications;
  • additional conditions such as author’s credits, attaching readme/license.txt files, etc.

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:

  • introducing a methodology to mark open source code;
  • including detailed information about where and when the code was downloaded, and attaching all the required files (such as readme.txt or license.txt) required by the original license;
  • storing open source code in separate, appropriately marked repositories.

What is an “agile exit”? When and how can it be applied to contracts?

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:

  • Get the summary of the work done from your vendor, indicating the source for the repository.
  • The contract must allow you to combine the code with new code created by a new team.
  • Establish exit plan rules for implementing a new team or an internal IT department into the project.
  • Be sure that all confidential information is returned or deleted within a given period after the end of the contract. 

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:

  • technical documentation,
  • user documentation,
  • project documentation.

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”.

What is force majeure? When does it apply? What happens if a contract doesn’t have a force majeure clause?

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:

  1. The event was caused by an external force.
  2. The event was impossible to predict.
  3. The seller was unable to prevent the effects of the event.

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.

Final thoughts

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.

Join the tribe of top tech executives

Fill out the survey
Fill out the survey
Share this post