Het dilemma, eerlijk gesteld
Vroeg of laat staat u als ondernemer voor de vraag: lossen we dit zelf op met maatwerk, of kopen we een kant-en-klare tool? Het voelt als een onschuldige technische keuze, maar in de praktijk kost de verkeerde afslag u geld dat u niet kunt missen — in beide richtingen.
Bouwt u te vroeg, dan steekt u schaars budget en aandacht in iets wat een goedkoop pakket allang doet. U betaalt voor onderhoud, hosting en kennis die u niet hoeft te bezitten, terwijl een abonnement van een paar tientjes per maand hetzelfde had gedaan. Klampt u zich daarentegen te lang vast aan standaardsoftware, dan loopt u een ander risico: een concurrent automatiseert juist dat ene proces dat uw onderscheid was, en u merkt het pas als het te laat is.
De ervaring leert dat de meeste fouten niet ontstaan door een gebrek aan techniek, maar door een gebrek aan een herhaalbare manier om te beslissen. Dit artikel geeft u die: een gewogen scoremodel en een eerlijke kostenbril, zodat de keuze op bewijs rust en niet op vendor-enthousiasme of de trots om iets zelf te kunnen bouwen.
De stelling vooraf, zonder omhaal: voor de meeste MKB-processen is de eerlijke standaard kopen. Bouwen is de uitzondering die u moet kunnen verdedigen. Niet voor niets tonen grote IT-projecten — gemeten door McKinsey & Company samen met de Universiteit van Oxford — dat zij gemiddeld zo'n 45% over budget gaan. Bouw groot is een klif. U hoort daar nergens in de buurt te komen.
Waarom 'bouwen vs kopen' de verkeerde vraag is
Het probleem met de vraag "bouwen of kopen?" is dat hij u dwingt tot een keuze op bedrijfsniveau, terwijl de werkelijkheid zich op procesniveau afspeelt. Uw boekhouding, uw offerteopvolging en uw planning verdienen elk een eigen antwoord. Eén beslissing voor het hele bedrijf is bijna altijd te grof.
Gartner heeft de klassieke tegenstelling daarom al jaren geleden geherformuleerd tot "buy and compose": niet kopen óf bouwen, maar samenstellen. U koopt verpakte, kant-en-klare capaciteiten en stelt daaruit een geheel samen dat bij uw bedrijf past. De vraag is dus niet langer "maken we het zelf?", maar "waar op het spectrum hoort dit specifieke proces thuis?".
Dat spectrum loopt van kopen, via configureren, naar automatiseren, tot bouwen. Aan de linkerkant neemt u een pakket precies zoals het is. Iets verder stelt u het in en richt u het in op uw werkwijze. Nog een stap verder verbindt u tools en legt u er een automatiserings- of AI-laag overheen. Pas aan de rechterkant bouwt u echt iets unieks van de grond af.
Met die bril vervalt de hele "bouwen vs kopen"-strijd. U vraagt niet meer wie er gelijk heeft, maar waar elk proces zit. De rest van dit artikel scoort daarom per proces — niet per bedrijf. Dat is de enige manier om recht te doen aan de werkelijkheid: het meeste hoort links, en een enkel proces verdient een plek verder naar rechts.
De 4 besliscriteria die het verschil maken
Om een proces op het spectrum te plaatsen, hoeft u geen IT-architect te zijn. Vier vragen, in gewone taal, brengen u verrassend ver. Beantwoord ze eerlijk voor elk proces dat u overweegt.
Eén: onderscheid. Wint of behoudt u hiermee klanten, of is dit hetzelfde leidingwerk dat iedereen heeft? Salarisadministratie wint geen klanten — uw concurrent doet het net zo goed. Maar de snelheid waarmee u een offerte naar buiten krijgt, kan wél het verschil zijn waarom een klant voor u kiest. Onderscheid is de belangrijkste vraag; daarover later meer.
Twee: procesfit. Hoe ver wijken uw stappen af van wat standaardtools aannemen? De meeste pakketten zijn gebouwd rond een gangbare werkwijze. Werkt u grotendeels zoals de rest, dan past een tool als een handschoen. Heeft uw proces eigenaardigheden die nergens in passen, dan begint het wringen — en dat wringen kost geld.
Drie: integratie-inspanning. Met hoeveel systemen moet dit praten, en hoe schoon zijn hun koppelingen? Een tool die netjes via een open API met uw boekhouding en CRM praat, is iets heel anders dan een tool die data alleen via export en handwerk loslaat. Hoe meer systemen en hoe rommeliger de API's, hoe duurder elke richting wordt.
Vier: veranderingssnelheid. Hoe vaak verschuiven de eisen? Hier zit het contra-intuïtieve criterium. U zou denken dat snel veranderende processen juist om maatwerk vragen, maar het tegendeel is meestal waar: hoge veranderingssnelheid pleit voor kopen. Een leverancier draagt de last van bijhouden — denk aan wijzigende belastingregels. U bouwt alleen zelf als dat veranderende ding nu net uw onderscheid ís en u de regie zelf in handen wilt houden.
Een scoremodel dat u in een middag draait
Maak van die vier criteria een gewogen scoremodel. Geef elk proces een score van 1 tot 5 per criterium, vermenigvuldig met een gewicht, en tel op. Het hele bedrijf doorlopen kost u zo niet meer dan een middag.
De gewichten zijn waar het op aankomt. Weeg onderscheid het zwaarst — keer drie. Procesfit en veranderingssnelheid krijgen een middelmatig gewicht, keer twee. Integratie weegt het lichtst, keer één. Waarom domineert onderscheid? Omdat dat de enige reden is waarom zelf bouwen ooit de moeite waard is. Iets wat iedereen heeft, kunt u beter kopen, hoe slecht het ook past; iets wat u écht onderscheidt, verdient investering, ook als de rest tegenzit. De andere criteria nuanceren, maar mogen onderscheid nooit overstemmen.
Lees de uitkomst af in drie banden. Een lage totaalscore betekent: kopen zoals het is. Een score in het midden betekent: kopen en configureren, of kopen plus een lichte automatiseringslaag als lijm ertussen. Een hoge score betekent: bouw de onderscheidende sectie — en alleen die.
Een klein voorbeeld maakt het concreet. Salarisadministratie: onderscheid 1 (×3 = 3), procesfit 5 (×2 = 10), veranderingssnelheid 1 want regels wijzigen vaak en u wilt dat niet zelf bijhouden (×2 = 2), integratie 4 (×1 = 4). Totaal laag — kopen. Een offerteopvolging op maat: onderscheid 5 (×3 = 15), procesfit 3 (×2 = 6), veranderingssnelheid 4 (×2 = 8), integratie 3 (×1 = 3). Totaal hoog — bouw die laag. Het model dwingt u onderscheid centraal te stellen en behoedt u voor bouwen uit gewoonte.
Drie uitgewerkte scenario's
Laten we drie herkenbare MKB-situaties door het model halen, zodat u ziet hoe de uitkomst kantelt.
Scenario A: boekhouding en salarisadministratie. Dit is bij uitstek commodity. Het onderscheidt u niet — geen klant kiest voor u omdat uw loonstrook mooier is. De veranderingssnelheid is hoog, maar op de verkeerde manier: belastingregels en cao's wijzigen voortdurend, en u wilt absoluut niet degene zijn die dat zelf moet bijbouwen. De procesfit met standaardpakketten is uitstekend, want vrijwel iedereen werkt volgens dezelfde fiscale logica. De uitkomst is glashelder: kopen, nooit bouwen. Een leverancier neemt de last van compliance van u over, en daar betaalt u graag voor.
Scenario B: offerteopvolging bij een dienstverlener. Hier wordt het interessant. Er zit een matige eigenaardigheid in — uw manier van opvolgen is net iets anders dan standaard — én er zit echt onderscheid in: snelheid naar offerte wint deals. Wie als eerste een doordachte offerte op tafel legt, wint vaker. De honesteoplossing is een hybride. Koop een gangbaar CRM voor de standaardregistratie, maar bouw de automatiserings- en AI-laag daar bovenop: automatische herinneringen, een lichte AI die concept-opvolgingen voorstelt, met een mens die ze controleert voor verzending. Dit is precies het terrein waar AppMakelaar het verschil maakt — lichte AI, mens in de lus, gebouwd op standaardsoftware in plaats van eronder.
Scenario C: een werkelijk ongebruikelijke kernoperatie die geen leverancier modelleert. Denk aan een nichebedrijf met een werkwijze die zo eigen is dat geen enkel pakket erbij in de buurt komt. Hoog onderscheid, slechte procesfit. Hier is bouwen het juiste antwoord — maar bewust, met open ogen. U accepteert de onderhoudsrekening die erbij hoort, omdat dit nu net uw bestaansrecht is. Geen verzonnen rendementsbeloftes; wel een heldere afweging.
De verborgen kosten van bouwen
Wie zelf bouwt, kijkt vaak alleen naar de offerte van de bouwer. Maar die prijs is de aanbetaling, niet de rekening. De echte kosten beginnen pas nadat het is opgeleverd.
Er is onderhoud. Software die leeft, moet worden onderhouden: bugs duiken op, gebruikers willen aanpassingen, en wat vandaag werkt, hapert morgen. Er is beveiliging — patches, het bijwerken van afhankelijkheden, het dichten van lekken die voortdurend worden ontdekt in de bibliotheken waarop uw bouwwerk leunt. Er is hosting, dag in dag uit, ongeacht of u de software die maand intensief gebruikt. Reken erop dat het onderhoud jaarlijks een betekenisvol deel van de oorspronkelijke bouwsom kost; het is geen randverschijnsel maar een vaste post.
Maar de moeilijkste kostenpost voor een MKB-bedrijf is menselijk. Wie begrijpt het systeem nog als de bouwer vertrekt? Dit is het bus-factor-risico: als de ene persoon die de code doorgrondt morgen onder een bus loopt — of gewoon een andere baan vindt — staat u met een black box. Het vervangen of vasthouden van die kennis is duur en kwetsbaar, en juist in een klein bedrijf is die afhankelijkheid van één persoon levensgroot.
Koppel dit aan het bewijs van McKinsey en de Universiteit van Oxford: het zijn de grote, complexe maatwerkbouwwerken waar projecten ontsporen — gemiddeld zo'n 45% over budget en zo'n 56% minder waarde dan voorspeld, gemeten over meer dan 5.400 projecten waarbij "groot" boven de 15 miljoen dollar lag. Uw bouw zit daar mijlenver onder, en dat is precies het punt: als u bouwt, bouw dan klein en smal. De klif zit aan het uiterste eind van de schaal, en daar wilt u niet naartoe kruipen.
De verborgen kosten van kopen
Eerlijk is eerlijk: ook bij kopen is de etalageprijs niet de echte rekening. Off-the-shelf software heeft zijn eigen verborgen kosten, en wie ze negeert, komt later bedrogen uit.
Begin bij de prijs per gebruiker. Een abonnement dat bij vijf medewerkers betaalbaar oogt, telt bij vijfentwintig medewerkers stevig aan — licentiekruip die meegroeit met uw succes, precies op het moment dat u het minst aan verrassingen op de kostenpost zit te wachten. Daarbovenop komen betaalde lagen en add-ons: de functie die u écht nodig hebt, zit vaak net in het duurdere pakket. En reken op aanpassings- en integratiewerk, want zelfs gekochte software praat zelden vanzelf met uw andere systemen.
Dan is er vendor lock-in. Hoe langer u een tool gebruikt, hoe dieper uw data, uw werkwijze en uw mensen erin verankerd raken. Wilt u ooit weg, dan stuit u op pijnlijke data-export, omscholing en overstapkosten die u vooraf zelden incalculeert. Ga ervan uit dat de werkelijke totale kosten hoger uitvallen dan de advertentie belooft.
Voor het EU-MKB komt er een extra dimensie bij: dataresidentie en exitvoorwaarden. Waar staat uw data, onder welk recht valt zij, en hoe makkelijk krijgt u haar terug? Lock-in is voor een Europese ondernemer niet alleen een kostenvraag maar ook een soevereiniteitsvraag. Dat kopen inmiddels de mainstream is — Eurostat meldt dat in 2025 rond de 53% van de EU-bedrijven betaalde clouddiensten gebruikte, en het CBS rapporteert dat in 2024 zo'n 71% van de Nederlandse bedrijven met 10 of meer medewerkers cloud gebruikte — maakt het niet automatisch verstandig om blind te tekenen. Mainstream betekent normaal, niet zorgeloos.
Een eerlijke TCO-vergelijking opzetten
U kunt bouwen en kopen pas eerlijk vergelijken als u beide over dezelfde looptijd en met dezelfde volledigheid naast elkaar legt. Niet met een verzonnen getal, maar met een herbruikbaar sjabloon dat ú invult met uw eigen cijfers. Neem een realistische horizon van drie tot vijf jaar — kort genoeg om overzichtelijk te blijven, lang genoeg om de ware kosten zichtbaar te maken.
Aan de bouwkant zet u op een rij: ontdekking en bouw (de eenmalige aanbetaling), hosting over de hele looptijd, onderhoud per jaar, beveiliging en updates, mensen en kennisbehoud — het vasthouden of vervangen van wie het systeem begrijpt — en de opportuniteitskosten van vertraging, want terwijl u bouwt, draait het proces nog niet.
Aan de koopkant zet u ernaast: licenties, vermenigvuldigd met de verwachte groei van het aantal gebruikers; implementatie en configuratie; integratie met uw bestaande systemen; de extra add-on-lagen die u gaandeweg blijkt nodig te hebben; training van uw mensen; en een reserve voor overstappen of exit, want ooit wilt of moet u misschien weg.
Leg die twee kolommen naast elkaar en u ziet meteen waar het break-evenpunt ligt. Kopen wint vroeg en wint op snelheid — u draait morgen, niet over een half jaar. Maatwerk verdient zichzelf pas terug na enkele jaren, en alléén als het proces stabiel genoeg is om de bouw over die jaren uit te smeren. Verandert het proces voortdurend, dan haalt u dat break-evenpunt nooit, want u blijft herbouwen. De vergelijking is daarmee geen rekenkundige truc, maar een denkmodel: het dwingt u te kijken naar het hele plaatje over jaren, in plaats van naar de prijs van jaar één.
De hybride: koop het standaardspul, bouw de rand, houd het modulair
Hier komt alles samen in de aanbevolen standaard. Koop off-the-shelf voor alles wat commodity is — boekhouding, e-mail, planning, het gangbare CRM. Bouw of automatiseer alleen de onderscheidende sectie, de dunne laag waar uw voorsprong zit. En houd het geheel modulair en via API's verbonden, zodat elk onderdeel vervangbaar blijft. Wat u vandaag koopt, kunt u morgen vervangen zonder dat het hele bouwwerk instort.
Wees over de integratie eerlijk, want daar zit de praktijk. Er is een oplopende schaal in kosten en regie. Het goedkoopst en eenvoudigst zijn native integraties — koppelingen die de leveranciers zelf al hebben gemaakt. Werkt dat niet, dan komt u uit bij iPaaS- of no-code-automatisering: platforms die tools aan elkaar knopen zonder dat u code schrijft, iets duurder maar nog steeds beheersbaar. Pas als ook dat tekortschiet, schrijft u eigen koppellijm — de duurste optie, met de meeste regie en het meeste onderhoud. Klim die ladder bewust op, stap voor stap, niet in één sprong naar boven.
Dit is waar de moderne derde weg ligt. In plaats van de onderliggende software te bouwen, bouwt u steeds vaker de wérkstroom: lichte automatisering en AI met een mens in de lus, bovenop standaardsoftware die u gewoon koopt. U schrijft geen boekhoudpakket meer; u bouwt de slimme laag die uw gekochte tools laat samenwerken zoals úw bedrijf werkt. Dat sluit naadloos aan op Gartners idee van "buy and compose": u stelt verpakte capaciteiten samen tot iets eigens, en de waarde die u toevoegt zit in de compositie en de automatiseringslaag — niet in het opnieuw uitvinden van wat al bestaat.
Valkuilen die de beslissing stilletjes verpesten
Zelfs met een goed model glijden ondernemers af in voorspelbare valkuilen. Loop deze checklist langs voordat u tekent.
Bouwen voor prestige — iets zelf maken omdat het kan of indruk maakt, niet omdat het onderscheidt. Het onderhoud en het bus-factor-risico te laag begroten, alsof de oplevering het einde van de kosten is in plaats van het begin. Trouw uit sunk cost aan een tool die u allang ontgroeid bent, omdat u er ooit in hebt geïnvesteerd. Integratie als bijzaak behandelen en pas ontdekken dat niets met elkaar praat als alles al is gekocht. Kiezen op de prijs van jaar één in plaats van op de totale kosten over meerdere jaren. Exit en lock-in negeren tot het moment dat u weg wílt en merkt dat u vastzit. En tot slot: scope creep, waarbij een "kleine bouw" gaandeweg uitdijt tot precies zo'n groot, ontsporend project dat in de statistieken belandt. Elk van deze valkuilen is op zichzelf onschuldig en juist daarom gevaarlijk — ze sluipen binnen terwijl u naar de verkeerde kant van het kompas kijkt.
Hoe u dit deze week beslist (en waar een partner past)
Wacht niet op het perfecte moment; dit kunt u deze week doen. Zet uw processen op een rij. Pak de belangrijkste vijf en scoor ze met het model uit dit artikel — onderscheid keer drie, procesfit en veranderingssnelheid keer twee, integratie keer één. Tel op en lees de banden af.
U zult merken dat de meeste processen op "kopen" landen, met hooguit één of twee op "bouw de dunne laag". Dat is geen teleurstelling maar precies de bedoeling. De eerlijke standaard voor het MKB is kopen; bouwen is de uitzondering die u met het model moet kunnen verdedigen. Wie dat omdraait, betaalt vroeg of laat de rekening.
Soms helpt een buitenstaander om die scores eerlijk in te vullen, want eigen processen ziet u zelden objectief. Daar past de rol van AppMakelaar: een gratis automatiseringsscan die per proces in kaart brengt wat commodity is en dus gekocht hoort te worden, en welke slanke laag een lichte custom- of automatiseringsoplossing verdient. EU-gehost, met een mens in de lus, gebouwd op de standaardsoftware die u al gebruikt. Geen verkooppraatje voor een groot bouwproject — juist het tegenovergestelde: een eerlijke kaart van waar zelf bouwen wél en níet de moeite waard is. Wilt u weten welke van uw processen écht een eigen laag verdienen en welke u beter gewoon koopt? Vraag een gratis automatiseringsscan aan en begin de keuze op feiten te maken.