What to look for when creating custom software:

In contrast to the standard software, the individual software distinguishes that these (in most cases) will only exist once in the form to be produced. In this respect, the so-called obligation or specifications plays a major role. In doing so, the characteristics of the software to be created between the purchaser and the contractor are summarized in concrete terms. This obligation or performance specification plays such a large role, because it provides information in future disputes, the extent of the software or any defects occurring. In addition, it is advisable to lay down the purpose of the individual software in as much detail as possible in a preamble to the contract in addition to the specifications or specifications.

For a good individual software is always a reasonable documentation. Any good software is worthless or worthless without a documentation that provides information on the source code, applicability, administration, etc.

A distinction is primarily made here between administration, installation and operating documentation, program and source code documentation, the training documents, the project management documentation and the test documentation. This list is not exhaustive and can be expanded from case to case. However, the previous types of documentation have proven useful in the creation of most custom software. It is therefore advisable to contractually agree at least the mentioned types of documentation.

It is strongly recommended that a contractual agreement be made on who owns the source code. Because if this was not contractually agreed, this should be judged according to the circumstances of each case. Characteristics such as the amount of the agreed wages are of great importance, and whether the program should be used for marketing by the purchaser and whether the purchaser could also need the source code for the maintenance and further development of the program. Again, there is great potential for conflict.

As you can see, the transmission of the source code is not necessarily due. In that sense, you should think carefully about whether you might not need it someday. Then it would be a gross error not to include the transmission of the source code in the contract.

If the parties subsequently discover any inadequacies of the contract, they must interpret the closed contract. That this is not necessarily beneficial for both sides, is obvious. If, for example, it has not been agreed in detail (keyword: obligations or specifications) what the program to be created has to do, then the contractor owes only a software that takes into account the contractual (basic) purpose the current state of the art in a medium Execution standard corresponds (BGH MMR 2004,356). In case of doubt, one must use such problems, in a legal procedure of an expensive expert.

Since, as already mentioned above, the creation of individual software is primarily based on the contract work law (§§ 631 ff. BGB), these standards are to be used. According to this, one of the most important duties of the manufacturer of the work is that he has to procure the work free of material and legal defects (§ 633 para. 1 BGB). The scale is to be judged according to § 633 Abs. 2 BGB. Consequently, the work is free of defects if it has the agreed quality. The agreed condition is determined in the contract. Here you can again recognize that the design of a contract in the software sector is of very great importance.

For example, the following defects could occur (depending on the content of the contract):

• Lack of development speed (BGH CR 1996, 667)
• Lack of data backup option (BGH NJW 1996, 2924)
• Virus attack caused by the contractor (Schneider / Günter CR1997, 389)
• A faulty, hardly understandable or even missing documentation (BGH NJW 2001, 1718)
• Missing plausibility check of user input (LG Heilbronn CR1989, 603)

Since, as already mentioned above, the creation of individual software is primarily based on the contract work law (§§ 631 ff. BGB), these standards are to be used. According to this, one of the most important duties of the manufacturer of the work is that he has to procure the work free of material and legal defects (§ 633 para. 1 BGB). The scale is to be judged according to § 633 Abs. 2 BGB. Consequently, the work is free of defects if it has the agreed quality. The agreed condition is determined in the contract. Here you can again recognize that the design of a contract in the software sector is of very great importance.

For example, the following defects could occur (depending on the content of the contract):

• Lack of development speed (BGH CR 1996, 667)
• Lack of data backup option (BGH NJW 1996, 2924)
• Virus attack caused by the contractor (Schneider / Günter CR1997, 389)
• A faulty, hardly understandable or even missing documentation (BGH NJW 2001, 1718)
• Missing plausibility check of user input (LG Heilbronn CR1989, 603)

Since the warranty rights are based on the general contract of employment law, the funds listed here must also be used.

Until the acceptance, the software orderer can refuse acceptance of the software due to a defect, unless the defect of the software - which the factory contractor has to explain in response to the complaint of the works orderer - is insignificant according to § 640 para. 1 S. 2 BGB. This can open up a large spectrum of defects in individual software. However, only if the contracts are sufficient and reasonably written according to the purpose of the contract. Otherwise, it is to be expected that the contractual relationship will be disturbed and the creation of the desired software will be delayed or no longer carried out. At least that is our practical experience in this area.

After the acceptance the rights of the software applicator according to § 634 Nr. 1 to 4 BGB come into consideration. Here, the preceded applies even more. Because now it is the software orderer, which must prove any defects. The requirements for this are quite high.