Ons 'starten in crisistijd' programma is nu online. Bekijk het hier

Software startup? Zo waarborg je de continuïteit voor je klanten

Hoe voorkomen jullie dat ik met lege handen sta als jullie failliet gaan?” is een veelgestelde vraag waar beginnende technologie startups tegenaan lopen. En het is ook geen rare vraag. Als technologie startup ontwikkel je immers een product dat echt impact heeft voor je klant. En als het eenmaal de impact heeft die je hebt beloofd, dan wil een organisatie ook niet meer zonder jouw oplossing. Daarom is het belangrijk een duidelijk antwoord te hebben op deze vraag voor je het verkoopproces start.

Escrow overeenkomst

De oplossing voor dit vraagstuk is een zogenaamde escrow overeenkomst. In een escrow overeenkomst wordt vastgelegd wat er gebeurt met de oplossing als je startup failliet gaat of de continuïteit van de oplossing in gevaar komt door bijvoorbeeld ziekte of onderlinge disputen.

Hoe werkte dat ooit?

In de tijd dat softwareontwikkeling een eenmalig project was met een duidelijk begin-, midden- en eindfase werd er na oplevering van de applicatie een kopie van de software gedeponeerd bij een notaris. Bij een faillissement van de leverancier werden de voorwaarden voor de escrow regeling gecontroleerd, waarna – bij goedkeuring – een kopie van de software werd overhandigd aan de begunstigde partij. Zo was het voor een klant mogelijk om de software waarvoor hij betaald had te blijven gebruiken en te onderhouden.

Hoe werkt escrow vandaag de dag?

Het antwoord op de vraag hoe een escrow regeling vandaag de dag is opgebouwd is complex. Eerst moeten we context geven in het systeemlandschap dat komt kijken bij een software applicatie anno 2020. Hierin maken we een onderverdeling in ‘code’ en ‘data’.

Code

Veel technologie startups maken gebruik van betrouwbare managed-hosting partijen of clouddiensten voor het hosten van de ontwikkelde applicaties. Dat zijn de plekken waar de meest actuele versie van de software beschikbaar is. Dit is tevens de omgeving waar klanten in werken.

De applicatie wordt daarheen gestuurd op het moment dat een nieuwe versie van de applicatie gereed is en alle tests heeft doorstaan. In vakjargon heet zo’n omgeving die je als klant gebruikt een productie-omgeving, en het volledige proces wordt OTAP (in het engels DTAP) genoemd. Dit staat voor ontwikkelen, testen, acceptatie en productie.

Hierdoor zijn er in de meeste gevallen 3 versies van de code:

  • De code die wordt gebruikt door de eindgebruiker op de productie-omgeving.
  • De nieuwe versie van het product die op de acceptatie-omgeving is aangeboden ter goedkeuring voor de (interne) testers van het product.
  • De omgeving waaraan ontwikkelaars op dit moment aan het programmeren zijn.

Om overzicht te houden wordt gebruik gemaakt van een versiebeheersysteem, in verreweg de meeste gevallen is dat Git. Om gemakkelijk te kunnen navigeren door alle mappen van de verschillende versies wordt gebruik gemaakt van online oplossingen die dit visueel maakt. Bekende oplossingen daarvoor zijn Github, Bitbucket en Gitlab.

Een groot voordeel van dergelijke oplossingen is dat de code door gebruik van oplossingen als Github ook meteen online is geback-upt.

Data

Wanneer je als software startup impact hebt gemaakt voor een gebruiker leidt dit er in de meeste gevallen toe dat deze persoon of organisatie veel data in het systeem heeft staan. Deze data bevindt zich niet in de code, maar in de achterliggende database.

Doordat de data niet wordt meegenomen in het OTAP proces is er ook geen sprake van versiebeheer via oplossingen als Github zoals we dat eerder beschreven. Wel worden databases met regelmaat geback-upt. Veelal is dit een dienst die door de software ontwikkelaar wordt uitbesteed aan de hostingpartij.

Escrow anno 2020

Doordat software vandaag de dag continu wordt doorontwikkeld is het eenmalig deponeren van de software geen optie meer. Het aanbieden van de ontwikkelde code aan een onafhankelijke derde partij dient een proces te worden dat onderdeel is van de zogenaamde “software release cycle“. In de praktijk komt het er daardoor op neer dat iedere keer wanneer een omgeving wordt goedgekeurd en aangeboden wordt op de productie-omgeving, er ook een kopie van de code wordt gedeponeerd bij de onafhankelijke derde partij. Daardoor heeft de klant in het geval van een faillissement altijd toegang tot de versie die tot het laatste moment is gebruikt, zonder verlies van functionaliteit.

Voor data geldt eigenlijk precies hetzelfde als voor code. Door met regelmaat een versie te deponeren bij een onafhankelijke derde partij is ook het risico op verlies van data afgedicht. Al is het wel belangrijk om daarbij oog te hebben over de mutaties die plaats hebben gevonden tussen het moment dat er is gedeponeerd en het moment dat het systeem ontoegankelijk werd. De frequentie waarmee een backup van de data wordt aangeleverd bij een derde partij zal dan ook sterk afhangen van het type oplossing waarvoor de applicatie is ontwikkelt.

In elkaar verweven data
In het geval van een software oplossing is data van meerdere klanten veelal in dezelfde database vastgelegd. Wanneer de escrow overeenkomst wordt geëffectueerd zal deze data eerst moeten worden ontvlochten alvorens de data ter beschikking wordt gesteld. Dit in verband met de nieuwe AVG wet die sinds 25 mei 2018 van kracht is.

Een ESCROW Alternatief

Een alternatief voor deze vorm van ESCROW is een driepartijenovereenkomst. Daarbij tekenen de leverancier, afnemer en hostingpartij een overeenkomst. In deze overeenkomst leggen zij vast dat, mits de afnemer de hostingkosten betaalt, de hostingpartij meewerkt aan overdracht van code en data op het moment dat de leverancier failliet gaat.

Conclusie

Wie wil voorkomen dat de continuïteit een deal-breaker is, ontkomt er niet aan zijn processen goed in te richten. Het vraagt om extra discipline, bewaking van processen en escrow overeenkomsten voor zowel de data als de ontwikkelde code. Maar zo waarborg je wel de continuïteit voor je klanten.


ICTrecht
Dit artikel werd geschreven in samenwerking met onze partner ICTrecht. Vanuit de kantoren in Amsterdam, Groningen en Brussel levert ICTRecht deskundig en praktisch juridisch advies over ICT, privacy en recht.

Geplaatst door:

19 mei 2020 door

Trotse partner van o.a.:

SEO & SEA Marketing

Efluence

ICTrecht

Emendis

True

  • © Forwardis B.V. Alle Rechten Voorbehouden

Share via
Copy link
Powered by Social Snap