Bouwen of kopen: de echte TCO van een commissie-tool

Op enig moment in elke MKB-organisatie komt de vraag op: laten we het zelf bouwen? Een ontwikkelaar in dienst, of een freelancer, een paar weken werk en je hebt iets dat precies past bij jouw situatie. Geen SaaS-fee, geen vendor-afhankelijkheid, eigen baas.

We hebben deze afweging in praktijk meermaals zien gebeuren. Bij commissie-tools komt het bouw-of-koop-vraagstuk veel vaker voor dan bij ERP of CRM, omdat de wens “het moet precies zo werken zoals wij het kennen” sterk is, en omdat de eerste schets van een eigen tool bedrieglijk eenvoudig lijkt. Hieronder de werkelijke TCO over drie jaar, met de kostenposten die in de eerste pitch zelden worden genoemd.

De aantrekkelijke pitch

“Een commissie-tool is in principe niet ingewikkeld. Een tabel met regels, een formule, een dashboard. Met een freelancer en wat tijd bouwen we het in zes weken. Geen SaaS-licenties, geen vendor-lock-in, en het past precies bij ons.”

Op papier klopt het. De berekening zelf, verkoopwaarde keer commissie, eventueel met een staffel, is geen rocket science. Een ervaren ontwikkelaar bouwt de eerste versie inderdaad in een paar weken. Probleem is dat die eerste versie pas het begin is van wat een werkbare commissie-tool moet zijn.

Wat de pitch weglaat

Integratie met je ERP

Verkoop, marges en betalingen zitten in Exact. Een eigen tool die daar niet aan gekoppeld is, vraagt handmatige import, wat het Excel-probleem nog erger maakt. Een echte koppeling met Exact betekent OAuth-flow, refresh-token-management, error-handling op rate limits, omgaan met data-mutaties (een factuur die wordt gecorrigeerd of geannuleerd), en multi-administratie-ondersteuning. Dit is geen weekendwerk; dit is de kern van het systeem.

Audit-trail en compliance

Een commissie-uitbetaling moet later traceerbaar zijn, voor de accountant, voor interne controle, voor discussies. Dat betekent dat elke wijziging in regels, tarieven, en uitbetalingen logmatig wordt vastgelegd. Geen “we hebben het toen aangepast”, maar een immutable audit-trail. In een MVP wordt dit altijd onderschat; bij eerste accountantcontrole wordt het pijnlijk duidelijk dat het ontbreekt.

Drie verschillende rollen, drie verschillende zichten

Sales-agent, manager en finance hebben elk een ander perspectief op dezelfde data. Sales wil zijn eigen open commissie zien. Manager wil team-prestatie en regel-beheer. Finance wil uitbetaalkalender en boekhoudkundige integraties. Drie rollen, drie UI-flows, drie sets permissies. In de eerste schets wordt dit altijd “voor later”, en “later” wordt zelden gehaald.

Onderhoud zonder dat de bouwer er nog is

De freelancer levert af, de tool werkt, en zes maanden later komt een wijziging in de commissie-regels. De ontwikkelaar is bezig met andere klanten en niet beschikbaar. Of erger: hij is van baan veranderd. Dan moet iemand anders zich inwerken in code die niet voor onderhoud is geschreven, met documentatie die zelden bestaat. Wat begon als een eigen tool, wordt een legacy-systeem.

Beveiliging en data-bescherming

Een commissie-tool bevat persoonsgegevens (agent-data, salarissen) en bedrijfsgevoelige informatie (marges per klant). AVG-eisen, rolgebaseerde toegang, audit-logging op data-toegang, backup en recovery, dit zijn geen “nice to haves”. Bij een datalek of accountants-controle moet dit aantoonbaar in orde zijn. In een zelfgebouwde tool is dit zelden de kerngedachte van de eerste versie.

De TCO over drie jaar

Realistische schatting voor een MKB-handelsbedrijf met tien sales-agenten dat zelf bouwt:

• Initiele bouw: 6 tot 12 weken werk, freelancer of intern ontwikkelaar. Realistisch 35.000 tot 70.000 euro.
• Onvoorziene scope: Audit-trail, multi-rollen-UI, ERP-koppeling, error-handling. Toegevoegde 4 tot 8 weken werk in jaar 1. Voeg toe: 25.000 tot 50.000 euro.
• Onderhoud per jaar: Bug-fixes, ERP-API-veranderingen, regel-aanpassingen, security-patches. Realistisch 8 tot 12 uur per maand bij een externe ontwikkelaar (€90 tot €130 per uur). Per jaar: 9.000 tot 18.000 euro.
• Schaal-werk: Bij een belangrijke wijziging (nieuwe regel-structuur, extra rol, andere ERP) circa 2 tot 4 weken werk. Eens per twee jaar: gemiddeld 12.000 euro per jaar.

TCO over drie jaar bij eigen bouw: realistisch 90.000 tot 170.000 euro. Plus de tijd van je interne mensen die de specs vaststellen, bugs rapporteren, en helpen met testen.

Vergelijking met SaaS

Een SaaS-tool zoals Kresio kost in dezelfde periode bij tien agenten en een Growth-plan circa 250 euro per maand of 3.000 euro per jaar, over drie jaar 9.000 euro. Geen onderhoudswerk, geen ERP-API-issues, geen security-overwegingen aan jouw kant. Updates en uitbreidingen komen automatisch.

Het verschil tussen 90.000 en 9.000 over drie jaar is geen kleine marge: het is een factor tien. En in die factor tien zit niet alleen de bouwkosten, het zit in de tijd van je team, de risico’s, en de ondersteuning bij groei.

Wanneer eigen bouw wel klopt

Eigen bouw is niet altijd onverstandig. Het klopt wanneer:

• Je commissie-logica is fundamenteel anders dan alles op de markt, bijvoorbeeld een specifieke industrie met unieke regels.
• Je hebt al een ontwikkelteam dat dit als deel van hun bredere werk kan opnemen, niet als losstaand project.
• De koppeling moet precies zo dat geen enkele generieke tool het kan doen.

Voor 95 procent van de MKB-handel valt geen van deze condities. Een SaaS-tool past precies, kost een tiende, en is direct beschikbaar.

Conclusie

De pitch “we bouwen het zelf, dat is goedkoper” houdt geen stand bij realistische TCO-berekening. Wat aanvankelijk een tool van twee maanden lijkt, wordt over drie jaar een meervoud aan kosten, en je krijgt er een legacy-systeem voor terug dat niemand wil onderhouden.

Wil je zien wat een SaaS-tool je oplevert? Bekijk de tarieven, of lees de complete gids voor het achterliggende denken.