Wat als de ontwikkelaar er niet meer is?

Waarom deze angst terecht is

Software op maat laten bouwen door één zelfstandige in plaats van een groot bureau voelt voor veel kmo’s als een risico. Dat is het ook, als het niet goed geregeld is. Eén persoon kan ziek worden, andere plannen maken, of gewoon niet meer bereikbaar zijn.

Bij een groot bureau lijkt dat risico kleiner, omdat er meerdere mensen zijn. Maar ook daar verdwijnt vaak net de ene persoon die uw project écht kende. Dan blijft u zitten met een team dat opnieuw moet inwerken, tegen een veel hoger uurtarief. Het achterliggende risico is dus niet uniek voor één zelfstandige. Wat wel bepaalt hoe erg het is: hoe afhankelijk bent u van die ene persoon om verder te kunnen?

Wat het risico echt beperkt

Of een vertrekkende ontwikkelaar een ramp wordt, of gewoon een vervelend ongemak, hangt af van vier zaken.

Eigendom van de broncode, niet enkel toegang tot een werkende toepassing. Staat de code in een repository op uw eigen account, niet enkel dat van de ontwikkelaar, dan kan een andere ontwikkelaar ze overnemen zonder eerst te moeten onderhandelen over toegang. Wat daar precies bij hoort te staan, leest u in van wie is de software die ik laat maken?

Hosting die u zelf beheert. Draait het hulpmiddel op een server, een cloudaccount of een platform op uw naam, niet op het persoonlijke account van de ontwikkelaar, dan blijft het gewoon draaien als die persoon wegvalt. Iemand anders kan er later ook gewoon bij.

Wachtwoorden en sleutels in uw bezit. Toegangsgegevens tot de hosting, de API’s (de technische verbindingen waarmee systemen met elkaar praten) en eventuele externe diensten horen bij u te liggen. Niet enkel bij de ontwikkelaar. Zonder die sleutels kan zelfs een nieuwe ontwikkelaar niets beginnen, ongeacht hoe goed de code zelf is.

Documentatie die uitlegt hoe alles samenhangt. Werkende code zonder uitleg is voor een buitenstaander veel trager te doorgronden. Een beknopte beschrijving van de opbouw, de belangrijkste keuzes en waar wat staat, scheelt veel tijd.

Wat containers en portabiliteit concreet betekenen

Een manier om die overdraagbaarheid technisch te versterken, is door software te bouwen in containers. Dat is een gestandaardiseerde verpakking die op vrijwel elke server of elk cloudplatform op dezelfde manier draait. Een nieuwe ontwikkelaar hoeft dan niet eerst uit te zoeken welke specifieke instellingen op de oorspronkelijke server stonden. Dat verkleint het verschil tussen “de ene persoon die het gebouwd heeft weet hoe het draait” en “eender welke ontwikkelaar kan het overnemen” aanzienlijk. Goede documentatie blijft daarnaast wel nodig: een container zonder uitleg is nog altijd een zwarte doos, alleen een beter verpakte.

Wat dit betekent bij Kufu, eerlijk gezegd

Dit is precies waarom hosting, broncode en wachtwoorden bij een traject bij Kufu bij u blijven, niet bij Kufu. Dat is geen extra dienst, het is het standaard uitgangspunt. Valt Kufu weg, om welke reden dan ook? Dan heeft u wat nodig is om een andere ontwikkelaar te laten overnemen: de code, de omgeving waarin ze draait, en de toegang ertoe. Dat maakt de overstap niet gratis of instant; een nieuwe ontwikkelaar moet zich nog altijd inwerken. Maar het is een dag of wat werk om opnieuw op gang te komen, niet een herstart van nul.

Dat is geen belofte dat er nooit iets misloopt als Kufu wegvalt — die belofte kan niemand eerlijk maken. Het is wel het verschil tussen “vervelend” en “onmogelijk”.

Wat u zelf kunt nagaan, bij Kufu of eender wie

Vraag expliciet: op wiens naam staat de hosting? Wie heeft de wachtwoorden? Staat de broncode ergens waar ik zelf bij kan, los van de ontwikkelaar? Is er documentatie die iemand anders zou kunnen volgen? Zijn die antwoorden onduidelijk? Dan is dat het moment om dat recht te zetten, voor er iets gebouwd wordt, niet nadat iemand al onbereikbaar is.

Wilt u dit voor uw eigen situatie concreet bekijken, dan is dat een van de dingen die tijdens een gratis kennismaking van een half uur mee op tafel komen.