Imagine that your software development company just landed a client for a profitable and long-term project. You are going to develop a mobile app for a Swedish healthcare SaaS startup. Your team needs to develop and design Android and iOS-enabled mobile apps from scratch. The client said if your work is effective, you will be contracted to provide technical support and update the product after the end of development. This project is valuable for your business with the potential to have ongoing collaboration. One of the tools you need to ensure appropriate expectations and a successful project is the Master Service Agreement. Having the MSA completed in advance makes regulations clearer for both parties and eliminates confusion.
In this article our lawyers highlight benefits of signing the MSA and describe the most crucial terms you need to include in your MSA document.
What is a master service agreement?
An MSA is a contract between a software development company and a client that outlines project expectations, communication rules, parties’ responsibilities, deadlines to provide services and pay invoices, and other essential issues. The MSA suits long-term projects and helps to make the development process predictable notwithstanding changes in a team, scope of work, and project vision. It is a framework for other documents, such as statements of work, change requests, and others.
How does an MSA work?
If you find yourself in an unpredictable situation you can find an answer in the MSA. The MSA is a guide for the software development company, the development team, and the client. The majority of the time a PM will know how to solve problems thanks to the MSA. For example, a client’s delay is a typical problem a PM will need to solve. Let’s imagine that you work on a “time and materials” basis and a client doesn’t send the materials needed for continuing the work, resulting in downtime. To protect the software development company’s interests the MSA must include a rule that downtime must be paid and deadlines will shift while a team waits for materials. Moreover, that rule helps to discipline clients. They will take all possible measures to fulfill their duties on time, because nobody wants to pay for a team that isn't working.
Some tips to draft a legally strong MSA
The MSA is usually written by a software development company and then given to a client for approval. The company’s task is to draft an agreement which will take into consideration the risks and interests of both parties. Below you will find some tips from our lawyers on writing a balanced document to satisfy clients’ requests and, at the same time, protect your company’s interests. This is what you need to do to make working with clients comfortable and productive.
The framework for creating, changing, and terminating the SoW
The MSA defines the general rules that both parties must follow, but specific details of every new task are described in a separate statement of work (SoW), which is an inherent part of an agreement. The framework for creating, changing, and terminating the SoW must be codified in the MSA.
Firstly, we advise you to set what information must be included in every SoW. For example, the definition of services and scope of work, involved team members, deadlines, payment and invoicing procedures, the way information is communicated, and the way work is delivered. In the MSA you will elaborate on all those issues.
Let’s imagine your company provides services on UI/UX for a crypto project. One of the sprints of the project is to work on a branding package. In this case in the SoW must include the following information:
- Services and scope of work. For example, the design of two logo options. Your team will research competitors to check their tone of voice, core values, messages, etc. The next step is to develop logos and make a presentation to show the idea, principal components, and implementation examples. The presentation will consist of a Google Slides deck template (9-10 slides).
- Team. The team includes a Brand Designer and a Project Manager.
- Deadline. Two months from the moment of the SoW signing. The software development company notifies the client on a timely basis when work takes longer than planned.
- Rates & billing. The branding package will be provided on a fixed price basis for the total cost of $6,500. Any extra features or deliverables must be estimated, communicated, and approved by the client before being worked on. Extra deliverables will be billed separately.
- Invoices and payment schedule. The software development company invoices the client in advance based on the individual milestones outlined in the SoW. The brand identity cost must be divided into two separate payments of $3,250 each. The invoice must be paid in full within five business days after it’s been issued and delivered to the client.
- Work Reviews. The client has the right to request work reviews with the relevant PM assigned to the relevant SoW.
- Communication. Emails, WhatsApp, Google Chat, Slack, Discord, or anything similar.
- Artifacts & Deliverables. Figma files accessible via secure URL. Google Slides or PDF presentations are accessible via a secure URL.
Please, take into consideration that the SoW for outstaffing services will be different. That SoW must include, at a minimum, the list of the development team members, every team member’s fixed fee and role.
Secondly, don’t forget to come to an agreement with clients on the conditions of the SoW changing, pausing, and terminating.
The client can change the scope of work, so the MSA must define the exact procedure if such a situation occurs. A Change request means one of two things. Either the client's demand for additional work that was not defined in the agreed and settled SoW or a change in the technical specifications. For example, the following situations would be considered changes:
- Adding a new task or milestone (function, feature, module, service)
- Updating the scope of existing tasks
- Updating the order of existing tasks
- Deleting an existing task
- Changing the technology
New services added through the change request are evaluated by the software development company and incur an additional expense which must be paid by the client.
We advise you to take change requests and their content seriously, because only correctly formed documents can be used in court if the client refuses to pay for work. Such a situation happened with CIGNEX, a global consulting company offering solutions, services, and platforms on Open Source, Cloud, and Automation technologies. The company’s client refused to pay more than $350,000 for services provided under five change requests. Three of them were signed by parties and set forth the amount of time spent by CIGNEX’s team members on certain phases of the project, along with their hourly rates. The other two change requests were not agreed to nor executed in writing. So, the US court for the district of Delaware ruled that debt collection was only available for the three properly executed change requests. That means even small changes must be codified by signing a change request.
The next step is to set the termination procedure. Оne or both of the parties may terminate any SoW in whole or in part. To protect a software development company’s rights, it is crucial to set the term in which the client must give notice for termination, for example 30 business days. After receipt of such notice, the company informs the client of all work that has been completed through the date of notification. The client undertakes to accept and pay for the work, performed before the date of the SoW termination.
Moreover, the software development company reserves the right to suspend or stop performing work in the event that payment has not been made within the term set in the MSA.
Having a well-documented SoW, change request, and termination procedure in place provides clarity and transparency, helping to avoid conflicts and reduce risks.
Notify the client about downtime consequences
Downtime potentially results in financial losses and project delays, but the inclusion of appropriate clauses in the MSA can help mitigate and effectively handle these risks. Let's take a look at some of them.
- Definition of downtime. The task is to define that downtime is the time during which the project team does not work due to delays by a сlient. That clause in the MSA ensures everyone is on the same page when it comes to understanding what constitutes downtime.
- Determination of the party responsible for the downtime. These delays might include the client's failure to provide necessary access, materials or information, lack of response, or failure to set or update tasks.
- Detailing the consequences of downtime. We suggest that you include a provision on payment for downtime at the rate specified in the SoW. Downtime does not affect the total sum to pay under the respective SoW.
Write clauses concerning debugging
First of all, include in the MSA a definition for what is considered a bug. A bug is anything preventing the software from proper and stable performance, caused by mistakes made by the software development company’s team members. Bugs can be classified in the following way:
- Blockers that make using the software impossible. These bugs negatively affect the software and the client's business.
- Major bugs prevent the key functionality of the software from working properly such as significant deviation from the business logic or incorrect implementation of necessary functions.
- Minor bugs do not affect the proper functioning of the software but impede user experience, for example UI/UX design, and can cause detrimental effects to the usability defined in the SoW.
Secondly, set the warranty period during which the client can contact the company and request bug fixes. For example, the client can send a request to the software development company within 45 days from the moment of full payment for the provided services.
When a client sends a request, it's up to the company to identify whether it's a bug or a change request. The company identifies and fixes bugs free of charge if the following requirements are met:
- The bug was not and could not have been identified at the time of acceptance of work.
- The bug was caused by a technical error by a team member and, as a result, the software mismatched the technical requirements.
- Third parties did not make changes to the software code, and the company is the exclusive developer of the software code.
Moreover, the following cases must not be classified as bugs:
- Errors resulting from fundamental defects in the client's source materials.
- Additional work resulting from a Change request.
How to get an effective Master Service Agreement?
To customize and write an effective MSA you need to take into consideration crucial project features, such as your business model (outsourcing or outstaffing) and payment model (fixed price or time & material). Those features create different risks, so the MSA must include clauses to account for your company's specific challenges.
The MSA is not the only document which you need to sign with a client. To understand the full scope of the documents required to protect your company, read our articles on NDAs and DPAs.
