Ik zag het laatst weer voorbij komen in een briefing van een pitch waar ik in zat: klanten die letterlijk vragen hoe een vendor lock-in voorkomen kan worden wanneer ze bij ons bureau een website of app laten bouwen. Ergens natuurlijk een gekke vraag om aan een agency te stellen. De eerste gedachte die ik heb is dat je een klant zo lang mogelijk bij je wil houden. Dus je gaat geen gratis tips geven hoe een vendor lock-in voorkomen kan worden, toch?
En toch is de vraag heel begrijpelijk. Iedereen kent de verhalen van bedrijven die vast zaten aan hun bureau en met grote afkoopsommen pas mochten vertrekken naar een andere partij. Dat voelt ergens niet eerlijk. Je hebt betaald voor een design of een website. Je gebruikt ‘m dagelijks. En dan is die niet van jou? En je redeneert natuurlijk voor de lange termijn. Als er iets gebeurt met het bureau, of er gebeurt iets in de relatie, dan wil je weg kunnen. Meestal gebeurt dit niet, maar het gaat hier ook om het gevoel dat de flexibiliteit en de mogelijkheid er is.
Wat is een vendor lock-in?
Makkelijk gezegd kun je zeggen dat je met een vendor lock-in vast zit aan de partij waar je iets hebt gekocht. Heb je een website, webshop of app laten bouwen bij een bureau, dan ligt het intellectueel eigendom daar vaak ook. Zij zijn degene die de website hebben ontworpen en gebouwd, dus het intellectual property (IP) is van hen.
En daar is ook echt wat voor te zeggen. Soms heeft een bureau bepaalde stukken software zelf en op eigen kosten gemaakt die in allerlei projecten worden toegepast. Daar heb je als klant als het goed is ook profijt van gehad. De ontwikkelkosten liggen bijvoorbeeld lager en je hebt sneller bepaalde functionaliteit in je website omdat er iets “van de plank wordt gepakt”. Dat gaat een bureau niet zomaar weggeven, dat is software die van hun is.
En als je het helemaal platslaat: het bureau is degene die daadwerkelijk het ontwerp heeft gemaakt. En zij zijn degene die uiteindelijk iedere regel code van je applicatie hebben geschreven. Net als bij muzikanten of schilders ligt het auteursrecht in eerste instantie bij het bureau.
Om te voorkomen dat klanten snel voor een ander bureau kiezen, werpen bureau’s soms drempels op die het klanten lastig maken om weg te gaan. De vendor lock-in wordt dan groter. Bijvoorbeeld door een afkoopsom af te spreken. Als klant koop je dan het IP terug van je website en mag je er mee doen wat je wilt, maar dan moet je wel betalen. Maar zodra jij als klant de eigenaar bent van het IP, is het een stuk makkelijker om te switchen van bureau en is er dus minder snel sprake van een vendor lock-in.
Hoe voorkom je een vendor lock-in bij een digital agency?
Uiteindelijk is het doel van iedere agency om een lange termijn relatie op te bouwen met hun klanten. En bij ons bureau en bij vrijwel alle agencies die ik ken, willen ze dat bereiken omdat hun klanten blij met ze zijn. En dat klanten tevreden zijn met de dingen die de bureau’s voor ze maken. Van de agencies die bijvoorbeeld in de Fonk150 of Emerce100 staan durf ik er eigenlijk mijn hand voor in het vuur te steken dat dit hun mindset is. Geen enkel agency-baasje is trots op het feit dat klanten bij ze zitten omdat ze niet of nauwelijks weg kunnen. Daar doe je het niet voor.
En toch kun je best als klant een aantal keuzes maken of dingen regelen die gewoon slim zijn en die iedereen zou doen. Hieronder noem ik er een paar:
Vraag hoe het geregeld is met het intellectueel eigendom
Simpel, maar effectief. Vraag er gewoon naar. Bij wie ligt het IP van het design en de codebase van de site? Wat kun je vinden in de algemene voorwaarden van het bureau? Waarschijnlijk zijn er IP clausules opgenomen. Je kunt vragen of die aangepast mogen worden zodat – delen van het IP – overgedragen worden aan jou als opdrachtgever. Helemaal geen gekke vraag.
Vraag of er documentatie beschikbaar is van de codebase
Dat het IP bij jou als klant ligt is natuurlijk prettig. Maar als je een auto hebt waarvan niemand begrijpt hoe die aan moet heb je er niet zoveel aan. Check bij je bureau wat ze documenteren. Of vraag met welke codestandaarden en technieken ze werken. Als je kiest voor een goed bureau, die gebruik maakt van codestandaarden en bewezen technieken, hoeft er meestal niet zoveel gedocumenteerd te worden. Dan kun je een site aan iedere andere goede programmeur overdragen. Een uitzondering hierop zijn natuurlijk applicaties die van zichzelf ingewikkeld zijn en complexe business logic in zich hebben.
Het is meestal niet standaard dat er complete boekwerken en beschrijvingen bij je website komen, dus reserveer hiervoor extra budget als dit echt van belang is.
Kies voor gangbare, veel gebruikte technieken
Je hebt het IP van het design, de codebase en alles is strak gedocumenteerd. Ha, op naar een ander bureau! Totdat je er achter komt dat er in Nederland nauwelijks experts en bureau’s te vinden zijn die de basis van jouw software gebruiken. Vroeger zag je vaak dat bureau’s hun eigen CMS ontwikkelde. Als klant kon je dan geen kant op, want geen enkel ander bureau kan met dat CMS overweg en geen enkel bureau wil daar tijd in investeren.
Let er als klant dus op dat je kiest voor software die ook veel wordt gebruikt. Op internet kun je allerlei statistieken vinden over de adoptie van bepaalde CMS’en. De regel is simpel: hoe groter de adoptie van een bepaalde techniek, hoe meer andere bureau’s er zijn die ook met die techniek overweg kunnen, hoe kleiner de vendor lock-in.
Bouw je website, shop of applicatie met open source software
Bij Van Ons werken we al vanaf de start van ons bureau met open source software, dus dit is voor mij natuurlijk preken voor eigen parochie. Maar niet minder waar. Als je kiest voor open source software, vallen grote delen van jouw site straks al onder bijvoorbeeld de GPL licentie. Dat betekent niet dat er geen IP rust op wat het bureau custom voor je maakt. Maar, mijn ervaring is dat bureau’s die veel met open source werken, zelf heel anders tegen IP aankijken. Als een agency met open source werkt, dan hebben zij vaker waarden als vrijheid, flexibiliteit en dingen samen doen hoog in het vaandel staan. Dat praat vaak wat makkelijker als je het eens moet worden over het IP.
Maatregelen die wel de vendor lock-in verlagen, maar niet de relatie met je bureau ten goede komen
Er zijn maatregelen die een vendor lock-in kunnen verkleinen die soms heel logisch klinken, maar niet altijd even uitvoerbaar zijn in de praktijk. Soms wil je als klant altijd toegang hebben tot de codebase. Of permanent toegang tot de server. Of je wilt zelf je website hosten op je eigen server, om zeker te zijn dat je altijd bij je site kan. En ja, in eerste instantie klinkt dat goed. Maar praktisch is het niet.
Bureau’s kiezen voor bepaalde hostingpartners omdat ze weten dat ze goed zijn en omdat dat die partners goed aansluiten op hun eigen werkwijzen en processen. Denk aan de beveiligingsmaatregelen of de support buiten kantoortijden om. Dan is het heel onhandig wanneer je als klant eisen gaat stellen aan waar de site gehost moet worden, alleen maar omdat je wilt voorkomen dat je nooit meer bij de codebase kunt. Een bureau kan dan soms zijn eigen SLA niet meer goed uitvoeren.
Toegang tot de server of GIT is ook niet ideaal. Als er iets met de website aan de hand is kan er discussie ontstaan over wie dit heeft veroorzaakt. Een situatie waar iedereen liever weg van blijft. Als bureau wil je een goede SLA kunnen leveren, maar dan moet het bureau wel de volledige controle hebben.
Vertrouwen is de basis
Uiteindelijk draait het natuurlijk om goede afspraken, praktische uitvoerbaarheid maar bovenal vertrouwen. Een bureau dat vreselijk moeilijk doet over IP en dat wil beschermen met afkoopsommen is in mijn ogen iets van 15 jaar geleden. Tegelijkertijd moeten klanten de bureau’s ook het vertrouwen geven en niet ieder wachtwoord willen hebben van de server. Het moet van twee kanten komen. Als het een belangrijk topic is, bespreek dit als klant dan met je bureau. En als jullie bij elkaar passen, dan kom je er hoogstwaarschijnlijk ook gewoon uit.
Geef een reactie