11 augustus 2026
Digitale soevereiniteit klinkt als een verhaal over cloudwetgeving en geopolitiek — iets voor overheden en grote technologiebedrijven. Maar de meest directe vorm ervan speelt zich elke dag af binnen uw eigen onderneming: in uw CRM, boekhouding, planning, productieomgeving of e-commerceplatform. Systemen waarop u steeds afhankelijker wordt, maar waarbij zelden vooraf de vraag wordt gesteld hoeveel controle u er werkelijk over heeft.
Het is geen toeval dat 'digitale soevereiniteit' vandaag zo vaak ter sprake komt. Een groot deel van de Europese cloudmarkt is in hands van Amerikaanse technologiebedrijven. Tegelijk zorgt wetgeving zoals de Amerikaanse CLOUD Act al jaren voor discussie over de vraag welke overheid onder welke omstandigheden toegang kan krijgen tot gegevens die door Amerikaanse bedrijven worden beheerd, zelfs wanneer die gegevens fysiek in Europa worden opgeslagen.
Europa probeert die afhankelijkheid ondertussen te verkleinen. Nieuwe initiatieven moeten Europese cloudinfrastructuur versterken en grote Europese technologie- en industriebedrijven zoeken steeds nadrukkelijker naar manieren om minder afhankelijk te worden van niet-Europese spelers.
Dat zijn belangrijke discussies. Maar ze gaan voornamelijk over infrastructuur, wetgeving en geopolitiek.
Voor een individueel bedrijf bestaat er een veel directere vorm van digitale soevereiniteit. En die hoeft niet te wachten op nieuwe Europese regelgeving.
De vraag is eenvoudig: wat gebeurt er met uw bedrijf wanneer uw softwareleverancier morgen stopt, wordt overgenomen of beslist om de spelregels te veranderen?
Dat is geen theoretisch scenario. Softwareproducten verdwijnen, abonnementen worden stopgezet, prijzen kunnen na een overname fors veranderen en leveranciers worden soms zelf gekocht door een bedrijf dat andere commerciële prioriteiten heeft.
Pas op zo'n moment wordt een vraag belangrijk die eigenlijk veel eerder gesteld had moeten worden: kan ik hier nog weg zonder mijn data, processen of bedrijfsvoering in gevaar te brengen?
Vertaald naar de software die uw onderneming dagelijks gebruikt, komt soevereiniteit in grote mate neer op drie vragen:
Toegang: Kan ik altijd bij mijn systeem en mijn gegevens, ook wanneer de leverancier stopt of de voorwaarden verandert?
Overdraagbaarheid: Kan ik mijn gegevens meenemen in een vorm waarmee ik werkelijk verder kan, of krijg ik alleen een exportbestand waar een andere toepassing nauwelijks iets mee kan?
Continuïteit: Kan iemand anders het systeem overnemen wanneer de huidige leverancier wegvallend, of wordt mijn onderneming op dat moment zelf onderdeel van het probleem?
Bij heel wat kant-en-klare software en SaaS-oplossingen blijkt het antwoord op minstens één van die vragen minder geruststellend dan bedrijven vooraf denken.
Een exportfunctie betekent bijvoorbeeld nog niet automatisch dat u gemakkelijk kunt vertrekken. Misschien krijgt u wel uw gegevens terug, maar niet de logica, relaties, workflows of configuraties die ervoor zorgen dat die gegevens binnen het systeem bruikbaar zijn. Ook contractuele voorwaarden kunnen bepalen hoe eenvoudig gegevens kunnen worden geëxporteerd, gemigreerd of opnieuw gebruikt.
En wanneer een leverancier stopt, wordt overgenomen of zijn commerciële strategie fundamenteel verandert, heeft een individuele klant meestal weinig invloed op wat daarna gebeurt.
In technologietermen spreken we dan vaak over vendor lock-in: een organisatie is zo afhankelijk geworden van één leverancier, technologie of platform dat veranderen bijzonder moeilijk, duur of risicovol wordt. Vendor lock-in is op zichzelf niet noodzakelijk verkeerd. Vrijwel iedere softwarekeuze creëert een vorm van afhankelijkheid.
De belangrijkere vraag is of u bewust weet waarvan u afhankelijk bent en wat uw uitweg is wanneer die afhankelijkheid ooit problematisch wordt.
Maatsoftware maakt een onderneming niet automatisch digitaal soeverein.
Slecht gebouwd maatwerk kan zelfs bijzonder grote afhankelijkheden creëren. Wanneer alleen de oorspronkelijke ontwikkelaar begrijpt hoe het systeem werkt, documentatie ontbreekt of de software gebouwd werd met sterk propriëtaire technologie, kan ook maatsoftware een vorm van vendor lock-in worden.
Maar goed opgezet maatwerk geeft een onderneming wel veel meer mogelijkheden om die afhankelijkheden vooraf bewust te organiseren. U kunt bijvoorbeeld duidelijke afspraken maken over:
Toegang tot uw gegevens en datamodel
De gebruikte technologie en architectuur
Hosting en infrastructuur
Documentatie en de broncode
Intellectuele eigendomsrechten
Overdracht naar een andere ontwikkelaar en ondersteuning wanneer de samenwerking ooit eindigt
De architectuur kan bovendien bewust worden gebouwd op open en gangbare technologie, zodat u niet vastzit aan één gesloten platform of één specifieke leverancier. En omdat u rechtstreeks samenwerkt met de partij die de toepassing bouwt, kunt u vooraf bespreken wat er gebeurt wanneer de samenwerking ooit stopt.
Dat gesprek krijgt u bij een wereldwijde SaaS-aanbieder zelden. Het fundamentele voordeel van maatwerk is daarom niet dat er geen afhankelijkheid meer bestaat. Het voordeel is dat u meer controle krijgt over de manier waarop die afhankelijkheid georganiseerd wordt.
Niet elk stukje software binnen een onderneming moet maatwerk zijn.
Voor boekhouding, e-mail, tekstverwerking of andere generieke toepassingen is bestaande software vaak veruit de verstandigste keuze. Een eigen boekhoudpakket bouwen alleen om onafhankelijk te zijn van een leverancier zou economisch weinig zin hebben.
Maar naarmate software dichter bij de kern van uw onderneming komt, verandert de afweging. Denk aan systemen waarin uw belangrijkste klantengegevens zitten, toepassingen die uw productie of logistiek aansturen, software waarin jarenlange bedrijfslogica werd opgebouwd of toepassingen die rechtstreeks bijdragen aan uw concurrentievoordeel.
Daar wordt de vraag naar digitale soevereiniteit plots veel relevanter. Niet omdat maatwerk ieder risico wegneemt, maar omdat het u de mogelijkheid geeft om vooraf afspraken te maken over precies de zaken die belangrijk worden wanneer er ooit iets fout loopt: toegang, overdraagbaarheid en continuïteit.
De echte vraag is daarom niet of uw onderneming afhankelijk is van een softwareleverancier. Dat bent u bijna altijd.
De echte vraag is: weet u vandaag al wat er gebeurt wanneer die afhankelijkheid morgen eindigt?
Of u nu kiest voor een standaardoplossing, SaaS of maatsoftware: stel deze vragen voordat u een systeem bedrijfskritisch maakt:
Gegevensexport: Kan ik al mijn gegevens op ieder moment exporteren in een formaat waarmee ik ook zonder de oorspronkelijke toepassing verder kan?
Voorwaarden: Wat staat er precies in de voorwaarden over toegang tot, verwerking van en overdracht van mijn gegevens?
Continuïteit: Wat gebeurt er met mijn toegang wanneer de leverancier stopt, wordt overgenomen of zijn prijzen of voorwaarden fundamenteel verandert?
Eigendom & documentatie: Wie beschikt over de broncode, technische documentatie, configuratie en het datamodel, en wie krijgt daar toegang toe wanneer de samenwerking eindigt?
Exitstrategie: Is er vandaag al iemand anders — intern of extern — die het systeem zou kunnen overnemen wanneer dat noodzakelijk wordt?
Misschien is dat uiteindelijk de eenvoudigste definitie van digitale soevereiniteit. Niet dat u nooit afhankelijk bent van een leverancier, wel dat u niet gevangen zit wanneer u ooit van leverancier moet veranderen.
Bij bedrijfskritische software hoort een exitstrategie daarom eigenlijk vanaf de eerste dag deel uit te maken van het ontwerp. Want de beste tijd om na te denken over hoe u een leverancier ooit kunt verlaten, is niet wanneer de samenwerking fout loopt. Het is wanneer ze begint.
AI-tools maken software bouwen makkelijker. Maar sneller bouwen is niet hetzelfde als beter bouwen. Over CRAPPS, lock-in, en waarom het gereedschap krachtiger wordt maar de vakkennis niet verdwijnt.
5 mei 2026
Mensen zeggen dat je bij hen moet werken. Wij lieten onze collega's gewoon praten. Geen script, geen corporate antwoorden — wel kakje-emoji-standpunten, een per ongeluk gebroadcastte privémeeting en twee mensen die ons bedrijf vergelijken met een hond én een koala. Samen geven ze het eerlijkste beeld van DMVH dat je ergens zult vinden.
2 april 2026
Veel softwareprojecten mislukken niet door slechte code, maar door te veel te bouwen voor je weet wat werkt. Een MVP — Minimum Viable Product — keert die logica om: eerst de essentie bouwen, dan leren van echte gebruikers, dan verder groeien. Geen compromis op kwaliteit, wel een slimmere manier om te starten.
19 maart 2026