Een programma namaken dat op het origineel lijkt, is iets anders dan een product leveren waarop klanten hun werk kunnen bouwen. Toch roepen de recente berichten over met AI nagebouwde software een terechte vraag op. Als delen van het ontwikkelwerk minder tijd kosten, wat koopt de klant dan nog bij een softwaredienstverlener? Het antwoord raakt de prijs, maar ook de kennis en verantwoordelijkheid die je als leverancier biedt.
Nabouwen heeft technische en juridische grenzen
Ook juridisch is er verschil tussen functionaliteit en de uitwerking ervan. In de zaak SAS Institute tegen World Programming maakte het Hof van Justitie in 2012 dat onderscheid voor auteursrecht op computerprogramma’s. Die uitspraak is geen algemene toestemming om software of alles wat daarbij hoort te kopiëren. Voor mijn punt is vooral van belang dat juridische bescherming en de praktische moeite van nabouwen twee verschillende dingen zijn.
De zichtbare werking van een programma kan helpen om een alternatief te ontwerpen. Daarmee zijn nog niet alle uitzonderingen, koppelingen en onderhoudsproblemen opgelost. De commerciële vraag is dus hoeveel ontwikkelwerk eenvoudiger wordt en welke kennis nodig blijft om het resultaat betrouwbaar te gebruiken. Dat verschil verdwijnt zodra je een eerste versie en een volwassen product op één hoop gooit.
Wat de klant nog steeds nodig heeft
Een klant moet kunnen uitleggen welk probleem de software oplost, welke uitzonderingen ertoe doen en wanneer de oplossing goed genoeg is. Na oplevering blijven onderhoud, beveiliging, ondersteuning en koppelingen nodig. Ontwikkelwerk verdwijnt daarmee niet. Wel moet een leverancier kunnen uitleggen waar de inspanning zit en wat die de klant oplevert.
Voor een softwareproduct spelen ook zaken als gebruiksgemak, overstapkosten en dienstverlening mee. Bij maatwerk komt de vraag dichter bij de opdracht te liggen: welke kennis, uitvoering en verantwoordelijkheid kopen we hier precies in?
Uren, vaste prijs of resultaat
Voor dienstverleners die op urenbasis werken, kan kortere ontwikkeltijd aanleiding zijn om opnieuw naar planning en prijs te kijken. Een uurtarief is daarmee niet achterhaald. Bij een onzekere opdracht kan het een werkbare afspraak zijn. Een vaste prijs of vergoeding op basis van resultaat vraagt juist om een duidelijke scope, meetbare afspraken en invloed op het resultaat.
Ik zou daarom beginnen bij de offerte. Welke werkzaamheden verwacht je nodig te hebben? Waar helpt AI mogelijk, welke controle blijft nodig en wie draagt het risico als de aannames niet kloppen? Daarover kun je een eerlijker gesprek voeren dan over de belofte dat AI alles sneller maakt.
Begin bij een recente offerte
Pak een recente offerte erbij. Kun je per belangrijk onderdeel uitleggen waarom het nodig is, welke inzet het vraagt en hoe de klant het resultaat kan beoordelen? Dat gesprek lijkt mij een betere voorbereiding op AI dan alvast het hele verdienmodel afschrijven.