Je maatwerksoftware is opgeleverd — en dan? Wie is eigenaar van wat

Na de oplevering van een webapplicatie beginnen de echte vragen pas: van wie is de code, wie beheert de server, en wat als je ooit wilt overstappen? Een nuchtere uitleg voor beslissers.

Een maatwerkapplicatie wordt opgeleverd, iedereen is tevreden, en dan verdwijnt het onderwerp uit je hoofd. Tot er anderhalf jaar later iets moet wijzigen, of je een offerte van een andere bouwer wilt opvragen, of de hostingfactuur ineens anders uitvalt. Dan komen de vragen: van wie is dit eigenlijk?

Het antwoord lijkt simpel — "van ons, we hebben ervoor betaald" — maar in de praktijk zitten er lagen in. Hieronder lopen we die lagen langs, zodat je vóór de start van een bouwtraject de goede dingen kunt afspreken, en niet achteraf ontdekt dat je ergens aan vastzit.

Vier dingen die allemaal "eigendom" heten

Bij een maatwerkoplossing zijn er grofweg vier zaken waar het eigenaarschap van geregeld moet worden. Ze lopen vaak door elkaar in gesprekken, en dat is precies waar misverstanden ontstaan.

1. De data. Alle informatie die in de applicatie zit: klanten, orders, documenten, logs.
2. De broncode. De bouwstenen waarmee de applicatie draait.
3. De omgeving. De server, database en domeinnaam waarop het geheel leeft.
4. De kennis. Wie weet hoe het in elkaar zit en hoe je het aanpast.

Een gezonde afspraak regelt alle vier. Veel standaardcontracten regelen alleen de eerste.

Je data: altijd van jou, maar kun je er ook bij?

Dat de data van jou is, is zelden het probleem. Het probleem is of je er los van de applicatie bij kunt. Als je morgen zou willen overstappen naar een ander systeem, kun je dan je volledige klantenbestand, je facturen, je bijlagen en je historie exporteren in een leesbaar formaat?

Vraag voor oplevering twee dingen:

• Een exportfunctie, of in elk geval een gedocumenteerde manier om een volledige database-dump te krijgen in een open formaat (CSV, JSON, SQL).
• Toegang tot je bijlagen en bestanden buiten de applicatie om. Als je PDF's en foto's alleen door de applicatie heen te benaderen zijn, zit je vast zodra die applicatie niet meer draait.

Dit is geen wantrouwen, dit is gezond huishoudboekje. Zet het in het contract als recht, niet als gunst.

De broncode: van wie is die, en wat mag je ermee?

Hier wordt het ingewikkelder. Er zijn drie veelvoorkomende varianten:

• De bouwer houdt de code, jij hebt gebruiksrecht. Je betaalt voor het gebruik; je mag niet zomaar een andere partij de code laten uitbreiden. Vaak gecombineerd met een abonnement.
• De code is van jou, maar wordt beheerd door de bouwer. Je bent eigenaar, maar in de praktijk heb je de code zelf nooit in handen. Bij ruzie of faillissement: zie je het ooit terug?
• De code staat in een repository waar jij óók bij kunt. Je hebt lees- en downloadrechten op de werkelijke broncode. Je kunt op elk moment een andere partij vragen ernaar te kijken.

De derde variant is het meest eerlijk. Een bouwer die dit niet wil, zegt daarmee iets. Niet per se iets slechts — er zijn goede redenen om code als product te verkopen — maar wees je ervan bewust wat je kiest. Lees ook ons stuk over wat een maatwerkwebapplicatie laten bouwen inhoudt, waar we dit onderwerp uitgebreider aanraken.

Een broncode-escrow: nodig of overdreven?

Bij grotere trajecten kom je het begrip broncode-escrow tegen: een derde partij bewaart de code en geeft die vrij als de bouwer bijvoorbeeld failliet gaat. Voor de meeste MKB-trajecten is dat zware kost. Een werkbaar alternatief is dat je gewoon toegang hebt tot de repository (bijvoorbeeld een eigen account op GitLab of GitHub), zodat je bij een probleem direct een kopie hebt.

De omgeving: waar draait het, en op wiens naam?

De applicatie draait ergens. Dat is een server bij een hostingpartij, een database, en meestal een domeinnaam. Check vóór oplevering:

• Op wiens naam staat het hosting-account? Als het op naam van de bouwer staat, ben je afhankelijk. Op jouw naam, met de bouwer als beheerder: beter.
• Op wiens naam staat de domeinnaam? Dit zou altijd op jouw bedrijfsnaam moeten staan, met jouw contactgegevens als houder.
• Wie heeft de SSL-certificaten in beheer? En wat gebeurt er als die verlopen?
• Waar staan de back-ups, hoe vaak worden ze gemaakt, en kun jij er zelf bij als het moet?

Dit zijn geen technische details om "later een keer op te pakken". Als een bouwer wegvalt en de domeinnaam staat op zijn naam, kun je weken bezig zijn om die weer in handen te krijgen.

De kennis: documentatie als overdraagbaar bezit

Een applicatie zonder documentatie is alleen bruikbaar zolang de mensen die hem bouwden nog bereikbaar zijn. Dat is een risico dat je bijna niet voelt — tot het acuut wordt.

Vraag bij oplevering om een minimale set documentatie:

• Een technische beschrijving: welke frameworks, welke database, welke externe diensten gebruikt de applicatie?
• Een beschrijving van de koppelingen: welke API's praten met welke systemen, met welke credentials, en wat gebeurt er bij storingen?
• Een opstart-instructie: hoe krijg je de applicatie draaiend op een nieuwe server?
• Een lijst met accounts en toegangen die bij de applicatie horen (zonder wachtwoorden, maar wel welke accounts er bestaan en waarvoor ze dienen).

Deze set hoeft geen boekwerk te zijn. Een beknopt document van tien pagina's is al goud waard als je ooit moet overstappen of uitbreiden.

Wat als je het niet geregeld hebt?

Als je dit stuk leest met een applicatie die al in gebruik is en je weet eigenlijk niet hoe het zit: dat is geen ramp, maar wel een goed moment om het alsnog op orde te brengen. Een rustig gesprek met je huidige bouwer, zonder dreigende onderstroom, levert meestal gewoon de antwoorden op. Een bouwer die er moeilijk over doet, geeft je waardevolle informatie — over de bouwer.

Noteer per punt: wat is nu geregeld, wat niet, en wat willen we binnen een jaar anders? Dat is genoeg om bij een volgende wijzigingsronde of contractverlenging stapsgewijs recht te zetten wat nog ontbreekt.

De korte checklist voor vóór je tekent

• Data: exporteerbaar in open formaat, bijlagen apart benaderbaar.
• Broncode: wie is juridisch eigenaar, en krijg jij leestoegang tot de repository?
• Hosting en domein: op jouw naam, met de bouwer als beheerder.
• Back-ups: frequentie, bewaartermijn, en of je zelf een kopie kunt krijgen.
• Documentatie: wat wordt opgeleverd, en in welke vorm?
• Exit-afspraak: wat gebeurt er als een van beide partijen stopt?

Deze zes punten passen op een A4-tje. Ze veranderen de prijs van een traject nauwelijks, maar ze bepalen hoe vrij je over drie jaar nog bent.

Overweeg je een maatwerktraject en wil je over dit soort afspraken van tevoren eerlijk doorpraten — ook als wij uiteindelijk niet de bouwer worden? Op onze pagina over maatwerk laten bouwen staat hoe wij een traject aanvliegen. En als je gewoon even wilt sparren over een lopende situatie: neem contact op.