App laten ontwikkelen: freelancer of bureau, kosten en contract

U hebt een idee voor een product, en misschien al klanten die erop wachten. U hebt iemand nodig die het bouwt. Een werknemer aannemen betekent een salaris, werkgeverslasten en een opzegtermijn op de dag dat u uit elkaar gaat. Dus denkt u aan een zelfstandige developer, een freelancer uit uw netwerk of van een platform dat opdrachtgevers en freelancers bij elkaar brengt, of aan een softwarebureau, een bedrijf dat software bouwt voor anderen.

Vergelijk de contracten die ze aanbieden, voordat u developers of bureaus met elkaar vergelijkt. Het contract bepaalt wie betaalt als uw behoefte verandert, wanneer uw gebruikers het product in handen krijgen, van wie de code is en hoe u kunt vertrekken. De accounts waarop uw applicatie draait, en wat er gebeurt op de dag dat degene die de code kent niet meer beschikbaar is, regelt u ook vóór de eerste werkdag.

Wat een freelance developer u biedt

Hij bouwt wat u hem toevertrouwt: een webapplicatie, een mobiele app, een functionaliteit in bestaande software. Vaak kiest hij ook de technologieën.

U betaalt niet wat een werknemer naast zijn salaris kost: geen werkgeverslasten, geen doorbetaalde vakantiedagen, geen loondoorbetaling bij ziekte en geen honorarium aan een wervingsbureau. En u werkt rechtstreeks samen met degene die uw software bouwt, zonder tussenpersoon.

U kiest ook een developer die gespecialiseerd is in het technische onderdeel dat uw product nodig heeft: een mobiele app, een systeem voor online betalen, een koppeling met andere software. U hoeft geen generalist fulltime in dienst te nemen. En hij kan meteen beginnen, terwijl een kandidaat die al een baan heeft eerst moet opzeggen en bij zijn huidige werkgever zijn opzegtermijn moet uitdienen voordat hij bij u kan beginnen.

Hij wordt betaald voor zijn werk, of uw product nu klanten vindt of niet. Een technische medeoprichter die in aandelen wordt betaald verbindt zijn toekomst juist aan die van uw bedrijf.

Wat een softwarebureau u biedt, en wat het niet vervangt

Een bureau bouwt wat nog niet bestaat: een website, een mobiele app, software op maat. U hoeft geen functie te creëren en geen proeftijd af te wachten. U tekent een contract met een bedrijf, en de ontwikkeling begint.

Als een werknemer, een medeoprichter of een freelance developer de software alleen schrijft, zit de kennis ervan bij één persoon. Een bureau kan uw product aan meerdere developers toevertrouwen, en wie vertrekt vervangen. Dat gebeurt niet altijd: vraag hoeveel mensen uw code zullen kennen.

Wat kost een app laten ontwikkelen: drie manieren van betalen

Een freelance developer of een bureau rekent meestal op twee manieren af. Per dag heet dat regie: u betaalt de bestede tijd, tegen het afgesproken dagtarief. Per project is het een vaste prijs met vaste scope: één prijs voor een lijst met functionaliteiten die bij ondertekening is beschreven.

Er is een derde manier van betalen, die niet op een schatting steunt. Bij een vaste prijs met vast budget en flexibele scope liggen de prijs en het op te lossen probleem vast. Flexibel blijft de manier waarop dat probleem wordt opgelost: de functionaliteiten die worden ontwikkeld.

Uw behoefte zal onderweg veranderen: uw eerste gebruikers laten u zien wat er ontbreekt en wat overbodig is. Elk van deze contracten geeft een ander antwoord op één vraag: wie betaalt die verandering?

Bij een vaste prijs met vaste scope draagt de leverancier de schattingsfout op de getekende lijst. De klant draagt de veranderende behoefte, meerwerk na meerwerk. Bij regie draagt de klant allebei. Een wijziging vraagt geen contractwijziging, maar elke extra dag komt op de factuur.

De verschillen kunnen fors zijn. Bij 4.677 IT-projecten bedragen de werkelijke kosten gemiddeld 1,8 keer de geschatte kosten, oftewel 80% meer, volgens een studie uit 2022 van Bent Flyvbjerg, hoogleraar aan de Universiteit van Oxford, en zijn coauteurs. Dat gemiddelde wordt omhooggetrokken door een minderheid van projecten met extreme overschrijdingen: in dezelfde steekproef ligt de mediane overschrijding dicht bij nul. Maar niemand weet bij ondertekening aan welke kant zijn project zal uitkomen.

Bij een vaste prijs met vast budget en flexibele scope wordt geen lijst met functionaliteiten getekend: een wijziging kost geen meerwerk en geen extra dag. Het budget blijft gelijk als de behoefte verandert; de functionaliteiten die worden ontwikkeld, passen zich aan. Daar staat tegenover dat dit model tijd van u vraagt. U beslist wat de meeste waarde heeft voor uw gebruikers, en u stelt de prioriteiten bij als uw markt verandert. Kunt u daar geen tijd in steken, dan past dit contract slecht bij u.

Een vaste prijs met vaste scope blijft geschikt voor een behoefte die niet verandert. Een product dat nog zijn klanten zoekt, valt daar niet onder. De prijs en de planning komen bij een vaste prijs en bij regie op verschillende manieren tot stand.

De kosten van software op maat hangen af van de tijd die u besluit te investeren in de ontwikkeling ervan en in de dagelijkse aanpassingen om uw bedrijf bij te houden, afgezet tegen wat het ontbreken ervan u kost.

Stel uw leverancier vóór ondertekening deze vraag: als mijn behoefte verandert, wat verandert er dan aan wat ik betaal?

Wat het contract zegt over veranderingen

Voor een startup weegt een vaste prijs met vaste scope vanaf de eerste maanden. Uw eerste gebruikers laten u zien wat ze missen, en wat ze niet gebruiken. Elke wijziging van de getekende lijst wordt meerwerk, apart begroot, dat u betaalt.

In Frankrijk wees in 2020 de rechtbank van koophandel van Parijs de terugbetalingsvordering af van een jong bedrijf dat twee mobiele apps en een website had laten ontwikkelen, zonder programma van eisen, volgens een agile methode. Het bedrijf was van leverancier gewisseld, en eiste de bedragen terug die het aan de eerste had betaald. Volgens Le Monde Informatique stelde de rechtbank vast dat de agile methode “leidt tot veel heen-en-weer tussen de partijen”, en dat de aangevoerde problemen “niet abnormaal zijn”.

Naar ons idee beschermen twee dingen u dan: doorlopend zien dat de software in handen van uw gebruikers is, en het contract kunnen beëindigen zodra het u niet meer bevalt.

Wat u krijgt, en wanneer

In Frankrijk beschrijft een praktische handleiding over de ontwikkeling van een mobiele app, in 2015 gepubliceerd door Syntec Numérique (nu Numeum, de branchevereniging van IT-bedrijven) en het advocatenkantoor Staub & Associés, ook het verloop van een ontwikkeling tegen een vaste prijs. De leverancier maakt eerst een mock-up van de applicatie, het storyboard, met daarin “de gedetailleerde functionele specificaties”. Hij zorgt dat de klant die accepteert “voordat de ontwikkelwerkzaamheden beginnen”.

Daarna volgen de ontwikkeling en de acceptatietest, de stap waarin de klant controleert of de applicatie aan het contract voldoet. In de voorbeeldclausule heeft de klant 10 dagen voor een eerste controle, en daarna 30 dagen controle bij normaal gebruik. Voor de leverancier is de ondertekening van de acceptatieverklaring een belangrijke stap: die “ontslaat de leverancier van zijn contractuele verplichtingen en ontgrendelt meestal een flinke betalingsmijlpaal”.

In dit schema krijgen uw gebruikers het product pas te zien als alles is ontwikkeld en gecontroleerd. Bij regie verplicht niets in het model om gaandeweg bruikbare software in handen van uw gebruikers te leggen.

Voor een startup is het juist het gebruik dat laat zien of het product in een behoefte voorziet. Hoe eerder uw gebruikers het in handen hebben, hoe eerder u weet wat u moet veranderen. Een eerste minimaal product dient precies om dat te toetsen.

Vraag uw leverancier dus wanneer uw gebruikers met de software kunnen werken.

U beslist wat er gebouwd wordt, de leverancier beslist hoe

Marty Cagan, oprichter van de Silicon Valley Product Group, een bureau dat productteams opleidt, was senior vicepresident product en design bij eBay. Hij onderscheidt vier risico’s bij elk product: niemand wil het kopen of gebruiken, niemand begrijpt hoe het werkt, het is niet te bouwen met de beschikbare tijd, kennis en technologie, of het houdt het bedrijf niet in leven. De haalbaarheid legt hij bij de engineers, en de vraag van klanten en de levensvatbaarheid voor het bedrijf bij de productverantwoordelijke.

In uw startup bent u de productverantwoordelijke. De leverancier staat in voor de haalbaarheid. Of klanten uw product willen, en of het uw bedrijf in leven houdt, blijft uw zaak, wie de code ook schrijft.

Als het contract een arbeidsovereenkomst wordt

Het Nederlandse recht trekt dezelfde grens tussen wat u beslist en wat de leverancier beslist. Volgens de Kamer van Koophandel hangt het van onder meer deze kenmerken af of iemand zelfstandig werkt: hij bepaalt zelf zijn werktijden, gebruikt zijn eigen gereedschap en bepaalt zelf hoe hij het werk uitvoert. Voldoet iemand niet aan de voorwaarden voor zelfstandigheid, dan is er sprake van schijnzelfstandigheid. In België onderscheidt de gezagsverhouding de loontrekkende van de zelfstandige: partijen mogen hun arbeidsrelatie zelf kwalificeren, maar die kwalificatie houdt geen stand als de feitelijke uitvoering er niet mee te verzoenen is. Ook de Franse rechter kijkt naar de werkelijke arbeidsomstandigheden: Pierre Bonneau, partner arbeidsrecht bij het advocatenkantoor CMS Francis Lefebvre, herinnert er in een artikel uit 2016 aan dat hij naar de werkelijke arbeidsomstandigheden kijkt, en niet naar wat het contract zegt. Tot de aanwijzingen die hij noemt: het ter beschikking stellen van werkmiddelen, het vastleggen van werktijden, regelmatige verslaglegging, een beoordeling met mogelijke sancties.

Blijkt het in werkelijkheid loondienst te zijn, dan moet de opdrachtgever alsnog loonheffing betalen, kan de Belastingdienst een naheffing opleggen en, bij opzet, ook een boete (KVK).

U legt dus het verwachte resultaat vast, en u beoordeelt wat wordt opgeleverd. De werktijden, de tools en de manier van werken blijven de zijne. Wilt u iemand die fulltime onder uw leiding werkt, dan hebt u een werknemer nodig, bijvoorbeeld een eerste developer.

Met een bureau is het niet anders: het kiest zelf zijn manier van werken. Wilt u developers in uw team, aan wie u elke dag het werk geeft, dan neemt u ze in dienst, of kiest u detachering in regie. In dat laatste geval moet de leverancier het gezag houden over de mensen die hij ter beschikking stelt. In België is het uitlenen van personeel met overdracht van werkgeversgezag verboden, behalve in de door de wet voorziene gevallen (FOD Werkgelegenheid). Het risico ontstaat als de leverancier alleen mensen levert, zonder een eigen dienst.

Wie beoordeelt het werk van de leverancier, als u niet technisch bent?

Beoordelen wat wordt opgeleverd, veronderstelt dat u het kunt lezen. Een oprichter die niet technisch is, ziet het scherm, niet de code.

Wat hij heeft gebouwd, en wat hij heeft doorontwikkeld. Vraag de leverancier vóór ondertekening u software te laten zien die hij in productie heeft gebracht en daarna jarenlang heeft doorontwikkeld. En vraag zijn vroegere klanten hoe hij werkt als er een probleem opduikt.

Een technische blik van buitenaf. Een parttime CTO kan de code voor u lezen: hij controleert het opgeleverde werk, en verdedigt uw belangen bij de leverancier.

Van wie is de code: de schriftelijke overdracht

Bestaat de arbeid van een werknemer in het vervaardigen van software, dan wordt, tenzij partijen anders zijn overeengekomen, zijn werkgever als maker van het werk aangemerkt (artikel 7 Auteurswet). Die regel geldt voor werknemers, en niet voor een freelance developer of een bureau.

De factuur betalen maakt u niet de eigenaar van de code. Een overeenkomst tot overdracht van auteursrecht wordt schriftelijk aangegaan, en de overdracht zelf vereist een daartoe bestemde akte. Draagt de maker zelf (een natuurlijke persoon, zoals een freelancer) over, dan omvat de overdracht alleen de bevoegdheden die uitdrukkelijk in de overeenkomst staan vermeld of die uit de aard en de strekking ervan noodzakelijkerwijs voortvloeien (artikel 2, derde lid, Auteurswet). Het ontwikkelcontract moet dus een overdrachtsclausule bevatten. Wat daarin niet staat, wordt in beginsel niet overgedragen.

Noem in het contract elk overgedragen recht afzonderlijk. Leg ook vast of de overdracht exclusief is. Is ze dat niet, dan kan de leverancier dezelfde code elders gebruiken, of in licentie geven aan andere bedrijven.

Een deel van de code kan ook bij de leverancier blijven. De Franse handleiding van Syntec Numérique, bedoeld voor leveranciers “van elke omvang” die mobiele apps ontwikkelen, raadt hun aan hun “eerder verworven kennis” vooraf uit te sluiten van de overgedragen rechten. De modelclausule bepaalt dat de leverancier “volledig eigenaar blijft” van de “middelen, werkwijzen en knowhow” die hij inzet, en de klant daarvan “een niet-exclusief gebruiksrecht” verleent.

Die clausule beschermt knowhow die de leverancier van klant tot klant hergebruikt. Voor u betekent ze dat een deel van de code van uw applicatie misschien niet van u is: u hebt alleen het recht het te gebruiken, onder licentie. Dezelfde modelclausule staat de klant toe die licentie in sublicentie te geven “aan iedereen die hij kiest”: zo kunt u uw applicatie later aan een andere developer toevertrouwen. Vraag welke delen van de code bij de leverancier blijven, en controleer of uw contract u die vrijheid laat.

Zonder overdracht verplicht niets in het contract de leverancier u de code te geven op de dag dat u erom vraagt. Een verhaal dat in 2008 op de Franse site LinuxFr.org werd gepubliceerd beschrijft zo’n geval. Laat de clausule door een advocaat nalezen voordat u tekent.

De accounts: domeinnaam, hosting, repository

Software is meer dan code. Om online te staan, heeft ze ook een domeinnaam nodig, een hostingprovider, en een repository, de plek waar de broncode wordt bewaard. Staan die accounts op naam van de leverancier, dan heeft hij er toegang toe: u hebt hem nodig voor elke wijziging, en om te vertrekken.

Open deze accounts op naam van uw bedrijf vóór de eerste werkdag, en geef hem toegang. Doe bij een mobiele app hetzelfde met de accounts waarmee u die in de app stores publiceert. Gaat u met iemand anders werken, dan trekt u een toegang in.

De Franse juridische nieuwssite Le Monde du Droit raadt aan, om bij de broncode te kunnen als de leverancier in gebreke blijft, een escrowovereenkomst te sluiten: de code en de documentatie worden bij een derde gedeponeerd, en met een afgesproken regelmaat bijgewerkt. Naar ons idee is het eenvoudiger met een repository op naam van uw bedrijf: u hebt de code elke dag, zonder te wachten tot de leverancier in gebreke blijft.

Als de developer niet meer beschikbaar is

Werkt er maar één developer aan, dan is een andere opdracht, een vakantie of ziekte al genoeg om hem onbeschikbaar te maken. Zolang de kennis van de software niet is opgeschreven, vertrekt ze met hem.

Vraag hem vanaf het begin wat een andere developer zou moeten weten om de software over te nemen: hoe hij die installeert, hoe hij die online zet, welke tests controleren dat een wijziging niets breekt wat werkte. En laat dat opschrijven, terwijl het werk vordert.

Is hij al vertrokken, dan begint de overname van de applicatie door een andere leverancier met het verzamelen van de toegangsgegevens en het schrijven van tests, vóór elke wijziging.

Kunnen vertrekken

Bij het kiezen van een leverancier telt ook hoe u weer van hem af komt. Mélina Loupia, journaliste gespecialiseerd in technologie en cyberbeveiliging, waarschuwt in een gids die de Franse techsite Clubic in februari 2026 publiceerde: zonder reversibiliteitsclausule kan een bedrijf in de situatie komen dat het niet van leverancier kan wisselen zonder maanden werk kwijt te raken. Het contract moet het volgende regelen: de teruggave van de gegevens, de toegang tot de configuraties, de overdracht van de documentatie en de opzegtermijn. Die termijn is vaak twee maanden. Een ontwikkelopdracht met een vaste prijs en een vaste scope beëindigen heeft een prijs: de opdrachtgever kan de overeenkomst te allen tijde opzeggen, maar de opdrachtnemer houdt recht op een naar redelijkheid vast te stellen deel van het loon, waarbij onder meer telt wat hij al heeft gedaan en welk voordeel u daarvan heeft. Dergelijke contracten bevatten bovendien vaak een boetebeding of opzegvergoeding.

Een schriftelijke clausule bewijst nog niet dat vertrekken mogelijk is. Dat bewijst alleen een proef. Doe die één keer, voordat u haar nodig hebt: vraag om de code en de documentatie, en geef die aan iemand anders dan de leverancier. Krijgt die de software aan de praat met wat u hebt gekregen, dan kunt u vertrekken.

Kunnen vertrekken verandert ook de relatie. Naar ons idee heeft de leverancier, als de klant het contract op elk moment kan opzeggen, er alle baat bij goed werk te leveren: anders zegt de klant het contract op.

Wanneer een freelance developer of een bureau het juiste antwoord is

Y Combinator, een Amerikaanse startupaccelerator, raadt oprichters die niet technisch zijn aan dat hun team de kennis heeft om zijn product zelf te bouwen, in plaats van het aan iemand anders toe te vertrouwen. Een freelance developer of een bureau inschakelen is uw product aan iemand anders toevertrouwen. Naar ons idee telt dat advies vooral als uw product in de eerste plaats een technologie is, waarvan de technische moeilijkheid de waarde bepaalt. Technische beslissingen zijn daar strategische beslissingen, en die horen bij een technische medeoprichter.

Naar ons idee is een freelance developer het juiste antwoord als het werk duidelijk afgebakend is en iemand anders dan hijzelf kan beoordelen wat hij oplevert. Drie situaties lenen zich daarvoor.

Specifieke kennis voor een product dat al bestaat. Een koppeling met boekhoudsoftware, een systeem voor online betalen.

Een MVP, het minimum viable product. Dat is geen eerste versie van het product, maar de kleinste test die controleert of het idee het bouwen waard is. Beslis vóór de eerste regel code of die test wordt weggegooid of het fundament wordt van uw product. Wordt hij het fundament, dan moet de code vanaf het begin productiekwaliteit hebben, en geldt alles hierboven: de overdracht, de accounts, de overname.

Een oprichter die niet alleen staat. Een medeoprichter, een parttime CTO of een technisch adviseur leest na wat wordt opgeleverd.

Moet uw product jarenlang doorontwikkeld worden, dan is de developer die het bouwt niet per se degene die het doorontwikkelt. De overdracht, de accounts en de documentatie regelt u vóór de eerste werkdag.

Naar ons idee past een bureau als meerdere developers de code van uw product moeten kennen, mits het contract daarin voorziet: vraag hoeveel mensen die zullen kennen.

Voor een freelance developer of een bureau betaalt u met geld. Moet uw product vooruit voordat u middelen hebt, dan blijft de technische medeoprichter over, betaald in aandelen, ten koste van een deel van uw kapitaal.

Welke vragen u moet stellen voordat u tekent

• Wat hebt u in productie gebracht, en doorontwikkeld? Zijn projecten, en wat zijn vroegere klanten erover zeggen.
• Als mijn behoefte verandert, wat verandert er dan aan wat ik betaal? Bij een vaste prijs met vaste scope gaat elke wijziging via meerwerk; bij regie komen er dagen bij op de factuur; met een vast budget en een flexibele scope verandert het bedrag niet, alleen de prioriteiten veranderen.
• Wanneer kunnen mijn gebruikers met de software werken? Een datum waarop ze die in handen hebben, geen einddatum van een project.
• Wie kent bij u de code van mijn product? En wat gebeurt er als die persoon vertrekt?
• Noemt de overdracht van de rechten elk overgedragen recht? Welke delen van de code blijven onder licentie, en mag ik die aan een andere developer toevertrouwen?
• Staan de accounts op naam van mijn bedrijf? De domeinnaam, de hosting, de repository van de code, de publicatieaccounts.
• Hoe kan ik vertrekken? De opzegtermijn, het teruggeven van de gegevens, het overdragen van de documentatie. En de overnameproef, één keer.
• Wie beoordeelt de kwaliteit van het opgeleverde werk? Bent u niet technisch, dan iemand die dat wel is.
• Legt u een resultaat vast, of werktijden? Een resultaat hoort bij een dienstverlening, werktijden bij een arbeidsovereenkomst.

DEVEDANOS: een bureau met een vaste prijs op vast budget

Van deze drie contracten hebben wij gekozen voor de vaste prijs met vast budget en flexibele scope, omdat een product dat zijn klanten zoekt onderweg verandert. U stuurt bij wanneer u wilt, meteen, zonder contractwijziging en zonder meerkosten.

We nemen ook de technische beslissingen die uw product vraagt, zoals een CTO dat zou doen: de technologieën, de architectuur, de manier van testen en in productie brengen. Die stemmen we af op uw doelstellingen.

Bij DEVEDANOS ontwikkelen wij uw software op maat, binnen een maand bruikbaar, tegen een vast maandbudget, en stemmen we die continu af op de veranderingen in uw bedrijf. Het budget wordt samen met u opgebouwd, op basis van uw cijfers en doelstellingen: samen bepalen we het bedrag en het probleem dat uw applicatie moet oplossen. De gebruikers van uw applicatie werken ermee vanaf de eerste ontwikkelmaand, en hoe ze ermee werken, bepaalt welke functionaliteiten we daarna ontwikkelen.

Onze aanpak is adaptief: hij voorspelt wat voorspelbaar is, het maandbudget en de ontwikkeldagen per maand, en probeert niet te voorspellen wat uw gebruikers met een functionaliteit zullen doen voordat ze die in handen hebben.

En om ervoor te zorgen dat wat vorige maand werkte, ook deze maand werkt, hanteren we een nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.

De broncode, infrastructuur, deployment-pipeline en documentatie zijn uw intellectueel eigendom zodra de eerste maandfactuur is betaald. Een proefperiode tot 15 werkdagen in de eerste maand: geen factuur als u de opleveringen niet wilt.

U kunt het contract schriftelijk opzeggen op elk moment, zonder opgaaf van redenen. Tijdens de maand van reversibiliteit begeleiden wij uw team totdat het kan bouwen, testen en deployen zonder ons. De pipeline blijft elke toekomstige wijziging beschermen, welke developer er ook aan werkt.

We hebben volledige zelfstandigheid nodig in de manier van werken, van het begin tot het einde van het project. Daarom detacheren we geen developers in uw team, en nemen we geen project aan waarvan u zelf de werkmethode bepaalt. Juist die zelfstandigheid stelt ons in staat in te staan voor een applicatie die binnen een maand bruikbaar is, en voor elke regressie.

We bouwen onder meer marketplaces, bedrijfsapplicaties en mobiele apps.

Verder lezen

Zoekt u een developer of een bureau om uw applicatie te laten ontwikkelen? Zullen we erover praten?

Bronnen

• M. Cagan, “The Four Big Risks” (de vier risico’s van een product: de haalbaarheid ligt bij de engineers, de waarde en de levensvatbaarheid bij de productverantwoordelijke), Silicon Valley Product Group, 4 december 2017.
• Silicon Valley Product Group, profiel van Marty Cagan (zijn loopbaan, waaronder het vicepresidentschap product en design bij eBay), geraadpleegd op 24 oktober 2026.
• P. Bonneau, “Les Urssaf, remparts à l’uberisation de l’économie ?” (de rechter kijkt naar de werkelijke arbeidsomstandigheden, en naar de aanwijzingen voor een gezagsverhouding), CMS Francis Lefebvre, 8 augustus 2016.
• M. Loupia, journaliste, gespecialiseerd in tech en cyberbeveiliging, “Choisir un prestataire informatique : 8 questions essentielles à poser” (de reversibiliteitsclausule, en wat het contract moet regelen om te kunnen vertrekken), Clubic, 16 februari 2026.
• “Développement de logiciel par un prestataire : ce qu’il faut savoir sur votre contrat” (de escrowovereenkomst), Le Monde du Droit, 5 december 2022.
• Syntec Numérique en Staub & Associés, “Sécuriser le développement d’une application mobile” (de scope die via een addendum wordt gewijzigd, het storyboard en de acceptatietest, de eerder verworven kennis die van de overdracht is uitgesloten), juridische handleiding PraTIC, 2015, p. 2 tot 6.
• Blog “Propriété du code d’un logiciel commandé” en de reacties erop (een klant die de code van de bestelde software niet krijgt), LinuxFr.org, 8 oktober 2008.
• J. Cheminat, “Méthode agile : la justice rappelle l’importance du cahier des charges” (een jong bedrijf waarvan de terugbetalingsvordering werd afgewezen, na een agile ontwikkeling zonder programma van eisen), Le Monde Informatique, 9 november 2020, over T. com. Paris, 7 oktober 2020.
• B. Flyvbjerg, A. Budzier, J. S. Lee, M. Keil, D. Lunn, D. W. Bester, “The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution” (bij 4.677 projecten werkelijke kosten van gemiddeld 1,8 keer de geschatte kosten, en een mediane overschrijding dicht bij nul), Journal of Management Information Systems, 39(3), 607-639, 2022.
• Kamer van Koophandel, “Wet DBA: voorkom schijnzelfstandigheid” (de kenmerken van zelfstandigheid, schijnzelfstandigheid en de gevolgen ervan), geraadpleegd op 26 oktober 2026.
• FOD Werkgelegenheid, “Arbeidsrelatiewet: aard van de arbeidsrelatie (loontrekkende)” (de gezagsverhouding, en de feitelijke uitvoering die de gekozen kwalificatie kan terzijde schuiven), geraadpleegd op 26 oktober 2026.
• FOD Werkgelegenheid, “Terbeschikkingstelling van werknemers” (het verbod op het uitlenen van personeel met overdracht van werkgeversgezag), geraadpleegd op 26 oktober 2026.
• Auteurswet, artikel 2, derde lid (de overeenkomst wordt schriftelijk aangegaan; de overdracht vereist een daartoe bestemde akte; bij overdracht door de maker omvat ze alleen wat uitdrukkelijk is vermeld of noodzakelijkerwijs voortvloeit), wetten.overheid.nl.
• Auteursrecht.nl, “Werkgever als maker” (artikel 7 Auteurswet: de werkgever als maker van het werk van een werknemer), geraadpleegd op 26 oktober 2026.
• Burgerlijk Wetboek Boek 7, artikel 408 (de opdrachtgever kan de overeenkomst van opdracht te allen tijde opzeggen) en artikel 411 (bij voortijdig einde heeft de opdrachtnemer recht op een naar redelijkheid vast te stellen deel van het loon) en artikel 639 (de werknemer behoudt gedurende zijn vakantie recht op loon) en artikel 629 (de werknemer die door ziekte niet kan werken, behoudt recht op doorbetaling van ten minste 70% van zijn loon), wetten.overheid.nl.