Voor bedrijven die hun supplychainsoftware willen uitbreiden, heeft de opkomst van AI-ontwikkelde apps de traditionele afweging tussen kopen en bouwen veranderd.
Voorheen was zelf bouwen voor de meeste kleine en middelgrote bedrijven simpelweg geen realistische optie. Maatwerksoftware vereiste een ontwikkelteam, een langdurig project en een onderhoudslast die alleen grote organisaties konden dragen. Nu AI het mogelijk maakt om binnen enkele dagen in plaats van maanden werkende applicaties te ontwikkelen, is die balans verschoven.
De vraag is daarom niet langer of je zelf kunt bouwen, maar wanneer je dat zou moeten doen. Voor welke oplossingen kun je nog steeds het beste kiezen voor SaaS? En in welke situaties is een AI-ontwikkelde app de betere optie?
Wat is er veranderd?
Met de introductie van Claude Opus 4.5 in november 2025 veranderde AI-ondersteunde softwareontwikkeling van een nuttig hulpmiddel in iets wezenlijk anders: agents die complete codepakketten van hoge kwaliteit kunnen schrijven, terwijl ze nog steeds door een mens worden aangestuurd. Modellen die daarna zijn uitgebracht, hebben de lat nog hoger gelegd. In de praktijk betekent dit dat de kosten en doorlooptijd van maatwerksoftware met een factor tien zijn afgenomen.
Voor supplychainteams biedt dit waardevolle mogelijkheden: oplossingen op maat voor unieke en complexe problemen die met standaardproducten moeilijk of alleen tegen hoge kosten kunnen worden opgelost.
Iedere supply chain kent wel enkele processen die niet binnen de standaard passen. Processen die momenteel bij elkaar worden gehouden met spreadsheets, e-mailketens en kennis die alleen in de hoofden van medewerkers zit. Juist dit soort problemen wordt door softwareleveranciers zelden goed opgelost, omdat ze te specifiek zijn om er een standaardproduct voor te ontwikkelen.
AI-ontwikkelde apps brengen echter ook reële risico’s met zich mee, vooral op het gebied van testen, beveiliging en onderhoudbaarheid. Goedkoop om te bouwen betekent niet automatisch goedkoop om te beheren. In de rest van dit artikel leggen we uit wanneer iedere route logisch is en hoe je verantwoord bouwt wanneer je daarvoor kiest.
Argumenten voor SaaS
Er zijn situaties waarin SaaS nog steeds de meest logische keuze is. De argumenten daarvoor zijn grotendeels onveranderd.
Grotere schaal, wat betreft gebruikers en locaties. Hoe meer mensen en locaties afhankelijk zijn van een tool, hoe groter de behoefte aan robuust toegangsbeheer, goede prestaties bij intensief gebruik, meertalige ondersteuning en professioneel releasemanagement. Leveranciers hebben deze problemen één keer opgelost voor honderden klanten. Wanneer je zelf bouwt, los je ze slechts voor één organisatie op.
Grotere functionele reikwijdte. Een geavanceerd APS-pakket vertegenwoordigt duizenden mensjaren aan opgebouwde functionaliteit en oplossingen voor uitzonderingssituaties. AI kan snel code schrijven, maar kan de domeinkennis die in een volwassen product is verwerkt niet samenpersen. Een brede scope betekent bovendien veel integraties. Juist daar worden maatwerkoplossingen vaak kwetsbaar.
Kritieke aard van de oplossing. Als het magazijn stilvalt zodra de software uitvalt, wil je een leverancier met een SLA, servicedesk, uitwijkvoorzieningen en audittrail. Hetzelfde geldt voor oplossingen die te maken hebben met financiële rapportages, douanezaken, veiligheid of wet- en regelgeving.
Gestandaardiseerde processen. Wanneer jouw proces in essentie hetzelfde is als dat van andere organisaties, zoals order-to-cash, het boeken van vervoerders of EDI-koppelingen met grote klanten, levert zelf bouwen geen concurrentievoordeel op. Koop de oplossing, configureer deze en ga verder.
Ecosysteem en standaarden. Leveranciers onderhouden integraties met vervoerders, marktplaatsen, douaneautoriteiten en ERP-systemen. Ook zorgen zij ervoor dat deze koppelingen blijven werken wanneer externe partijen hun interfaces wijzigen. Dat voortdurende onderhoud blijft onzichtbaar, totdat je het zelf moet uitvoeren.
Argumenten voor AI-ontwikkelde apps
Kleine schaal, met een beperkt aantal gebruikers en locaties. Een tool die door vijf planners op één locatie wordt gebruikt, stelt totaal andere eisen dan een oplossing voor vijfhonderd gebruikers. Veel functies van enterprise-oplossingen vormen in zo’n geval onnodige ballast. Bovendien maakt de prijs per gebruiker SaaS bij kleinschalige implementaties vaak onevenredig duur.
Beperkte functionele reikwijdte. Een klein en duidelijk afgebakend probleem is bij uitstek geschikt voor AI-ontwikkelde software: één workflow, een heldere input en output en een beheersbare set bedrijfsregels. Hoe kleiner de scope, hoe beter een mens kan begrijpen, testen en controleren wat de AI heeft gebouwd.
Het unieke karakter van het probleem. Dit is het sterkste argument voor zelf bouwen. Wanneer het probleem echt specifiek is voor jouw producten, netwerk of klanten, biedt de SaaS-markt vaak geen passende oplossing. Het alternatief is meestal een duur maatwerktraject of een product dat je dwingt jouw proces aan de logica van de software aan te passen. Met een maatwerkapplicatie past de software zich aan het proces aan, in plaats van andersom.
Snelheid en omkeerbaarheid. Een AI-ontwikkelde app kan binnen één dag als prototype worden gebouwd en diezelfde week al aan gebruikers worden voorgelegd. Blijkt het probleem verkeerd te zijn begrepen, dan zijn de gemaakte kosten beperkt. Vergelijk dat met de selectie, contractering en implementatie van een SaaS-oplossing, een traject dat doorgaans zes tot achttien maanden duurt.
De hiaten tussen bestaande systemen opvullen. De meeste supplychainsoftwarelandschappen beschikken al over een centraal ERP- of WMS-systeem. De grootste pijnpunten bevinden zich meestal in de tussenliggende gebieden: een afstemming waarvoor niemand verantwoordelijk is, een rapport dat een dag kost om samen te stellen of de afhandeling van uitzonderingen die zich volledig in iemands inbox afspeelt.
Deze oplossingen aan de randen van het systeem zijn bij uitstek geschikt om zelf te bouwen, juist omdat ze klein, specifiek en relatief laagrisico zijn.
De kopen-of-bouwen-matrix
De twee groepen argumenten kunnen worden samengebracht in twee assen. De verticale as combineert de argumenten voor SaaS: schaal, functionele reikwijdte en bedrijfskritiek. De horizontale as vertegenwoordigt het sterkste argument voor zelf bouwen: het unieke karakter van het probleem.
Door een oplossing langs deze twee assen te positioneren, ontstaan vier kwadranten.
Buy or build matrix
Kopen: hoge schaal en weinig uniek. Dit zijn brede, kritieke processen die sterk lijken op die van andere organisaties en goed met standaardsoftware kunnen worden ondersteund. Het bezit van deze software levert geen voordeel op. Het levert juist veel voordelen op wanneer een leverancier verantwoordelijk is voor onderhoud, integraties en ondersteuning.
Kopen en samen met een partner uitbreiden: hoge schaal en zeer uniek. Dit is het lastigste kwadrant: een proces dat kritisch en omvangrijk is, maar niet binnen een bestaand product past.
Begin in dat geval niet vanaf nul en pak het niet alleen aan. Koop het meest geschikte kernsysteem en overbrug vervolgens samen met de leverancier of een implementatiepartner de resterende kloof. Dat kan door middel van configuratie, een gezamenlijk ontwikkelde uitbreiding of een maatwerkoplossing die aan dezelfde standaarden voldoet als je van een professionele leverancier zou verwachten. Denk daarbij aan grondig testen, een beveiligingscontrole en duidelijk vastgelegd eigenaarschap.
Bouwen: kleine schaal en zeer uniek. Dit zijn afgebakende, specifieke problemen waarmee slechts een handvol medewerkers op één of twee locaties te maken heeft. De SaaS-markt negeert deze problemen of vraagt er onevenredig hoge prijzen voor. Hier leveren AI-ontwikkelde apps de meeste waarde tegen het laagste risico. Ook de eerder genoemde potentiële bouwoplossingen vallen binnen dit kwadrant.
Houd het eenvoudig: kleine schaal en weinig uniek. Kleine, alledaagse problemen hebben geen licentie en ook geen eigen app nodig. Een goed opgebouwde spreadsheet, een standaardrapport uit het ERP-systeem of een betaalbare standaardtool is vaak voldoende. Weersta de verleiding om iets te bouwen, alleen omdat bouwen eenvoudiger is geworden.
De meeste oplossingen blijven niet voor altijd op dezelfde plek in de matrix staan. Een succesvolle maatwerkoplossing verschuift vaak naar boven wanneer steeds meer gebruikers en locaties ermee gaan werken. Zodra dat gebeurt, komt de oplossing terecht in het kwadrant ‘kopen en samen met een partner uitbreiden’ en moet deze op basis van die nieuwe positie opnieuw worden beoordeeld.
Een praktisch besliskader
De matrix geeft het algemene overzicht. Met de volgende vijf vragen kun je een specifieke oplossing erin positioneren:
- Hoeveel mensen en locaties worden hiervan afhankelijk? Bij meer dan enkele tientallen gebruikers of meerdere locaties ligt kopen meer voor de hand.
- Wat gebeurt er als de oplossing een dag niet beschikbaar is? Als het antwoord luidt dat de operatie stilvalt, kun je beter kopen. Of je moet de oplossing op een veel hoger kwaliteitsniveau bouwen.
- Bestaat er een goed product voor precies dit probleem? Als dat zo is en de prijs redelijk is, kies dan voor kopen. Is de aansluiting slecht of betaal je voor een kleine behoefte een enterpriseprijs, dan kan bouwen logischer zijn.
- Is het proces onderscheidend of gestandaardiseerd? Gestandaardiseerde processen koop je in. Onderscheidende processen kunnen de moeite waard zijn om zelf in bezit te hebben.
- Wie is hier over twee jaar verantwoordelijk voor? Als je niemand bij naam kunt noemen, moet je niet bouwen.
De eerste twee vragen bepalen de positie op de verticale as. De derde en vierde vraag bepalen de positie op de horizontale as. De vijfde vraag is een doorslaggevende voorwaarde voor alles wat zich in de twee rechterkwadranten bevindt.
Voor de meeste middelgrote bedrijven ontstaat daarom niet het patroon ‘kopen óf bouwen’, maar koop de kern en bouw de randen: een solide SaaS- of ERP-basis voor kritieke, brede processen op grote schaal, omringd door een portfolio van kleine maatwerkapps die de specifieke problemen oplossen waarvoor het kernsysteem geen oplossing biedt.
Conclusie
AI-ontwikkelde apps hebben SaaS niet overbodig gemaakt. Ze hebben het middengebied haalbaar gemaakt: problemen die te klein of te specifiek waren om een softwarelicentie voor te rechtvaardigen, maar tegelijkertijd te pijnlijk waren om in een spreadsheet te laten voortbestaan.
Voor supplychainmanagers liggen de kansen juist in dit middengebied. Koop wat breed, kritisch en gestandaardiseerd is. Bouw wat afgebakend, uniek en van jou is.
Behandel de code die je zelf bouwt bovendien met dezelfde discipline die je van iedere professionele leverancier zou verwachten. Want vanaf het moment dat jouw planners ervan afhankelijk zijn, bén jij de leverancier.
