De wereld ligt vol met kansen terwijl het aantal ondernemers met een goed idee hard groeit. Het fijne van de ontwikkelingen in de it zijn de vrijwel oneindige mogelijkheden. Veel succesvolle samenwerkingen ontstaan dan ook op de volgende manier: een ondernemer ziet een grote kans in de markt, hij of zij zoekt een programmeur en samen maken ze de toekomst.
Ze vertrouwen elkaar blind, werken knetterhard en na een roerige start groeit de saas-applicatie. Dit betekent dat er features, klanten en daarmee ook vragen bijkomen. De ontwikkelaar en ondernemer bouwen door, maar dan ontstaan de eerste scheurtjes in de samenwerking. Het wordt voor de programmeur of kleine ontwikkelpartij steeds lastiger om de applicatie te onderhouden en de samenwerkingspartners realiseren zich dat ze elkaar ontgroeid zijn. Ondanks hun wederzijdse waardering is het tijd om ieder een eigen pad te bewandelen.
En dan?
Uitdaging
Als je als saas-ondernemer tot op dit punt niet hebt nagedacht over intellectuele-eigendomsrecht, de kwaliteit en continuïteit van jouw applicatie sta je voor een uitdaging. Want net als bij een huwelijk zonder huwelijkse voorwaarden, kan het ingewikkeld zijn om achteraf te bepalen wie waar recht op heeft en hoe je verder gaat met jouw gezamenlijke product.
Of beter gezegd, wie mag dit doorontwikkelen? Ga je een saas-product ontwikkelen? Sta dan eerst stil bij deze drie vragen:
- Hett intellectuele-eigendomsrecht: van wie is de broncode en mag ik dit overnemen?
- Kwaliteit van de code en werk: welke techniek wordt gebruikt en kan ik iemand vinden die dit kan overnemen?
- Continuïteit: met wie ga ik dit product ontwikkelen en kan diegene mij ook helpen bij flinke groei?
Intellectueel eigendom
Bij een saas-applicatie ligt het kapitaal van het bedrijf voor een groot deel in de applicatie zelf. Het is daarom belangrijk om goede afspraken over intellectueel eigendom te maken want dat wordt in dit geval door een ander, de ontwikkelaar of ontwikkelpartij, gegenereerd.
Intellectueel eigendom kan op de volgende manieren tot stand komen:
- Via medewerkers. Zij hebben in principe het intellectueel eigendomsrecht over hetgeen ze ontwikkelen. In de meeste arbeidsovereenkomsten is echter afgesproken dat zij dit overdragen aan het bedrijf waar ze werken.
- Door de inzet van consultants en externen. Tenzij anders contractueel afgesproken hebben zij het intellectueel eigendomsrecht van hetgeen ze ontwikkelen.
- Via een bedrijf dat de software ontwikkelt. Ondanks dat opdrachtgevers betalen voor de diensten die ze leveren, heeft het bedrijf dat de software ontwikkelt (en dus niet de opdrachtgever) het intellectueel eigendomsrecht op wat zij oplevert. Tenzij anders afgesproken.
En dit laatste, tenzij anders afgesproken, is van belang bij een saas-onderneming. Zorg dus dat je vooraf helder hebt van wie de broncode is, of dit nog officieel moet worden overgedragen en of dit goed is geregeld in zowel de arbeidscontracten en overeenkomsten met externen. Controleer daarnaast of licenties van externe leveranciers overdraagbaar zijn.
Ontwikkelpartij
In de meeste gevallen beschikt een programmeur of ontwikkelpartij over kennis en expertise die je zelf niet hebt. Voor een fijne samenwerking moet er sprake zijn van wederzijds vertrouwen. Wil je meer te weten komen over jouw softwareontwikkelaar? Stel dan de volgende vragen.
- Welke technieken worden gebruikt en waarom wordt daarvoor gekozen?
- Beschikt de ontwikkelpartij over certificeringen of zijn ze aangesloten bij een brancheorganisatie?
- Hoe borgt de ontwikkelaar de kwaliteit?
- Is het mogelijk om bestaande klanten of referenties te spreken?
- Hoe is hosting en de servicedienstverlening geregeld?
Als je ontwikkelaar bijvoorbeeld aangeeft dat hij of zij Laravel gebruikt, onderzoek dan door hoeveel ontwikkelaars dit wordt gebruikt, of er een brancheorganisatie is die de kwaliteit borgt en of andere partijen hiermee kunnen werken. Stel daarnaast voor een code review of externe assessment te laten uitvoeren. Op die manier voorkom je verrassingen in een later stadium.
Continuïteit staat voorop
Door samen te werken met een ontwikkelpartij kun je in korte tijd hard groeien. Je kunt jouw ambitie en ondernemersplan realiseren, maar deze samenwerking zorgt ook voor een bepaalde mate van afhankelijkheid. Wil je er zeker van zijn dat jouw ontwikkelaar jouw project aankan en je geen onnodige vertraging oploopt, dan kun je vooraf een aantal dingen doen. Voer bijvoorbeeld een kredietcheck uit en probeer in te schatten hoe belangrijk jij bent voor de ontwikkelpartij. Er kleven risico’s aan zowel de grootste als de kleinste opdrachtgever zijn. Overleg daarnaast over jouw team, wie werken er aan jouw product, hebben ze eventuele back-up in huis en hoe is kennismanagement geregeld? Bedenk dat in veel gevallen een lage prijs ook lage kwaliteit betekent, omdat ‘randzaken’ zoals documentatie en kennismanagement worden weggelaten.
Een saas-onderneming opbouwen is een mooi avontuur. Wat je ook kiest, een grote ontwikkelpartij of een goede zelfstandige developer die vanuit huis werkt, kies vooral bewust. Dit doe je door alle risico’s in kaart te brengen en hiernaar te handelen. Als je dit doet, staat niets jouw succes meer in de weg!
(Auteur Maurits Dijkgraaf is saas-ondernemer en oprichter van PAQT.)
Het is goed om ook aandacht te geven aan de non-technische issues want deze worden te vaak vergeten doordat de meeste ondernemers vooral kansen zien en de risico’s daarom bagatalliseren. Oja, naast het in kaart brengen van de risico’s moet je er een plan bij opstellen om de impact hiervan te mitigeren. En ik vraag me daarom af of je niet beter het idee zelf kunt beschermen in plaats van de code want deze is vaak wel vervangbaar als je een goed bouwplan hebt. Uitwisselbaarheid van de planken en spijkers in het bouwplan zorgt ervoor dat je niet alleen van de code kunt wisselen maar ook van provider, of de middleware. Ik zou bijna zeggen dat je daarom het beste voor open source code kunt kiezen. Bijna zit in de mogelijke risico’s die meekomen met het concept van open source want continuïteit zit meer in de details dan in de schaal.
Repelsteeltje schreef ooit eens over de ‘ketenproblematiek’ bij SaaS omdat het intellectuele eigendom van de code meer een contractueel punt is dan een issue in de continuïteit als je geen toegang meer hebt tot de data. En hoeveel SaaS-ondernemers zijn hierdoor verdronken? We mogen geen namen noemen maar een klantenbestand is vaak waardevoller dan de code. En reversed engineering van de processen op basis van een bouwplan kost soms minder tijd dan het herstellen van een ransomware aanval.
Dag Oudlid,
Dank voor je inhoudelijke reactie! Ik kan me zeker vinden in wat je zegt, uiteindelijk is mijn ervaring dat het klantenbestand en de passie en visie van de ondernemer het meest doorslaggevend is. Wat ik echter ook heb gezien is dat ondernemers uit enthousiasme vergeten wat de gevolgen zijn van het niet bij je eigen code kunnen (doordat je geen toegang hebt of het IP niet hebt). Als je dan een conflict hebt met de partij die jou de toegang beperkt kun je niet door, opnieuw ontwikkelen kan maanden tot jaren kosten en dat kost je dan weer je klanten. In mijn beleving kan dat allemaal voorkomen worden door dit van tevoren goed te regelen.
Wat betreft jouw voorstel inzake open source, ik ben zelf een groot voorstander van open source software. Ik vat je punt alleen niet wat het voordeel hiervan is inzake dit vraagstuk. Zou je dat nog wat willen toelichten?
Maurits,
Een strategisch gebruik van open source richt zich op de toegang tot de code om deze te kunnen hergebruiken hoewel dat helaas nog niks zegt over de leesbaarheid en onderhoudbaarheid als we kijken naar spaghetticode. En uiteraard kan hergebruik van code beperkt worden door een licentie maar ik denk niet dat dit een verrassing achteraf is als je weloverwogen en niet uit zuinigheid een keus maakt voor open source.
Oja, SaaS is naar mijn opinie vanuit de techniek vooral een plaatsingsmodel waarbij het gemak waarmee een softwareproduct van de ene hardware- of softwareomgeving naar de andere kan worden overgezet bepalend is voor de portabiliteit. Voor het gemak net zoals Nespresso code verpakken in een oplossing van capsules die maar door één machine gebruikt kunnen vergroot misschien wel het gemak maar niet de uitwisselbaarheid.