Software development agreements: a checklist
Yes! You’ve found a great agency to develop a brilliant piece of new software. But before even one line of code gets written, your service agreement needs to get drawn up.
Don’t look at this as tedious admin. View it as your roadmap in ensuring everyone is on the same exciting journey ahead. You don’t have to be technically minded either, as most of it is a mix of common sense and ensuring good communication. Get it right and this agreement will drive all the expected behaviour before, during and after the project, for both sides of the table.
Whilst design and dev processes will vary depending on the project, here are some key questions you should think about before drafting up your agreement.
- Who will own the intellectual property rights (IP)?
Basically, who will own the final product – the agency who developed it, or the customer who is paying for it? If it’s agreed that the customer will be the copyright holder, the developer must grant a licence to the customer, or assign the intellectual property rights over.
- The development process
This can be tricky, as it should be as detailed as possible, but often the finer details can only be made once the project has started. However, there will always be an ultimate goal e.g. release a translation software, and within that you can factor in MVPs (minimum viable products).
You can also determine the project management methodology that will be used. Waterfall or Agile / Scrum, for example. And within this, what the phases and iterations will look like.
- Testing
Testing is fundamental and should take place throughout the project. Agree on what testing is going to take place during development, at each release stage and before final release. This will include internal QA (quality assurance), client testing and user testing. Minimal Viable Product (MVP) releases can help to drive this.
- Aftercare
Decide on what support and maintenance will be provided after the development is completed and released. Your service agreement may include some support provisions, although it’s more common for services beyond the project to be based on a separate fee.
A common option is a ‘time and materials’ contract, where an agency charge for whatever time they are then needed for. Or alternatively you can choose a fixed rate e.g. x% hours of frontend/backend dev per month.
- Exclusions
What will not be included in the agreed fee? For example, ‘training’ and ‘documentations’, might be written in as out of scope. Check with the agency/developer about what their normal exclusions are.
- Timeframe
When it comes to large projects, it’s nearly impossible to determine what exactly will be done at a given time.
This can be easier to gauge by breaking it up into regular milestones, which in turn breaks down the project into agreed deliverables. At the end of each stage you can get work signed off and see where you are in a time range. This regular communication also helps to make sure that you are heading towards the software you had in mind.
- Cost/payment
Once you’ve agreed on a fee, how it’s paid can vary. A popular choice to keep everything moving swiftly, is a milestones’ payment scheme. So, for example x% up front, then y% on completion of each stage. Or, alternatively, a fixed cost, time and materials contract can be more straightforward for smaller projects.
- Changes
‘Change’ is a normal part of any development project. But anything that deviates from the original ask or developed task list, will need to go under a change request which may be charged extra if it is deemed as out of scope on what has been agreed on. Discuss what warrants ‘out of scope’ before beginning the project. You should agree on a number of reviews for feedback and the type and volume of changes should be defined – the aim is to try and stop scope creep and keep the project on course.
- Warranties
Hopefully you won’t need to ever think about them again, but warranties are essential safeguards that need to be in place before starting. As a basic rule, you should at a minimum have indemnities that protect you for any loss or damage against security or stability, that could be caused by the software’s performance or copyright infringements. The developer should have indemnity insurance and it may be worth checking this is in place.
- Disputes
The whole aim of a software agreement is to avoid disputes. However, it’s always best to factor for worst case scenarios before they actually happen. It can be useful to have set procedures in place to ensure that if a dispute does occur, it’s then handled effectively.
For more detail and to get your head around the legal jargon that will be part of your next step, have a look at some of the free software development agreement templates that are out there.
data product High Digital Software Development
