Maatwerksoftware is vaak het hart van je bedrijfsvoering. Maar wat gebeurt er als de ontwikkelaar of het bureau dat het bouwde ermee stopt? In dit artikel lees je hoe je leveranciersafhankelijkheid beperkt en je software toekomstbestendig houdt, met praktische afspraken over broncode, documentatie, hosting en overdraagbaarheid.
Steeds meer MKB-bedrijven draaien op software die speciaal voor hen is gebouwd: een klantportaal, een planningssysteem, een koppeling tussen webshop en boekhouding of een volledig eigen ERP. Dat is logisch, want maatwerk sluit naadloos aan op je processen. Maar het brengt ook een vraag met zich mee die vaak pas wordt gesteld als het al te laat is: wat gebeurt er als de partij die je software bouwde er niet meer is?
Denk aan een freelancer die een vaste baan accepteert, een bureau dat failliet gaat, of simpelweg een samenwerking die niet meer werkt. Op dat moment wil je niet ontdekken dat je geen toegang hebt tot je eigen code, dat niemand weet hoe de server is ingericht, of dat de applicatie zo eigenzinnig is opgebouwd dat geen andere ontwikkelaar er nog aan durft te beginnen.
In dit artikel zetten we op een rij hoe je die afhankelijkheid beperkt, zonder dat je het vertrouwen in je huidige partner hoeft op te zeggen.
Leveranciersafhankelijkheid: wat is het precies?
Leveranciersafhankelijkheid (in het Engels vendor lock-in) betekent dat je zo sterk aan één leverancier vastzit dat overstappen erg duur, risicovol of praktisch onmogelijk is. Bij maatwerksoftware kan die afhankelijkheid op verschillende niveaus zitten:
- Eigendom: wie is juridisch eigenaar van de broncode en mag deze gebruiken en aanpassen?
- Toegang: heb jij de beschikking over de code, de database en de serveromgeving, of alleen de ontwikkelaar?
- Kennis: is de werking van het systeem vastgelegd, of zit alles in het hoofd van één persoon?
- Techniek: is de software gebouwd met gangbare, breed ondersteunde technologie, of met een obscuur of zelfgebouwd framework?
Afhankelijkheid is op zich niet erg, want iedere samenwerking brengt die met zich mee. Het wordt pas een risico als je geen alternatief hebt op het moment dat het nodig is.
1. Regel het eigendom van de broncode
Het begint bij heldere afspraken. Leg in je overeenkomst vast wie eigenaar wordt van de broncode, of in elk geval welke gebruiksrechten jij krijgt. Zonder expliciete afspraken blijven de auteursrechten op software in de regel bij de maker liggen. Dat betekent niet automatisch dat je er niets mee mag, maar het maakt een overstap wel ingewikkelder.
Er zijn verschillende smaken: volledige overdracht van het intellectueel eigendom, een eeuwigdurende en overdraagbare licentie, of een constructie waarbij generieke onderdelen bij de ontwikkelaar blijven en het maatwerk naar jou gaat. Welke vorm past, hangt af van je situatie. Laat je bij twijfel juridisch adviseren; het belangrijkste is dat het zwart op wit staat.
Een aanvulling die soms wordt gebruikt is software-escrow: de broncode wordt periodiek gedeponeerd bij een onafhankelijke partij en komt beschikbaar als de leverancier bijvoorbeeld failliet gaat. Dat is vooral interessant als je de code niet zelf in beheer krijgt.
2. Zorg dat je zelf toegang hebt
Eigendom op papier is mooi, maar in de praktijk gaat het om toegang. Controleer of je:
- beheerder of eigenaar bent van de code-repository (bijvoorbeeld op GitHub of GitLab), of daar op zijn minst leesrechten hebt;
- zelf de rekeningen en accounts bezit van hosting, domeinnamen, DNS en externe diensten (zoals mailservers, betaalproviders en API-koppelingen);
- toegang hebt tot back-ups van je database en weet waar die worden bewaard.
Een veelvoorkomend scenario: de domeinnaam of het hostingaccount staat op naam van de ontwikkelaar, "omdat dat makkelijker was". Dat werkt prima zolang de samenwerking goed loopt. Maar als het misgaat, kan het overzetten veel tijd kosten. Zet dit soort accounts daarom zo veel mogelijk op naam van je eigen organisatie en geef je ontwikkelaar daarop toegang, niet andersom.
3. Documentatie is geen luxe
Software die alleen te begrijpen is voor degene die hem schreef, is kwetsbaar. Goede documentatie hoeft geen dik boekwerk te zijn. Denk aan:
- een README die beschrijft hoe je de applicatie lokaal opstart en uitrolt;
- een overzicht van de architectuur: welke onderdelen er zijn en hoe ze met elkaar en met externe systemen communiceren;
- vastgelegde keuzes en afwegingen, zodat een opvolger begrijpt waarom iets op een bepaalde manier is gebouwd;
- een lijst van gebruikte externe diensten en waar de configuratie staat.
Daarnaast zijn geautomatiseerde tests een vorm van levende documentatie. Ze laten zien hoe het systeem hoort te werken en geven een nieuwe ontwikkelaar het vertrouwen om wijzigingen door te voeren zonder iets kapot te maken.
4. Kies voor gangbare technologie
De technologiekeuze bepaalt in grote mate hoe makkelijk je later een andere partij kunt inschakelen. Software gebouwd met een breed gebruikt en actief onderhouden framework, zoals Laravel in de PHP-wereld of React aan de frontend, heeft een grote community, veel beschikbare ontwikkelaars en uitgebreide documentatie. Een zelfgebouwd framework of een nichetaal kan technisch prima zijn, maar maakt je afhankelijker van een kleine groep mensen.
Let ook op onderhoud: houd frameworks en pakketten up-to-date. Software die jaren achterloopt is niet alleen een beveiligingsrisico, maar ook lastiger over te dragen, omdat een nieuwe partij eerst flink moet investeren in upgraden voordat er gewerkt kan worden.
5. Maak overdraagbaarheid onderdeel van de samenwerking
De beste manier om continuïteit te borgen, is er vanaf het begin open over te praten met je ontwikkelpartner. Een professionele partij zal daar niet moeilijk over doen, integendeel. Goede afspraken over eigendom, toegang en documentatie geven beide kanten duidelijkheid en dwingen tot kwaliteit.
Een paar vragen die je je (toekomstige) ontwikkelaar kunt stellen:
- Wie wordt eigenaar van de code en waar staat die?
- Op wiens naam staan hosting, domein en externe accounts?
- Hoe is de documentatie geregeld en hoe wordt die bijgehouden?
- Hoe worden updates en beveiligingspatches uitgevoerd?
- Wat gebeurt er als we in de toekomst afscheid van elkaar nemen?
Krijg je op deze vragen vage of ontwijkende antwoorden, dan is dat een signaal om door te vragen.
Afhankelijk zijn mag, overgeleverd zijn niet
Een langdurige samenwerking met een vaste ontwikkelpartner heeft veel voordelen: ze kennen je organisatie, je processen en je software door en door. Het doel is dus niet om afhankelijkheid volledig te vermijden, maar om ervoor te zorgen dat je nooit overgeleverd bent. Met heldere afspraken, eigen toegang, goede documentatie en gangbare technologie staat je software stevig, wat er ook gebeurt.
Twijfel je of jouw maatwerksoftware goed geborgd is? Bij CodeBros bouwen we software op een manier die overdraagbaar en toekomstbestendig is, en we kijken ook graag mee naar bestaande applicaties. Neem contact met ons op voor een vrijblijvende check van je huidige situatie.