Afhankelijk van één ontwikkelaar: zo maak je je software toekomstvast

Veel bedrijven zijn voor hun belangrijkste software afhankelijk van één ontwikkelaar. Iemand die het systeem ooit heeft gebouwd, het als enige begrijpt en het al jaren bijhoudt. Zolang die persoon beschikbaar is, gaat het goed. Maar ontwikkelaars stoppen, worden ziek, verhuizen of krijgen andere prioriteiten. In dit artikel lees je hoe je het risico inschat, wat je in elk geval in handen moet hebben en hoe je je software toekomstvast maakt.

Een van de manieren om die afhankelijkheid op te heffen is slim software nabouwen: het systeem opnieuw bouwen op gangbare techniek, met code en documentatie die van jou zijn.

Waarom is het een risico om afhankelijk van één ontwikkelaar te zijn?

Afhankelijk zijn van één ontwikkelaar is een risico omdat de continuïteit van je bedrijf dan aan één persoon hangt. Als het systeem stilvalt en die persoon niet bereikbaar is, kan niemand het oplossen. Ook zonder storing merk je de afhankelijkheid:

• aanpassingen duren lang, omdat ze moeten wachten op de beschikbaarheid van één persoon;
• je kunt moeilijk inschatten of tijd en prijs redelijk zijn, omdat er geen vergelijking is;
• nieuwe wensen worden uitgesteld, omdat de ontwikkelaar er geen ruimte voor heeft;
• de techniek veroudert, omdat er geen tijd of interesse is om bij te blijven.

Dat ligt meestal niet aan de ontwikkelaar. Het is een gevolg van hoe de situatie is gegroeid.

Hoe weet je hoe afhankelijk je bent?

Je weet hoe afhankelijk je bent door te kijken wat er gebeurt als die ene persoon morgen niet meer beschikbaar is. Stel jezelf deze vragen:

• Hebben wij zelf toegang tot de broncode, en is die actueel?
• Weten wij waar het systeem draait en hebben wij de inloggegevens van server, hosting en database?
• Staan domein, accounts en licenties op naam van ons bedrijf?
• Is er documentatie die een andere ontwikkelaar kan gebruiken?
• Is de techniek gangbaar genoeg om iemand anders te vinden die ermee kan werken?
• Zijn er back-ups en weten we hoe we die terugzetten?

Is het antwoord op meerdere vragen nee of weet ik niet, dan ben je in hoge mate afhankelijk.

Wat moet je in elk geval in handen hebben?

Zorg dat je in elk geval de broncode, de toegang en de data in eigen beheer hebt. Concreet:

• Broncode in een repository op naam van je bedrijf, waar de ontwikkelaar toegang toe heeft, niet andersom.
• Toegang tot hosting, server en database via een account van je bedrijf, met de ontwikkelaar als gebruiker.
• Domeinnamen, licenties en abonnementen op naam van je bedrijf.
• Een recente back-up van de data die je zelf kunt bereiken.
• Afspraken over eigendom van de code, vastgelegd in een contract.

Dit is geen wantrouwen, maar normaal beheer. Een goede ontwikkelaar werkt daar graag aan mee. Wat juridisch meespeelt bij eigendom en code, lees je in mag je bestaande software laten nabouwen.

Hoe maak je bestaande software overdraagbaar?

Je maakt bestaande software overdraagbaar door kennis vast te leggen en een tweede partij in te werken. Dat kan stap voor stap.

Code en toegang centraliseren

Zet de broncode in een repository van je bedrijf en breng alle accounts onder bij je organisatie. Dat is de eerste en belangrijkste stap.

Documentatie laten maken

Laat de ontwikkelaar beschrijven hoe het systeem is opgebouwd, waar het draait, hoe je een update uitrolt en welke onderdelen kwetsbaar zijn. Een paar pagina's is vaak al genoeg om iemand anders op weg te helpen.

Een tweede partij inwerken

Laat een tweede ontwikkelaar of bureau meekijken en kleine aanpassingen doen. Zo ontdek je snel wat er ontbreekt aan documentatie en ontstaat er een alternatief.

Onderhoud structureel regelen

Spreek af hoe updates, beveiliging en back-ups geregeld zijn, en door wie. Dat kan bij de huidige ontwikkelaar blijven, zolang het vastligt en controleerbaar is. Meer over structureel beheer lees je bij onderhoud en beveiliging.

Wanneer is nabouwen de betere route?

Nabouwen is de betere route als de software zo verouderd of zo eigenzinnig is gebouwd dat overdragen nauwelijks kan. Dat zie je als:

• de techniek niet meer wordt ondersteund of bijna niemand er nog mee werkt;
• er geen of geen actuele broncode is;
• de ontwikkelaar binnenkort stopt en geen tijd heeft voor een overdracht;
• elke aanpassing risico geeft op fouten elders in het systeem.

Bij een nabouw leggen we vast wat het systeem doet en bouwen we het opnieuw op gangbare techniek, met code en documentatie die van jou zijn. Hoe dat werkt, lees je in slim software nabouwen.

Hoe voorkom je afhankelijkheid bij nieuwe software?

Je voorkomt afhankelijkheid door er vanaf de start afspraken over te maken. Let bij nieuwe software op:

• Gangbare techniek. Kies voor platforms en talen waar veel ontwikkelaars mee werken. Wij bouwen bijvoorbeeld met Next.js en een backend op Supabase of Xano. Welke backend past, lees je in Supabase of Xano.
• Eigendom. Leg vast dat code, ontwerp en documentatie van jou zijn.
• Accounts op jouw naam. Vanaf dag één, niet pas als er een probleem is.
• Documentatie als onderdeel van de oplevering. Niet als extra, maar als vast onderdeel van het project.
• Exporteerbare data. Je gegevens moeten altijd in een standaardformaat te exporteren zijn.

Hoe helpen wij als je afhankelijk bent van één ontwikkelaar?

We beginnen met een korte scan: waar staat de code, wie heeft toegang, hoe actueel is de techniek en wat is er gedocumenteerd. Daarna adviseren we of overdragen of slim nabouwen de beste route is. In beide gevallen zorgen we dat code, data en documentatie van jou zijn, zodat je niet opnieuw afhankelijk wordt, ook niet van ons.

Herken je je in deze situatie? Neem contact op, dan kijken we samen naar de risico's en de mogelijke stappen.