A software development agreement is a contract between a software team and a client.
It can be frustrating to have to work through legal documents before starting the work. Most people don’t enjoy reading legal documents. But having an agreement in place will help your relationship.
A software development agreement can protect your team and your client. It will act as a basis from which a great relationship can start by defining expectations.
Today, we’re going to share some of the key points you should consider when drafting an agreement.
As with any legal document, you should have your work reviewed by a solicitor or lawyer. Factor in that you may need to pay attorney fees.
1. Work Phases
A work phase outlines when your software team will complete a body of work.
Work phases break the project down into discrete milestones. They list deliverables and their respective deadlines.
When you clearly state work phases in an agreement, you prevent client disappointment and negative consequences such as claims of breach of contract.
Work phases are a two-way street. It isn’t all about when you will provide the work, it will also specify when your client needs to provide feedback. Specifying needs and timeframes can help frame future, potentially difficult, discussions.
2. Payment Times and Amounts
Establishing the payment times and amounts will ensure that you won’t be waiting for payment.
The two most common forms of payment agreement are:
- Fixed-price – a price given to an entire project. Fixed-price can be helpful to your client as they will know upfront what the project will cost. Your client will have the leverage to insist on how the project looks at the end and how long it takes to develop.
- Time and materials – your client will pay you for time spent and the cost of materials. Time and materials benefit you as it means you get paid even if your project takes longer than anticipated.
Being clear about payment details will help you get paid sooner.
Pro Tip: Code faster with TextExpander
TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more.
3. Intellectual Property and Moral Rights
A common issue when developing software is understanding who owns the intellectual property (IP).
Unless an agreement defines who owns the intellectual property, it will default to the creator. In the case of software development projects, that would be your development team.
You holding the IP can cause issues. Your client may be unable to extend the scope of the product as they do not own the copyright.
If your client has the copyright signed over to them, it may lead to issues. For instance, you won’t be able to reuse any code created for the project in other, unrelated projects.
Moral rights are the rights of the creators of copyrighted works. These are similar to IP but focus on general attribution, not ownership. Default moral rights will depend on your jurisdiction. With software, sometimes developers are not attributed to works. You should check with local laws to see if you need to make a statement about moral rights.
IP and moral rights are an example of when you need legalese. There are certain phrases your contract requires to stand up to scrutiny. Having the right wording now can save you in legal costs in the future.
4. Open-Source Software
Most software developers will use open source libraries when developing software applications.
Your client may want to have a full list of the libraries used during the development of the application.
Your client needs to know that your developer has complied with the requirements for using that piece of open-source software.
The use of open-source software is often overlooked when drafting agreements. Not having something clearly written can make things hard for your client during audits or due-diligence checks.
5. Warranty
A warranty is a promise that a product will work in a certain way for a certain length of time.
If it does not, then there should be an agreement in place that your developers will fix bugs or any issues that arise.
You should agree on the terms with your client and detail these in the software development agreement.
You should not make claims that the software will work indefinitely. The ever-changing technological landscape may make this impossible. Typically, software warranties last for 90 days to a year.
Without a firm statement, your client might think you will support the product forever.
6. Developer and Client Testing
The software development agreement should outline the required testing.
Some software development methodologies have testing as a separate phase of development. You should document if your client has requested a reduction in the testing phase.
You should note if your client has a specific QA process which should form part of the testing.
Your agreement should state what the repercussions are if your client fails to test something you asked them to.
Like work phases, setting expectations now can help frame conversations later.
7. Software Installation and Integration
The agreement should state if you are supplying DevOps as well as providing the software.
If your client is handling DevOps, you should document how handover will happen.
Any gaps when discussing the installation or integration can lead to frustration. Often, your client will assume your developers would handle everything. A good software development agreement clears this up.
8. Ongoing Support
Related to the installation and integration is ongoing support.
If you expect to support this project going forward, your agreement needs to outline what form that will take.
Specifically, you will want to outline what channels are open for support. Common support channels include phone, email, or a dedicated channel in Slack.
Your agreement should outline the type of support you are willing to provide. It should answer questions like “how do we onboard new people” and “how do we learn about these features”.
A service level agreement is a more substantial document you may need if handling support. A version mentioning your core business hours and response times will suffice for a development agreement.
An excellent software development agreement makes it clear where support stops and feature development starts.
9. Maintenance Services
Maintenance services are like support but focus on keeping everything up to date.
If you include ongoing maintenance, your agreement should be clear on what is general maintenance and what is extra work.
You might include minor updates to software dependencies, but not significant updates.
Security upgrades can occasionally require a significant rework of sections. It would be best if you documented how security updates might impact the project.
Support and maintenance are an excellent way for you to make money once the project is complete.
10. Termination
Like all contracts, you can terminate a software development agreement. The termination section outlines the circumstances under which you or your client can end the contract.
The core questions to cover are:
- How can the termination happen?
- What happens to money owed?
- What is the required amount of written notice?
- Does your client need to stop using your code?
- Do your developers need to hand over code?
- What provisions of the software development agreement should survive the termination?
No one wants to end a contract early, but by outlining the procedures at least the way termination happens is predictable.
11. Dispute Resolution
Even with an excellent development agreement, disputes can happen. The dispute resolution section handles how either side can open a dispute.
Outlining what laws are applicable in this situation, and specifically, the country of the law is essential.
The country stated in the agreement will make a big difference in what laws are applicable. What is common practice in one country may be unheard of in others.
As a general rule, you should pick the country in which you do business, as you will be able to find legal help more quickly.
Taking the time to clearly outline the dispute resolution process can save you in potential legal fees down the line.
12. Source Code Escrow
It may be sensible to suggest keeping code in a source code escrow.
Source code escrow is the deposit of a codebase with a trusted third party.
Having code sit in escrow ensures maintenance and security in the event of a breakdown between the developers and your client.
Including a section in your agreement about source code escrow will show you care about the long term success of the project.
Set Your Project Up For Success
A software development agreement is a formality. Yet, by including the sections above you lay the foundation for a successful project.
As with all forms of communication, the more clear you can make it the better your relationship with your client will be.
A software development agreement is worth writing well. In the best-case scenario, you will only refer to this document once, and you will look professional.
In the worst case, you will be using this document to save you thousands in legal fees and lost time.
Either way, a concise, clear agreement will help you.
Not able to play the video? Click here to watch the video
