Geen vendor lock-in: waarom jij eigenaar moet zijn van je software

Geen vendor lock-in: waarom jij eigenaar moet zijn van je software

ArtikelAlisina NawabiAlisina Nawabi29 april · 17:337 min leestijd

Software die je laat bouwen, hoort van jou te zijn. Niet half, niet zolang je blijft betalen, maar echt. Over dichtgetimmerde SaaS, bureaus die je gijzelen, en wat eigenaarschap concreet betekent.

Je hebt een mooi systeem laten bouwen. Een webshop, een portaal, een stuk automatisering, iets met AI. Het werkt, je bent tevreden. Tot je een jaar later iets wilt veranderen, en je ontdekt dat je nergens bij kunt. De broncode? Die staat bij het bureau. De data? Opgesloten in hun platform. De documentatie? Bestaat niet, of leeft in het hoofd van iemand die er niet meer werkt. En elke maand betaal je een bedrag dat verdacht veel lijkt op huur voor iets waarvan je dacht dat het van jou was.

Dit is geen pech. Dit is een verdienmodel. En mijn stelling is simpel: software die je laat bouwen, hoort van jou te zijn. Niet half, niet "zolang je blijft betalen", maar echt. De code, de data, de documentatie. Alles. Wie dat niet levert, verkoopt je geen oplossing maar een afhankelijkheid.

Het probleem: gegijzeld door je eigen systeem

Vendor lock-in is het netjes klinkende woord voor een minder nette praktijk: je zo bouwen dat je niet meer weg kunt. Het gebeurt zelden met opzet en met kwade bedoelingen. Vaker is het gewoon het pad van de minste weerstand voor de leverancier, en het meeste verdienen op de lange termijn.

Je herkent het aan een paar signalen. De broncode krijg je niet te zien, "dat is ons intellectueel eigendom". Je data zit in een gesloten platform en exporteren kan niet, of alleen als een onleesbare brij. Niemand bij jou snapt hoe het systeem in elkaar zit, dus voor elke wijziging, hoe klein ook, ben je terug bij dezelfde partij. En de prijs voor die wijzigingen? Die bepalen zij, want ze weten dat je geen kant op kunt.

Het venijn zit in de maandelijkse gijzeling. Je betaalt niet voor doorontwikkeling of echte waarde, je betaalt om de deur open te houden naar je eigen spullen. Stop je met betalen, dan stopt het systeem. Dat is geen abonnement. Dat is losgeld in termijnen.

En het ergste: het remt je af. Je durft niet meer te veranderen, want elke verandering kost geld en goodwill bij een partij die de macht heeft. Je software, die je vooruit zou helpen, wordt een rem.

Dichtgetimmerde SaaS is hetzelfde probleem in een ander jasje

"Maar ik koop toch gewoon een SaaS-tool, dan heb ik dit niet?" Soms klopt dat. Voor standaardwerk is een goede SaaS-oplossing vaak prima, en die hoef je niet zelf te bezitten. Een mailprogramma bouw je niet na.

Maar let op de dichtgetimmerde variant. Dat is de tool die precies genoeg kan om je binnen te krijgen, en net te weinig om je vrij te laten. Je data kun je er niet fatsoenlijk uit halen. Koppelen met je andere systemen mag alleen via hun dure "enterprise"-pakket. En de functie die jij nodig hebt, staat al twee jaar op de roadmap. Je past je bedrijf aan de tool aan, in plaats van andersom.

Het verschil tussen gezonde SaaS en een gouden kooi zit in één vraag: kun je weg als je wilt? Kun je je data meenemen, in een bruikbaar formaat, zonder toestemming te hoeven vragen? Kun je koppelen met wat je verder gebruikt? Is "nee" het antwoord, dan huur je geen tool. Dan ben je het product.

Wat eigenaarschap concreet betekent

Eigenaarschap is een groot woord dat vaak vaag blijft. Laat ik het concreet maken. Voor mij betekent het vier dingen, en ze zijn geen van alle onderhandelbaar.

1. De code is van jou. De volledige broncode staat in een repository waar jij toegang toe hebt en eigenaar van bent. Niet "inzage op verzoek", maar gewoon in jouw beheer, op jouw account. Wil je morgen een andere ontwikkelaar inhuren om verder te bouwen? Dan geef je die persoon toegang en klaar. Geen toestemming nodig, geen afkoopsom.

2. De data is van jou. Je gegevens staan in een standaard, open formaat dat jij kunt exporteren wanneer je maar wilt. Geen vendor-specifieke brij waar je niets mee kunt. Self-hosted waar het kan, zodat je data op jouw infrastructuur leeft en niet in andermans silo. Klantgegevens, bestellingen, content: het is van jou, en je kunt er altijd bij.

3. De documentatie bestaat. Hoe is het gebouwd, hoe draait het, hoe zet je het ergens anders neer, waar zitten de koppelingen? Dat staat opgeschreven, leesbaar, en hoort gewoon bij de oplevering. Documentatie is wat een systeem overdraagbaar maakt. Zonder documentatie ben je, ongeacht wie de code bezit, alsnog afhankelijk van het hoofd van één persoon.

4. Geen maandelijkse gijzeling. Je betaalt voor wat je krijgt: het bouwen, en eventueel onderhoud of doorontwikkeling als je dat wilt. Niet voor het recht om bij je eigen systeem te kunnen. Servers, domeinen en externe diensten hebben terechte lopende kosten, dat is normaal. Maar die staan op jouw naam, op jouw accounts. Stopt de samenwerking, dan blijft alles gewoon draaien. Niets valt om omdat ik de stekker eruit trek.

Het verschil tussen deze vier punten en de gangbare praktijk is het verschil tussen iets bezitten en iets huren zonder het te weten.

Hoe ik dat borg

Mooie principes zijn niets waard zonder uitvoering. Dus concreet: hoe zorg ik dat je echt eigenaar bent?

Ik bouw op open technologie en standaarden, niet op een gesloten platform waar ik je aan vastklik. De repository staat vanaf dag één op jouw account, of wordt aan het eind volledig naar jou overgedragen, met geschiedenis en al. Waar het kan, lever ik self-hosted op, op infrastructuur die op jouw naam staat. De inloggegevens van servers, domeinen en diensten zijn van jou, niet van mij.

Bij de oplevering hoort documentatie: hoe het draait, hoe je het deployt, waar de koppelingen zitten. Genoeg dat een andere ontwikkelaar het kan oppakken zonder mij te hoeven bellen. Want dat is de echte test van eigenaarschap, kun je verder zonder de bouwer? Bij mij is het antwoord ja, met opzet.

En de integraties bouw ik zo dat je data tussen je systemen kan stromen zonder dat je vastzit aan dure tussenlagen. Open koppelingen, geen tolpoortjes.

Dat ik solo werk, helpt hierbij. Er is geen accountmanager die je aan een contract bindt, geen verdienmodel dat draait op jouw afhankelijkheid. Mijn belang is dat het werkt en dat je tevreden terugkomt, niet dat je niet weg kunt. Met slim werken, loont hard werken: voor jou betekent slim werken dat je software je vooruit helpt in plaats van vast te houden.

De eerlijke conclusie

Stel jezelf één vraag over elk systeem dat je laat bouwen: als de relatie met de leverancier morgen eindigt, kan ik dan gewoon door? Heb ik de code, de data, de documentatie, de sleutels? Is het antwoord nee, dan bezit je je software niet. Je software bezit jou.

Eigenaarschap is geen bonus en geen premium-optie. Het is gewoon hoe het hoort. Je hebt betaald voor iets, dus het is van jou, met alles erop en eraan.

Veelgestelde vragen

Alisina Nawabi
Geschreven doorAlisina Nawabi

AI Product Engineer & Solutions Architect

Bij FLOH ontwerp en bouw ik complete software, integraties en AI op maat, van eerste idee tot werkend product, en jij blijft eigenaar. Hier schrijf ik nuchter over bouwen met AI en software voor ondernemers en organisaties.

Meer over mij

Gerelateerde artikelen

Digitale soevereiniteit is risicobeheer, geen politiekArtikel

Digitale soevereiniteit is risicobeheer, geen politiek

Soevereiniteit wordt gevoerd als een principekwestie over Amerika en Big Tech. Daardoor schuift de nuchtere ondernemer het weg. Onterecht: waar je data staat en van wie je software is, is gewoon een bedrijfsrisico.

Lees artikel
De verborgen TCO van je SaaS-stapelArtikel

De verborgen TCO van je SaaS-stapel

Elk SaaS-abonnement lijkt goedkoop. Maar bedrijven met 1 tot 500 medewerkers gebruiken gemiddeld 152 tools. Samen vreten ze marge, aandacht en controle over je data. Tel de stapel op.

Lees artikel
Waarom ik een PDF-tool bouwde die niets uploadtUpdate

Waarom ik een PDF-tool bouwde die niets uploadt

Bijna elke gratis PDF-tool stuurt je bestand naar een onbekende server. Voor een contract of paspoort voelt dat verkeerd. Daarom bouwde ik Pilatus Press: 24 PDF-tools die volledig in je browser draaien en je bestanden nooit uploaden.

Lees artikel
Waarom ‘even AI implementeren’ zelden het echte probleem oplostArtikel

Waarom ‘even AI implementeren’ zelden het echte probleem oplost

Iedereen wil iets met AI. Maar de winst zit zelden in het model, die zit in het proces, de data en de architectuur eromheen. En in eerlijk durven zeggen wat je juist niet met AI moet doen.

Lees artikel
Self-hosted vs. cloud: waarom ik vaak self-hosted bouwArtikel

Self-hosted vs. cloud: waarom ik vaak self-hosted bouw

De cloud regelt alles, maar stuurt elke maand een rekening en houdt je vast. Een eerlijke afweging van controle, kosten, privacy en onderhoud, en wanneer self-hosted wint en wanneer juist niet.

Lees artikel
Eén maker vs. een heel bureau: waarom solo soms sneller en beter isArtikel

Eén maker vs. een heel bureau: waarom solo soms sneller en beter is

Een bureau zet een heel team in, maar elke overdracht kost kwaliteit, tijd en afstand tot de bouwer. Waarom solo vaak sneller en beter levert, en hoe ik de grenzen ervan opvang.

Lees artikel