Wie een app laat ontwikkelen, gaat er vaak van uit dat betalen gelijkstaat aan bezitten. Toch zijn juridisch eigendom en technische en organisatorische zelfstandigheid twee verschillende dingen. Voor een bedrijfskritische app zijn ze allebei nodig. Pas dan heb je echt eigenaarschap over je app: je bepaalt zelf wie eraan werkt, wanneer er een update plaatsvindt en met welke partner je samenwerkt. Zo blijven continuïteit en overdraagbaarheid in jouw handen en voorkom je een vendor lock-in.
De vier verborgen risico’s van gebrekkig app-eigenaarschap
Tijdens de bouw zijn deze risico's meestal niet zichtbaar. Alles werkt, de releases worden gedaan en de samenwerking loopt voorspoedig. Ze komen pas boven zodra je wilt opschalen, doorontwikkelen of een app wilt overdragen aan een andere samenwerkingspartner.
1. Geen toegang tot je eigen app
Staat je app in het Apple Developer-account of de Google Play Console van het bureau, dan ben je geen eigenaar. Een app overzetten naar een ander account is mogelijk, maar alleen als het bureau meewerkt aan die app-transfer.
Daarnaast zijn er sleutels en toegangsgegevens die net zo belangrijk zijn als de code zelf:
Signing keys. Nieuwe Android-apps gebruiken Play App Signing, waarbij Google de app signing key beheert. Bij oudere Android-apps zonder Play App Signing is de keystore cruciaal: raak je die kwijt, dan kun je de app nooit meer updaten.
Hosting en API's. Draait de backend op een AWS (Amazon Web Services)- of GCP (Google Cloud Platform)-omgeving van het bureau, of staan API-keys en credentials alleen in hun beheer, dan is ook daar je toegang afhankelijk van een derde.
Gevolgen: je kunt zelf geen updates uitrollen, de app ligt direct stil bij een conflict of faillissement en je verliest waardevolle store-reviews, ratings en directe communicatie met je eindgebruikers.
2. Gedwongen herbouw door niet-overdraagbare code
Ook als de code wel van jou is, betekent dat nog niet dat een ander team ermee verder kan. Code die leunt op eigen frameworks van het bureau, of die niet volgens gangbare ontwerppatronen is gebouwd, is lastig over te dragen. Na een paar jaar bouwen zonder duidelijke structuur ontstaat al snel code die alleen de oorspronkelijke ontwikkelaars nog begrijpen.
Een tweede vorm van lock-in zit in de keuze van externe componenten. Een sterke afhankelijkheid van specifieke betaalde SDK's (software development kit) of platforms bindt je aan de licentievoorwaarden en prijzen van die leverancier.
Gevolgen: hoge kosten bij de overstap naar een nieuw team, stilstand in de doorontwikkeling en in het ergste geval een volledige herbouw.
3. Intellectual property (IP)-ownership: waarom betalen niet automatisch eigendom betekent
Volgens artikel 2 van de Auteurswet is voor de overdracht van auteursrecht een schriftelijke akte nodig. Zonder akte van overdracht heb je hooguit een gebruiksrecht op de software, geen eigendom van de broncode. Een betaalde factuur of een mondelinge afspraak is niet genoeg.
Zet het bureau freelancers in, dan speelt er nog iets. Het bureau kan alleen rechten overdragen die het zelf heeft. Zijn de rechten van die freelancers niet eerst schriftelijk aan het bureau overgedragen, dan is de rechtenketen niet sluitend.
Daarnaast zijn er twee aandachtspunten die vaak over het hoofd worden gezien:
Gevolgen: risico op juridische claims, minder waarde bij een overname of due diligence en verlies van exclusiviteit.
4. Afhankelijkheid van individuele developers (bus factor 1)
De bus factor is het aantal mensen dat uit een team kan wegvallen voordat een project stilvalt. Bij een bus factor van 1 zit alle kennis bij één ontwikkelaar. Dat gebeurt sneller dan je denkt, zeker als architectuurdocumentatie, CI/CD-pipelines en geautomatiseerde tests ontbreken. Releases, configuratie en ontwerpkeuzes zitten dan vooral in iemands hoofd, niet in het systeem.
Goede kennisborging maakt een app overdraagbaar. Een nieuwe ontwikkelaar kan dan op basis van documentatie, tests en een geautomatiseerd releaseproces snel en veilig aan de slag.
Gevolgen: vertrekt een sleutelfiguur, dan ligt de app stil. Nieuwe ontwikkelaars inwerken kost bovendien veel tijd en geld, omdat de onboarding-tijd fors oploopt.
