Broncode is waard wat het een ander bespaart om hem te gebruiken in plaats van hem zelf te bouwen, min het risico dat die ander loopt. Voor de code van een bureau tellen vooral omvang, kwaliteit, tests, documentatie en de vraag of je de eigendom kunt aantonen.
Zonder aantoonbare eigendom is de waarde voor een koper bijna nul, hoe goed de code ook is. Aantonen doe je met arbeidsovereenkomsten, overdrachtsaktes van zzp’ers en klantcontracten. De bandbreedtes hieronder gelden voor code waarvan het bureau alle rechten heeft.
| Wat je hebt | Bandbreedte, EUR |
|---|---|
| Kleine repository, tot 10.000 regels | 200 - 1.500 |
| Middelgroot product, 10.000 tot 100.000 regels | 1.500 - 15.000 |
| Groot product met historie en tests | 15.000 - 100.000 |
Richtbedrag voor een niet-exclusieve licentie. De code blijft van jou. Gecontroleerd op 12 oktober 2026.
Dit zijn indicaties. De echte waarde van een repo kan buiten deze bandbreedtes vallen, naar boven en naar beneden.
Welke factoren bepalen de waarde van code?
- Eigendom. De eerste vraag van elke koper. Code van werknemers is van het bureau (artikel 7 Auteurswet). Code van zzp’ers alleen als die schriftelijk is overgedragen. Een gat in de keten verlaagt de prijs of stopt de deal. Zie wie is eigenaar van de code.
- Omvang en reikwijdte. Hoeveel functionaliteit zit erin, en hoe zelfstandig werkt het? Een module die je in een middag inbouwt, verkoopt makkelijker dan een monoliet die aan je infrastructuur vastzit.
- Kwaliteit en tests. Testdekking, een werkende CI-pipeline, een build die draait op een schone machine. Een koper die moet gokken of het werkt, betaalt minder.
- Documentatie. Een README, architectuurnotities, uitleg over deployment. Het verschil tussen ‘we kunnen dit morgen gebruiken’ en ‘we moeten eerst een maand uitzoeken wat dit doet’.
- Geschiedenis. Een commitgeschiedenis van jaren laat zien dat de code in productie heeft gedraaid en is bijgewerkt. Code die echt gebruikt is, heeft bugs al achter zich.
- Open source. Welke licenties zitten erin? Permissieve licenties zijn meestal geen probleem. Copyleft kan het gebruik door een koper beperken.
- Markt. Voor wie is dit nuttig? Een betalingskoppeling voor een niche of een planningsmodule voor een bepaalde branche heeft een duidelijke groep kopers. Hoe specifieker de toepassing en hoe groter de vraag, hoe beter.
Hoe reken je het uit?
Drie methoden, die je naast elkaar gebruikt.
| Methode | Vraag | Opmerking |
|---|---|---|
| Vervangingskosten | Wat kost het om dit opnieuw te bouwen? | De bouwkosten zijn het plafond van wat één koper betaalt |
| Opbrengst | Levert de code al inkomsten op, als product of via licenties? | Een koper rekent met die inkomsten over een paar jaar, met een korting voor risico |
| Markt | Wat brengen vergelijkbare repo’s of producten op? | De lastigste methode, omdat er weinig openbare prijzen zijn |
Waarom staat er nul op de balans?
Bij veel bureaus worden de uren voor eigen tools en producten direct als kosten geboekt. Op de balans staat dus niets. Dat zegt niets over de waarde in de markt.
Een bureau met tien jaar projecten heeft meestal:
- een plank vol interne tools;
- een paar stilgelegde producten;
- een componentbibliotheek;
- een aantal projecten waar het auteursrecht bij het bureau is gebleven.
Wat verhoogt de waarde voordat je verkoopt?
- Sluit de eigendomsketen. Overdrachtsaktes van zzp’ers alsnog regelen.
- Haal klantspecifieke delen eruit. Generieke code verkoopt aan meer partijen.
- Schrijf de README. Een middag werk, merkbaar verschil.
- Maak een licentieoverzicht. Elk open source pakket met zijn licentie.
- Ruim geheimen op. Sleutels en echte data uit de geschiedenis.
- Zorg dat de build werkt. Op een schone machine, met één commando.
Wat doe je met de waardering?
Met een waardering weet je of het loont om te verkopen of om in licentie te geven. En voor een bv met een S&O-verklaring kan de winst uit die deal onder de innovatiebox vallen.