Wat het contract goed moet regelen

Een contract voor softwareontwikkeling op maat is niet zomaar papierwerk. Het bepaalt wie wat bezit, wie waarvoor verantwoordelijk is en wat er gebeurt als het misgaat. We hebben genoeg projecten meegemaakt om te weten dat een slecht opgesteld contract problemen veroorzaakt die geen enkele goede wil kan oplossen. Hier zijn tien dingen die je voor ondertekening goed moet regelen.

1. Geen opzeggingsclausule

Als de leverancier niet levert, kun je dan het contract beëindigen? Zonder een duidelijke opzeggingsclausule heb je daar mogelijk geen juridische grond voor. Zorg dat je contract je de mogelijkheid geeft om de samenwerking te beëindigen als je niet tevreden bent, en wees specifiek over welke omstandigheden dat recht activeren.

2. Onduidelijke scope en geen gedefinieerd proces

Scopedocumenten zijn op zichzelf niet voldoende. De leverancier zal jouw vereisten anders interpreteren dan jij bedoelde, en zonder een gedefinieerd ontwikkelingsproces is er geen mechanisme om dat vroeg te ontdekken. Je contract moet specificeren hoe werk wordt opgesplitst in iteraties, hoe je de voortgang beoordeelt en hoe wijzigingen worden verwerkt. Een proces dat je elke twee weken werkende software laat zien, biedt veel meer bescherming dan een gedetailleerd specificatiedocument.

3. Vage betalingsvoorwaarden

Duidelijke betalingsvoorwaarden beschermen beide partijen. Vage voorwaarden leiden tot geschillen over wanneer betaling verschuldigd is, wat een voltooide mijlpaal inhoudt en wat er gebeurt als een van beide partijen te laat is. Leg dit voor de start van het project concreet vast.

4. Geen intellectuele-eigendomsclausule

Wie is eigenaar van de code? In de meeste Nederlandse en Europese contracten is de opdrachtgever eigenaar van alles wat in het kader van een werk-voor-huur-overeenkomst wordt geproduceerd. Ga daar niet van uit. Leg het schriftelijk vast. Specificeer ook dat de leverancier jouw code niet opnieuw mag gebruiken voor andere klanten.

5. Geen aansprakelijkheidsclausule

Als de leverancier gebrekkige code levert die schade veroorzaakt aan jouw bedrijf of klanten, is hij dan aansprakelijk? Leveranciers willen hun aansprakelijkheid beperken, vaak tot de waarde van het contract. Zorg dat een eventueel aansprakelijkheidsplafond hoog genoeg is om jouw daadwerkelijke risicoBlootstelling te dekken.

6. Geen geheimhoudingsovereenkomst

Je leverancier heeft toegang tot jouw processen, jouw gegevens en soms de informatie van jouw klanten. Een geheimhoudingsovereenkomst moet doorlopen na het einde van het project, doorgaans ten minste een jaar, en moet alle teamleden aan de kant van de leverancier omvatten.

7. Geen geschillenbeslechtingsmechanisme

Als er een geschil ontstaat, is naar de rechter stappen langzaam en duur. Leg in het contract vast hoe geschillen worden opgelost, of via bindende arbitrage, mediation of een ander mechanisme. Dit is veel eenvoudiger overeen te komen voor een geschil dan erna.

8. Geen non-solicitatieclausule

Wat gebeurt er als de leverancier jouw medewerkers wegkaapt, of jij die van hen? Een non-solicitatieclausule legt de regels voor beide partijen vast en vermindert het risico op ongemakkelijke situaties tijdens of na het project.

9. Geen belangenconflictclausule

Werkt de leverancier aan hetzelfde vraagstuk voor een van jouw concurrenten? Een belangenconflictclausule verplicht hen dit te melden en geeft je verhaal als het zonder melding gebeurt.

10. Geen ondersteuningsovereenkomst

Het project is klaar en de software draait in productie. Er duikt een bug op. Wie lost dat op? Leg de verantwoordelijkheden van de leverancier na de livegang vast voor je tekent, niet erna. Bepaal of je een doorlopende ondersteuningsovereenkomst wilt, een garantieperiode of een overdracht aan je interne team, en leg dat vast.

Neem contact met ons op voor meer informatie over hoe we onze softwareontwikkeling op maat trajecten structureren.