10 juni 2026

Reverse engineering, bouw een compleet softwarepakket na in een dag

Een paar weken geleden zat ik bij een organisatie die al jaren met hetzelfde planningspakket werkt. Niemand was er tevreden over. De licentie was net weer duurder geworden, de leverancier bouwde al tijden niets nieuws meer, en elke wijziging in het proces moest om de software heen worden georganiseerd in plaats van andersom. Toen ik vroeg waarom ze niet overstapten, kwam het bekende antwoord: te duur, te eng, te veel werk.

Die avond deed ik een experiment. Ik opende het pakket, klikte een uur lang door alle schermen, en beschreef aan een coding agent wat ik zag. Welke velden, welke knoppen, welke stappen in welke volgorde. Daarna liet ik het datamodel afleiden uit die beschrijvingen en de belangrijkste flows nabouwen. Aan het eind van de dag had ik een werkende versie van de kernfunctionaliteit. Geen kopie van hun code, geen toegang tot hun database, gewoon: kijken wat de software dóet en dat opnieuw laten bouwen.

Was het af? Nee, daar kom ik op terug. Maar het feit dat dit kan, in een dag, door één persoon, zegt iets fundamenteels over waar de waarde van software tegenwoordig zit. En vooral over waar die niet meer zit.

Wat er technisch gebeurt

Reverse engineering klinkt als hacken, maar wat ik hier beschrijf is veel saaier. Je kijkt naar de buitenkant van een applicatie en reconstrueert wat erachter moet zitten.

Het werkt in drie stappen.

Eerst beschrijf je de schermen. Niet de pixels, maar de functie: dit scherm toont een lijst van afspraken, gefilterd op locatie en medewerker, met deze kolommen en deze acties. Dat is informatie die elke gebruiker gewoon kan zien. Vroeger schreef een analist daar wekenlang functionele specificaties over. Nu dicteer je het in een uur aan een model, dat er direct gestructureerde specificaties van maakt.

Daarna leid je het datamodel af. Hier zijn taalmodellen verrassend sterk in. Als een scherm een afspraak toont met een klant, een medewerker, een locatie en een status, dan kun je daaruit afleiden welke tabellen en relaties er onder moeten liggen. Het model stelt zelfs de vragen die een goede databaseontwerper zou stellen: kan een afspraak meerdere medewerkers hebben, wat gebeurt er bij een annulering, is een locatie verplicht. Tachtig procent van de bedrijfssoftware die ik tegenkom heeft een datamodel dat je op deze manier in een middag boven water hebt.

Tot slot herbouw je de flows. Een nieuwe afspraak aanmaken, een conflict signaleren, een bevestiging versturen. Dit is het deel dat vroeger maanden kostte en nu uren, omdat het overgrote deel van die flows patroonwerk is: formulieren, validaties, statusovergangen, notificaties. Precies het werk waar coding agents goed in zijn.

Het resultaat is geen kloon van de oorspronkelijke code. Het is nieuwe software die hetzelfde probleem oplost, gebouwd op basis van wat je aan de buitenkant kunt waarnemen.

Even precies over intellectueel eigendom

Hier hoort een eerlijke kanttekening bij. Code kopiëren, decompileren of een database leegtrekken is iets heel anders dan wat ik beschrijf, en daar moet je gewoon vanaf blijven. Ook het een op een namaken en commercieel aanbieden van andermans product is een gebied waar je juridisch advies bij wilt, want naast auteursrecht spelen ook databankenrecht en contractvoorwaarden mee.

Waar ik het over heb is het nabouwen van functionaliteit voor eigen gebruik of als prototype: begrijpen wat een pakket voor jouw organisatie doet en dat zelf opnieuw bouwen. Functionaliteit en ideeën zijn in de basis niet beschermd zoals broncode dat is, maar dit is geen juridisch advies, wel een technische realiteit. Check bij twijfel je licentievoorwaarden en vraag het na. De rest van dit verhaal gaat over die eigen-gebruik-variant.

Waarom dit nu uitmaakt

Decennialang was de redenering van softwareleveranciers simpel: dit pakket kostte ons jaren ontwikkeltijd, dus het is logisch dat je er flink voor betaalt en dat overstappen bijna onmogelijk is. Die redenering rustte op één aanname: software bouwen is duur.

Die aanname klopt steeds minder. Als de functionaliteit van een gemiddeld bedrijfspakket in dagen in plaats van jaren na te bouwen is, dan zit de waarde van dat pakket blijkbaar niet in de code. Waar dan wel?

In de data. Jouw tien jaar aan klanthistorie, afspraken en dossiers in dat pakket zijn waardevol. De schermen eromheen niet.

In de integraties. Het pakket dat met je boekhouding, je DigiD-koppeling of je bankomgeving praat, heeft iets dat een prototype van een dag niet heeft. Koppelingen zijn vaak meer werk dan het pakket zelf.

In vertrouwen en distributie. Een leverancier met duizend klanten, een supportafdeling en een trackrecord verkoopt iets anders dan code. Die verkoopt de zekerheid dat het morgen ook nog werkt en dat er iemand opneemt als het misgaat.

In onderhoud. Software is geen project maar een abonnement op werk: security-updates, gewijzigde wetgeving, browsers die veranderen, klanten die bellen. De bouwkosten zijn een eenmalig bedrag, het onderhoud is de eeuwigdurende rekening.

Dat is de echte verschuiving: de code zelf is van schaars goed veranderd in iets dat je kunt reproduceren. Alles eromheen niet.

Wat dit betekent voor SaaS-prijzen en lock-in

Voor organisaties die jarenlang aan een pakket vastzaten, verandert hierdoor de onderhandelingspositie, en dat is misschien wel het meest praktische gevolg.

Neem die organisatie met het planningspakket. Het prototype van die ene dag was geen vervanging, maar het was wel iets anders: bewijs. Bewijs dat de functionaliteit waar ze jaarlijks een fors bedrag voor betalen geen magie is. Dat verandert het gesprek met de leverancier. Niet als dreigement, maar als realistische optie op tafel. Een leverancier die weet dat zijn klant kan vertrekken, gedraagt zich anders dan een leverancier die weet dat zijn klant gevangen zit.

Ik verwacht dat SaaS-prijzen hierdoor de komende jaren onder druk komen te staan, vooral in het middensegment: de pakketten die functioneel niet bijzonder zijn maar wel bijzonder geprijsd, omdat overstappen altijd te duur was. Leveranciers die hun prijs alleen konden verdedigen met "het is veel werk om dit na te bouwen" raken dat argument kwijt. Leveranciers die hun prijs verdedigen met data, integraties, betrouwbaarheid en service houden juist een sterker verhaal over.

En voor interne tooling geldt iets soortgelijks. Het pakket van vijftig euro per gebruiker per maand waarvan je twee schermen gebruikt? Dat is precies de categorie waar zelf bouwen ineens een serieuze optie is. Niet altijd de beste optie, maar wel een optie, en dat alleen al is nieuw.

De eerlijke grens: een demo is geen productie

Nu het deel dat in de enthousiaste verhalen meestal ontbreekt, want ik wil niet doen alsof die dag bouwen het hele verhaal is.

Wat ik in een dag nabouwde was de kernfunctionaliteit: de schermen, het datamodel, de belangrijkste flows. Wat ik niet had: tien jaar aan randgevallen. Het oorspronkelijke pakket weet wat er moet gebeuren als een afspraak over een jaarwisseling heen loopt, als twee gebruikers tegelijk hetzelfde record bewerken, als de import een half corrupt bestand binnenkrijgt. Die kennis zit niet in de schermen, die zit in jaren aan bugfixes, en die bouw je niet na door naar de buitenkant te kijken.

Ik had ook geen migratie. De bestaande data uit het oude pakket halen, schoonmaken en betrouwbaar overzetten is vaak meer werk dan de nieuwe software zelf. Geen rechtenmodel dat tegen een audit kan. Geen backups, geen monitoring, geen logging, geen beheerplan, geen antwoord op de vraag wie het onderhoudt als de bouwer iets anders gaat doen.

De demo is makkelijk. Productie is waar software serieus wordt. Mijn vuistregel uit de praktijk: het prototype is tien tot twintig procent van het echte werk. Dat is nog steeds spectaculair, want vroeger was dat prototype zelf al maanden werk. Maar wie op basis van een geslaagde demo-dag zijn licentie opzegt, gaat een pijnlijk jaar tegemoet.

Een denkmodel voor wie dit overweegt

Als je overweegt om een pakket na te bouwen, of dit als drukmiddel wilt gebruiken, loop dan deze vragen langs:

• Mag het? Check je contract en licentievoorwaarden, en houd het bij functionaliteit voor eigen gebruik, niet bij code of data van de leverancier.
• Waar zit de echte waarde van het huidige pakket: in de schermen, in de data, in de integraties of in de zekerheid van de leverancier?
• Hoe komt je bestaande data eruit, en in welke staat? Geen export, dan is dat je echte lock-in, niet de software.
• Wie gaat het onderhouden, en is dat realistisch over drie jaar?
• Welke randgevallen kent het oude pakket die jij nog niet kent? Vraag het de mensen die er dagelijks mee werken.
• Is een prototype als onderhandelingsmiddel misschien waardevoller dan een daadwerkelijke overstap?

Die laatste vraag wordt vaak overgeslagen. Soms is het beste resultaat van een nabouwdag niet nieuwe software, maar een beter contract met je bestaande leverancier.

Conclusie

Dat je een softwarepakket in een dag kunt nabouwen, betekent niet dat alle software waardeloos is geworden. Het betekent dat de waarde verhuisd is: van de code naar de data, de integraties, het vertrouwen en het onderhoud. Voor leveranciers is dat ongemakkelijk nieuws als hun prijs vooral op bouwkosten van vroeger rustte. Voor organisaties die zich jaren gevangen voelden in een pakket is het bevrijdend nieuws: de muren van die gevangenis blijken een stuk lager dan het contract suggereerde.

De code was nooit het punt. Dat zien we nu pas goed, omdat de code het enige deel was dat moeilijk leek.

↘︎ ALLE ARTIKELEN