Haris OdobasicBouw smalle go-to-market-tools, zoals een CPQ, een commissiecalculator of een territoryplanner, en koop je systems of record, dus het CRM, het ERP en het marketing automation-platform. AI-codeertools hebben smalle tools goedkoop gemaakt om te bouwen, maar een system of record brengt nog steeds integratie-, compliance- en onderhoudswerk met zich mee dat zich zelden terugverdient.
Dat is ons standpunt bij Revenue Wizards. Voor de kernplatforms zitten we stevig aan de kant van kopen. Voor de smalle, regelgebaseerde tools eromheen is bouwen elk kwartaal voor meer teams de betere deal geworden.
Waarom het debat over bouwen of kopen is veranderd
Het grootste debat in SaaS op dit moment is of je tools koopt of zelf bouwt. Voorstanders van bouwen wijzen op grote kostenbesparingen. Tegenstanders zeggen dat het riskant is en dat je niet in staat zult zijn te onderhouden wat je bouwt.
Sinds ik in tech werk, verbazen de marges van sommige SaaS-bedrijven me. SaaS Capital meldt dat de brutomarges op SaaS-licentieomzet in zijn portfolio en jaarlijkse enquête doorgaans 80% tot 85% bedragen (SaaS Capital). Veel leveranciers herinvesteren fors in groei, dus de winst is lager, maar elke extra gebruiker kost de leverancier heel weinig. Een rationele koper moet zich afvragen waarom hij daarvoor betaalt.
Ze betalen voor waarde, of waargenomen waarde. Een CRM maakt een salesorganisatie veel efficiënter dan een spreadsheet. Een marketing automation-tool automatiseert het repetitieve werk. Een CPQ helpt bij het maken van offertes. Teams stellen terecht dat deze tools tijd vrijmaken voor werk met meer waarde, en daarom betalen ze de premie.
AI zet dat paradigma onder druk. Veel mensen kunnen nu een gelijkwaardige tool bouwen, of een tool die precies bij hun use case past, voor een fractie van de kosten. Als dat klopt, brokkelt het waardeargument voor de SaaS-premie af.
Onze eigen data laat zien hoe ver dit al is. In ons onderzoek RevOps in 2026 onder 123 RevOps-professionals zei 61% dat ze eigen AI-tools bouwen. De voorbeelden die ze gaven waren praktisch, zoals quote-to-cash-systemen, CPQ, territory- en capaciteitsplanning, deduplicatie-agents, sales coaches die calls voorbereiden en deals scoren, en forecasttooling. Ik verwacht dat dat aandeel blijft stijgen naarmate modelleveranciers bouwen makkelijker maken.
Welke go-to-market-tools moet je zelf bouwen?
Er zijn tientallen go-to-market-tools die je kunt bouwen, van een partnerportaal of een commissiecalculator tot een CPQ-tool binnen Salesforce of HubSpot (uitgewerkt voorbeeld hieronder).
Door bepaalde tools zelf te bouwen kun je terugkerende licentiekosten verlagen, maar de besparing hangt af van je huidige abonnementen, je gebruik en de kosten van het bouwen en onderhouden van de vervanger. Gebruik onze calculator voor bouwen of kopen om de licentiekosten in je eigen toolstack te schatten voordat je beslist.
Een scorecard voor bouwen of kopen van RevOps-tools
Beantwoord zeven vragen voor elke kandidaat-tool. Elk antwoord wijst één kant op.
| Vraag | Wijst naar bouwen | Wijst naar kopen |
|---|---|---|
| Is het een system of record (CRM, ERP, marketing automation)? | Nee | Ja |
| Is de scope smal, met duidelijke input en output? | Ja | Nee |
| Is de logica specifiek voor hoe jij verkoopt (prijsregels, beloningsplannen, territories)? | Ja | Het is generiek |
| Doet een tool waarvoor je al betaalt het werk? | Nee | Ja |
| Gaat een benoemde persoon het na de lancering beheren en onderhouden? | Ja | Nee |
| Hoe groeien de licentiekosten over drie tot vijf jaar? | Met elke seat die je toevoegt | Vlak of beperkt |
| Hoe erg is een storing (omzetverantwoording, compliance, klanten)? | Beperkt en terug te draaien | Groot |
Twee antwoorden zijn harde stops. Is het een system of record, koop het dan. Wordt niemand er na de lancering eigenaar van, koop het dan of laat het zitten. Wijzen anders vijf of meer antwoorden naar bouwen, besteed dan een week aan een prototype en vergelijk dat met de offerte van de leverancier op totale kosten, niet op licentieprijs.
Onze Five Dots RevOps-kennisbank benadert de kostenkant op dezelfde manier. Vergelijk de total cost of ownership over meerdere jaren, inclusief licenties, interne beheer- en engineeringtijd, externe hulp en de productiviteitskosten van de verandering, niet alleen de licentieregel. Ze waarschuwt ook voor een klassieke fout, namelijk kiezen voor maatwerk omdat er toevallig engineers beschikbaar zijn. Beschikbaarheid vandaag is geen eigenaarschap voor jaren.
Drie voorbeelden van bouwen of kopen in RevOps
Een CPQ kun je meestal het best binnen je CRM bouwen. Offertelogica is smal en sowieso van jou. Of je nu een CPQ koopt of bouwt, je definieert elke prijsregel, goedkeuring en drempel zelf. Licenties per seat groeien met elke nieuwe offertemaker, terwijl een build binnen het CRM dat je al hebt vooral een eenmalige investering plus onderhoud is. De case wordt zwakker als je offerteteam klein is of je governance zwak. We behandelen de cijfers in onze uitsplitsing van de prijzen van Salesforce CPQ.
Territory- en capaciteitsplanning is vaak de moeite van het bouwen waard. Veel teams doen dit in spreadsheets die niemand vertrouwt. De logica hangt af van je segmenten, je capaciteitsmodel en je data, en daarom duikt het op tussen de interne tools die de respondenten in ons onderzoek beschreven. Een kleine app bovenop CRM-data, met een duidelijke eigenaar, verslaat vaak zowel de spreadsheet als een planningssuite die je maar één keer per jaar zou gebruiken.
Conversation intelligence koop je. Opnemen, transcriberen, CRM-updates en coaching zijn een opgelost probleem waarin leveranciers flink hebben geïnvesteerd, en de data zit al in de tool. Onze Five Dots-kennisbank is er duidelijk over en zegt dat je geen verticale tool moet nabouwen waarvoor je al betaalt. Bouw in plaats daarvan de workflow die op de output reageert, bijvoorbeeld het doorsturen van een vermelding van een concurrent naar het juiste kanaal.
Welke skills en welk team heb je nodig om GTM-tools te bouwen?
Je hebt de skills in huis nodig. Tools als Lovable, Claude Code en Codex van OpenAI helpen je deze tools te bouwen, en zelfs zakelijke gebruikers komen er ver mee, maar het is beter als ervaren operators het bouwwerk doen.
Ik zou nog verder gaan en investeren in echte engineeringcapaciteit binnen het Revenue Operations-team. Ik bedoel geen go-to-market engineer zonder programmeervaardigheden, maar een echte developer. Die mensen besparen je veel en bouwen een betrouwbare tooling-infrastructuur voor je commerciële team. Waar ze in de structuur thuishoren, behandelen we in ons RevOps-organigram voor SaaS.
Teamgrootte telt. Onder ruwweg 20 verkopers neem je waarschijnlijk geen aparte engineer aan, en kunnen je RevOps-mensen gerichte tools zelf bouwen en onderhouden. Daarboven begint een developer binnen RevOps zichzelf terug te verdienen.
Wil je werkende tools zonder eerst een team aan te nemen? Onze Forward Deployed GTM Engineers bouwen ze binnen je CRM en stack, documenteren ze en dragen ze over aan je mensen. Plan een gesprek en we vertellen je welke van je tools het waard zijn om te bouwen.
Veelgehoorde bezwaren tegen het zelf bouwen van SaaS-tools
Tegenstanders van bouwen brengen vier bezwaren in. Hier is onze kijk op elk daarvan.
Ten eerste de beveiliging. Dat argument verliest snel terrein. Low-code-, no-code- en cloudplatforms regelen nu een groot deel van de beveiligingsinrichting, en veel GTM-tools hebben dat niveau van afscherming sowieso niet nodig. Je kunt zelf hosten op je eigen infrastructuur, single sign-on inbouwen voor de relevante functies en, waar klanten dat eisen, de tool opnemen in de scope van een SOC 2-onderzoek, het rapport van de AICPA over de beheersmaatregelen van een dienstverlener op het gebied van beveiliging, beschikbaarheid, integriteit van verwerking, vertrouwelijkheid of privacy (AICPA).
Ten tweede het vertrek van mensen. Mensen maken zich zorgen over wie de tool beheert als de bouwer vertrekt. Dat is een terechte zorg, maar een kleinere dan vroeger. Huidige modellen zijn erg goed in het maken van degelijke documentatie, zodat een nieuwe collega een tool kan overnemen, en dezelfde documentatie helpt het model de tool met de juiste prompts te onderhouden en te verbeteren. Investeer vooral in een team dat deze tools kan onderhouden. Dat is op lange termijn je concurrentievoordeel.
Ten derde de complexiteit. Sommige tools zijn te complex om zelf te bouwen. Daar zit wat in, maar bijna alles kan worden gebouwd. Grote bedrijven met grote engineeringteams bouwen al decennia hun eigen kernsystemen, en er is een hele branche van maatwerksoftwarebedrijven ontstaan om die te bouwen en te onderhouden. Dat je iets kunt bouwen, betekent niet dat je het moet doen, en dat brengt ons bij wat je niet moet bouwen.
Ten vierde governance. Dit is het bezwaar dat we in ons klantwerk het vaakst zien bijten. Zodra teams gaan bouwen, zijn de risico's dubbele tools, builds op slechte brondata, inloggegevens die op de verkeerde plekken worden gedeeld, en automatiseringen die verder niemand begrijpt. De teams die dit goed doen, houden één repository aan, beheren toegang, delen context en bouwen een centrale workflowlaag, terwijl ze data- en automatiseringsdiensten daaronder nog steeds inkopen. Een slanke toolstack geldt net zo goed voor wat je bouwt als voor wat je koopt.
Wat je (nog) niet moet bouwen
Het ERP, het CRM en het marketing automation-platform zou ik voorlopig niet bouwen.
Die drie zijn systems of record. Ze zijn sterk geïntegreerd met andere platforms, en maatwerkprocessen maken ze snel complex. Salesforce, HubSpot, Xero, NetSuite en vergelijkbare leveranciers hebben flink geïnvesteerd om ze te perfectioneren. Een zelfgebouwde variant kan werken voor een klein bedrijf, maar voor een middelgroot SaaS-bedrijf of een grotere onderneming is het een zware klus. Steek de moeite liever in het datamodel van je CRM, en begin met tools die eenvoudiger zijn en meer opleveren.
Eenvoudig betekent niet altijd goedkoop. De CPQ is duur, maar die kan opnieuw worden gebouwd. Dus, bouwers, aan de slag.
Doe je het liever samen met ervaren bouwers? Plan een gesprek over onze Forward Deployed GTM Engineers.
FAQ over bouwen of kopen van SaaS-tools
Wat moet RevOps bouwen in plaats van kopen?
Bouw smalle, regelgebaseerde tools die weerspiegelen hoe je verkoopt, zoals een CPQ binnen je CRM, een commissiecalculator, territory- en capaciteitsplanning of deduplicatie- en verrijkingsagents. Koop systems of record en elke tool die je stack al afdekt.
Is het goedkoper om je eigen SaaS-tools te bouwen met AI?
Vaak wel, maar niet vanzelf. Bouwen schrapt licentiekosten per seat, maar je neemt bouwtijd, hosting en onderhoud op je. Vergelijk de totale kosten over drie tot vijf jaar, inclusief de persoon die eigenaar van de tool wordt.
Moeten we ons eigen CRM bouwen?
Nee, voor de meeste bedrijven niet. Een CRM is een system of record met diepe integraties, rechten, rapportage en compliance-eisen, en een zelfgebouwd CRM eindigt meestal als een zwakkere versie van het platform dat je had kunnen kopen.
Wie moet maatwerk-GTM-tools bouwen en onderhouden?
Iemand binnen het commerciële team die er elke dag is, idealiter een engineer binnen RevOps. Externe bouwers kunnen de eerste versie maken, maar een benoemde interne eigenaar moet hem onderhouden naarmate prijzen, producten en processen veranderen.
Hoe kies je tussen bouwen en kopen?
Gebruik een korte scorecard. Die vraagt of het een system of record is, hoe smal de scope is, hoe specifiek de logica is, of een huidige tool het al doet, wie eigenaar wordt, hoe de licentiekosten groeien en wat een storing kost. Systems of record en tools zonder eigenaar zijn harde stops voor bouwen.
