Waarom „maatwerk of kant-en-klaar” de verkeerde vraag is
Je hebt een Excel-tabel voor bestellingen, een ERP-module die het team voor de helft van de stappen omzeilt, of een SaaS die precies het onderdeel dat het meest telt, buiten beschouwing laat. Op een gegeven moment zegt iemand „laten we onze eigen software bouwen”. De vraag die daarop volgt, wordt meestal verkeerd gesteld: maatwerksoftware of kant-en-klare software, als één enkele keuze voor het hele proces.
In werkelijkheid wordt de beslissing stuk voor stuk genomen: welk deel van het proces te gangbaar is om opnieuw uit te vinden, en welk deel specifiek is voor jouw bedrijf, zodat geen enkel standaardpakket het dekt. Het artikel doorloopt de criteria die ertoe doen, toont de hybride variant die de meeste bedrijven missen, en dan een beslissingstabel en de signalen van een onbetrouwbare offerte voor softwareontwikkeling.
Het eerste criterium: hoe standaard het proces is en hoezeer het je onderscheidt
Een eenvoudige test uit software-engineering helpt bij de beslissing: als het proces dat je wilt veranderen iets is wat elk bedrijf in jouw sector op dezelfde manier doet — boekhouding, onboarding, het opstellen van een factuur — koop je een kant-en-klare tool en pas je je proces daaraan aan. Als het proces juist de reden is waarom klanten jou kiezen, verdient dat onderdeel speciaal geschreven code. Martin Fowler zegt het direct: als het proces deel uitmaakt van jouw concurrentievoordeel, bouw je maatwerksoftware; zo niet, dan koop je een pakket en pas je je eraan aan.
Context: op EU-niveau zijn kant-en-klare tools al de norm — het percentage bedrijven met een ERP varieert van 41% bij kleine bedrijven tot 89% bij grote, en 53% van de EU-bedrijven gebruikt minstens één ERP-, CRM- of BI-systeem, volgens Eurostat (2025). De standaardkern is bijna altijd het juiste startpunt; de nuttige vraag is wat eraan ontbreekt, voor jou.
Het tweede criterium: wat met wat moet communiceren
Weinig „kant-en-klaar van het schap” gekochte tools communiceren van nature met alles wat je al in huis hebt. Een ERP zoals SAGA of SAP, een koerier met dagelijkse AWB's, het RO e-Factura-systeem van de ANAF — elk heeft een eigen formaat, en een generieke SaaS dekt ze zelden allemaal out of the box, zeker niet voor een flow die specifiek is voor een Roemeens bedrijf. Meestal wordt die wrijving niet opgelost door de kern te vervangen, maar via kleine, toegewijde webapplicaties, precies gebouwd als brug tussen de systemen.
De termijnen zijn niet theoretisch: B2B-rapportage in RO e-Factura werd verplicht vanaf 1 januari 2024, en B2B-facturatie via hetzelfde systeem vanaf 1 juli 2024, volgens het Ministerie van Financiën. Ongeacht of de facturatie op de gekochte tool blijft of in een op maat gebouwd onderdeel terechtkomt, is de integratie met e-Factura niet optioneel — het is een wettelijke vereiste die je hoe dan ook moet afvinken.
Het derde criterium: wie de code, de infrastructuur en de data bezit
Als je een abonnement koopt, staan je gegevens meestal in het formaat en op de infrastructuur van de leverancier. Zolang de relatie goed loopt, maakt dat niet uit. Het telt op de dag dat de leverancier zijn prijzen wijzigt, wordt overgenomen door iemand anders, of het product stopzet — het moment waarop je onderhandelt vanuit de positie van het bedrijf dat niets bezit van wat het heeft opgebouwd.
Vandaar ook de valkuil van de agressieve personalisatie van een gekocht pakket. Thoughtworks wijst erop dat het aanpassen van gekochte software dezelfde risico's met zich meebrengt als ontwikkeling vanaf nul — vertragingen, onvoorziene kosten, competenties die niets met de kernactiviteit te maken hebben — maar zonder het voordeel om, uiteindelijk, de code te bezitten. Fowler beveelt het tegenovergestelde aan: in plaats van de gekochte kern te personaliseren, bouw je losse onderdelen, gekoppeld via API, die je volledig bezit — precies het principe achter de hybride variant.
Het vierde criterium: de kosten over drie jaar, niet de startprijs
Een abonnement lijkt goedkoop in de eerste maand. Over drie jaar stijgen de kosten met het aantal gebruikers, met het datavolume en, bijna altijd, met de tarieven voor precies de uitzonderingen die je nodig hebt — een extra module, een hoger plan, een add-on enkel voor jouw flow. Een build op maat kost in het begin meer en vraagt daarna onderhoud, maar de curve is anders: de grote inspanning zit geconcentreerd aan het begin en vermenigvuldigt zich niet met elke nieuwe gebruiker.
Er bestaat geen universeel verdict — niet „altijd kopen”, niet „altijd bouwen”. Forrester beschrijft dit als een slinger: bedrijven die voortdurend naar één uiterste neigen, verliezen controle of snelheid, terwijl een bewuste combinatie het stabielste resultaat oplevert. Time to value telt net zo zwaar als de prijs — een gekochte tool is bijna altijd sneller inzetbaar dan een build vanaf nul, nog een reden om de kern niet weg te gooien.
De variant die de meeste bedrijven missen: de kern blijft, de onderdelen worden op maat gebouwd
Het gesprek „maatwerk of kant-en-klaar” loopt vast omdat het als een enkele keuze voor het hele systeem wordt gesteld. De hybride variant — je behoudt de standaardkern en bouwt op maat alleen de ontbrekende onderdelen — is de variant waar bedrijven die de kosten op lange termijn analyseren, niet alleen de startprijs, vaak op uitkomen. De onderdelen die eromheen worden gebouwd, zijn meestal drie: integraties, interne beheerpanelen en automatiseringen.
AutosWorld is een concreet voorbeeld, nog in de lanceringsfase: een webshop gebouwd op WooCommerce, met het standaardplatform ongewijzigd. Wat op maat wordt gebouwd, is het beheerpaneel aan de achterkant — dashboard, snelle productbewerking, eigen velden voor leverancier en marge, automatisch berekend. Na het inloggen komt het team direct in zijn eigen paneel terecht, niet in WordPress, zodat de dagelijkse voorraadwerking niet van iemand buiten het bedrijf afhangt.
Tchibo GAME ON toont de omgekeerde situatie — het proces is echt het product. De campagne vereiste het uploaden van kassabonnen vanaf de telefoon, automatische validatie en antifrauderegels tegen dubbele bonnen. Geen enkele kant-en-klare tool dekte deze combinatie, dus werd het platform volledig op maat gebouwd, door The Niche Society. Het verschil met AutosWorld zit niet in kwaliteit, maar in het type proces.
De beslissingstabel: wat we aanbevelen, afhankelijk van de situatie
De criteria hierboven geven voor elk bedrijf een ander antwoord. De tabel brengt de veelvoorkomende situaties samen met de bijbehorende aanbeveling.
| Situatie | Aanbeveling | Waarom |
|---|---|---|
| Identiek proces bij elk bedrijf in de sector | Je koopt de kant-en-klare tool | Niemand wint bij het opnieuw uitvinden van een gestandaardiseerd proces |
| Het team verliest tijd met het handmatig kopiëren van data naar een ander systeem | Je bouwt een integratie op maat bovenop de kern | Het probleem zit op de grens tussen systemen, niet in de kern |
| Het proces is de reden waarom klanten jou kiezen, niet de concurrentie | Je bouwt maatwerksoftware voor dat ene stuk | Een standaardpakket brengt je op het niveau van de markt |
| Je hebt een eenvoudige back-office nodig bovenop een standaardplatform (bijv. webshop) | Je behoudt de kern, voegt een op maat gebouwd paneel toe | De kern blijft eenvoudig bij te werken |
| Je weet nog niet welk proces je wilt automatiseren | Begin met een geschreven discovery, geen opdracht voor code | Een verkeerd doel kost meer dan een maand analyse |
Hoe een serieuze eerste build eruitziet — en waar je op let bij een offerte
Een serieuze eerste build begint niet met code, maar met een korte discovery die wordt afgesloten met een document: wat er wordt gebouwd, wat niet, hoe de integraties eruitzien en wie wat doet. De eerste lancering is bewust klein — één enkele flow, tot het einde. De code en infrastructuur staan vanaf de eerste dag op het account van het klantbedrijf.
Onderhoud stopt niet bij de lancering: dependencies verouderen, integraties kunnen breken wanneer het ERP of de e-Factura-specificatie verandert, en beveiligingspatches zijn niet optioneel. Software die twee tot drie jaar „vergeten” wordt, wordt stilletjes een risico — het onderhoudsbudget verdient het om al bij de eerste offerte besproken te worden.
- 01Vaste prijs vóór enige discovery de inspanning werd geraden, niet gezien
- 02Doel alleen in mondelinge gesprekken, niet op papier misverstanden komen pas bij de oplevering aan het licht
- 03De code blijft op het account van de leverancier zonder toegang zit je er voor onbepaalde tijd aan vast
- 04Eén enkele lancering, alles tegelijk problemen komen te laat aan het licht
- 05Geen enkel gesprek over wat er na de lancering komt het eerste probleem wordt een noodgeval, geen geplande taak
Bronnen en verder lezen.
- 01Eurostat — E-business software usage in EU enterprises (2025)
- 02Ministerie van Financiën — RO e-Factura, officiële presentatie
- 03Martin Fowler — Package Customization
- 04Thoughtworks — The Buy versus Build Shift: Issues With Buying Software
- 05Forrester — The ROI Pendulum: Build vs. Buy in the Age of AI
Veelgestelde vragen
Wanneer loont het om maatwerksoftware te bouwen in plaats van een kant-en-klare tool te kopen?
Wanneer het proces de reden is waarom klanten voor jou kiezen, niet voor een concurrent, of wanneer geen enkele combinatie van tools op de markt de exacte flow dekt die je nodig hebt. Voor alles wat gangbaar is in jouw sector, is het meestal goedkoper om te kopen en je proces daaraan aan te passen.
Wat betekent de hybride variant en waarom mist de meerderheid van de bedrijven die?
De standaardtool die je al gebruikt behouden en op maat alleen de ontbrekende onderdelen bouwen — integraties, interne panelen, automatiseringen. Dit wordt vaak gemist omdat het gesprek start als een enkele keuze tussen „alles kopen” en „alles bouwen”, terwijl de beslissing apart, per onderdeel, wordt genomen.
Hoe herken ik een serieuze offerte voor maatwerksoftwareontwikkeling?
Begin met een discovery en een geschreven doel, niet met een vaste prijs die al bij het eerste gesprek wordt gegeven. Stel een kleine eerste lancering voor, geen „big bang” met alles wat ooit is bedacht, en laat de code vanaf de eerste dag op het account van jouw bedrijf staan.
Wie zou de code en infrastructuur moeten bezitten bij een maatwerksoftwareproject?
Het klantbedrijf, niet het bureau dat bouwt. De code staat op het account van jouw organisatie, de infrastructuur op jouw cloudaccount, ook al beheert het bureau die dagelijks. Zo kun je altijd van leverancier wisselen, zonder te verliezen wat je hebt opgebouwd.
Laten we kijken wat we bij jou kunnen automatiseren.
Een gratis sessie van 30 minuten: we vertellen je wat er te automatiseren valt, hoe lang het duurt en wat het kost, met een vaste prijs na de discovery.