You would like to have individual software developed specifically for your company’s needs, or you require external support in developing your software solution? In these cases, you must ensure that you conclude a legally compliant contract for the development of individual software. This blog article shows which regulations such a contract should contain.
Development methods
Before we look at the main contractual provisions in detail, we will first examine the methods by which your company can have software developed. Because this has an influence on the contractual structure. If software is developed according to SCRUM or another agile method, a different contract is required than for development as part of a “classic” IT project.
But what does SCRUM actually mean and how would a more classic IT project proceed in comparison? SCRUM is an agile development method that no longer knows a classic project manager and project phases, rather there are sprints with a duration of two to four weeks. In these sprints, a more or less finished result, a so-called increment, is delivered. In the SCRUM method there is the product owner on the customer side, the SCRUM master on the developer side and the development team. The product owner maintains the so-called product backlog, which contains the requirements for the software to be developed. The so-called backlog items (= entries) are processed in sprints by the development team and a release of the increments created in the sprint takes place during a sprint review meeting. A SCRUM contract should contain definitions of the listed terms and outline the process, especially for the creation of the product backlog and the sprint. These regulations are missing in a development contract that follows a more “classic” IT project. In a classic IT project, there are often project managers at both parties who coordinate in regular jour fix meetings and call on the steering committee for major decisions or disagreements. Both parties must request changes to the requirements in a formalized change request procedure and your company accepts the software after completion.
Now you may be wondering which method your company should choose? Agile methods such as SCRUM should be anchored in the mindset of your company. Experience shows that this is more the case with start-up companies.
Determining requirements correctly – the be-all and end-all for development success
Your company must be aware that the development of individual software is a collaborative project. The software developer depends on your cooperation in defining the requirements for the software to be developed. Therefore, we recommend that you first identify and involve the right stakeholders in your company and give them sufficient time to work on the requirements definition in addition to their other activities in your company. After all, the success of software development depends to a large extent on the accurate and comprehensive definition of requirements, irrespective of the development method. Ensure that the software developer in the development contract is either responsible for defining the requirements or must at least support you in an advisory capacity and define the requirements together with you. These should be well documented so that the software developer’s scope of work is clearly defined. In agile development, documentation is done in the product backlog. In the course of development, you will find several times that the requirements need to be changed. These changes must also be well documented and – unless agile development is used – a change request procedure should be defined in the contract. When developing according to SCRUM, the individual increments of each sprint are prioritized and constantly changing requirements can be taken into account through new backlog items. In the context of SCRUM development, requirements can be adapted more quickly and flexibly to changed circumstances. A formal change request procedure is not required.
Rights to the individual software
When drafting the software development agreement, particular attention should be paid to the transfer of rights. It is important to ensure an exclusive and complete transfer of rights. The software developer should also hand over the source code to you. This is particularly important if the software developer develops part of the source code under your software product. If you want to use the developed software commercially for yourself, the rights granted to you should cover a transfer to third parties and a grant of rights of use to third parties.
Indemnification from claims of third parties due to infringement of property rights
The software developer should be contractually obligated to ensure that the software and his work results, above all, do not infringe third-party property rights. He should also indemnify your company against third-party claims for infringement of property rights.
Keeping budget and time schedule under control
Your company should insist on the conclusion of a contract for work (“Werkvertrag”) and agree on a fixed price for successful software development. If, even after negotiations, the software developer only agrees to development services on a time-and-materials basis, we nevertheless advise you to oblige the developer to provide an effort estimate (Time and Material) that, in the best case, represents a guaranteed upper cost limit (“cap”). Otherwise, the effort estimate should at least serve as an agreed cost limit. The developer should be obliged to inform your company when he reached e.g. about 70% of the agreed cost limit. Then, if necessary, you can work constructively with the software developer to find solutions for meeting the cost limit. In doing so, you should have the right to decide solely at your own discretion, which concrete measures the software developer must implement to comply with the cost limit. In any case, you should only have to reimburse costs that exceed the cost limit after written agreement between the parties.
Experience shows that the software developer will find it difficult to commit to fixed dates for individual development milestones. Here, too, you should insist on this or, if necessary, opt for SCRUM. This is because development in sprints, which usually take place every two to four weeks, makes it easier for your company to plan the expected completion of development. We recommend starting from a realistic time schedule and allowing for unforeseen challenges during development.
Other important contractual provisions
The software should be tested regularly and in particular after its completion and accepted as a whole at the end. In this context, it may be useful for the parties to jointly determine test and acceptance criteria when specifying the requirements for the software. Furthermore, the software development contract should regulate warranty and liability.
Support and maintenance
When designing the contractual relationship, also consider the support and maintenance of the individual software. The software will only have lasting added value for your company if its support and maintenance are ensured. Make therefore sure to agree on so-called service levels with the software developer. These essentially regulate the availability of the developer, especially for troubleshooting, and define error classes as well as response and recovery times. In addition, the software developer should be committed to regular updates of the software. To ensure successful long-term software use, the support and maintenance contract should be agreed for a fixed term (around 10 years) and the software developer should be contractually obligated to hand over detailed documentation of the software.
Conclusion
If you consider our contract drafting recommendations, get the right stakeholders in your company on board in good time, plan the time schedule and cost budget realistically and critically review offers from software developers, the chances of successful software development are good. With this in mind, good luck!