Door Roy Van Eijsselsteijn, CEO van Interactivated
Elk jaar valt de verlengingsfactuur net wat hoger uit. Vroeg of laat vraagt iemand in het bedrijf zich dan hardop af: is het niet goedkoper om eigen software te laten bouwen? Stijgende SaaS kosten maken dat een terechte vraag, en soms is het antwoord echt ja. Maar eigen software wint alleen van abonnementen als je aantal seats, prijsstijgingen of de aansluiting op je proces de doorslag geven. En het brengt ook zijn eigen risico's mee. In dit artikel zetten we beide kanten eerlijk op een rij: wat elke route echt kost, hoe je het break-even punt berekent en hoe je voorkomt dat je de ene lock-in inruilt voor de andere.
Wat kosten SaaS-abonnementen echt?
De prijs op de website van een leverancier is meestal het kleinste deel van wat software abonnementen je uiteindelijk kosten. Wil je eerlijk vergelijken, tel dan voor elke tool die je gebruikt elke post hieronder mee:
- De prijs per seat. Dat is de maandprijs per gebruiker, vermenigvuldigd met iedereen die een login heeft, ook collega's die alleen maar hoeven mee te kijken.
- Abonnementsniveaus. Als je maar één functie uit een hoger niveau nodig hebt, kan je hele account een niveau omhoog gaan, en elke seat gaat mee.
- Add-ons. Extra modules, opslag, contacten of gebruikscredits worden vaak bovenop de basisprijs gefactureerd.
- Koppelingen. Wil je data tussen systemen uitwisselen, dan heb je meestal connectortools nodig, en die hebben hun eigen abonnementen.
- Beheertijd. Iemand is uren kwijt aan instellingen, gebruikersbeheer, workflows en het repareren van koppelingen die na een update stuk gingen.
- Licentiekosten software bij verlenging. De leverancier bepaalt de licentiekosten, en die kunnen bij elke contractverlenging veranderen.
Wat hoort er dan in het totaal? Elke post hierboven, per jaar, voor elke tool die hetzelfde werk doet of dezelfde data bevat. Dat laatste telt zwaarder dan de meeste mensen denken. Overlappende tools zie je heel vaak, en goed saas management begint altijd met een volledige lijst: waarvoor betaal je en wie gebruikt het echt?
Wat kost eigen software?
Eigen software, of maatwerk software, ruilt een maandelijks abonnement in voor bouwkosten vooraf en daarna kosten voor beheer. Voor een eerlijke vergelijking moeten ze allebei in je som:
- Bouw. Het ontwerp, de ontwikkeling, het testen en de datamigratie die nodig zijn voor de eerste versie.
- Hosting. De servers of clouddiensten waarop de software draait, inclusief back-ups en monitoring.
- Onderhoud. Frameworks en libraries up-to-date houden, bugs oplossen en onderweg kleine verbeteringen doorvoeren.
- Beveiliging. Patches doorvoeren, testen op kwetsbaarheden en beheren wie waar toegang toe heeft.
- Support. Hulp voor je gebruikers, en iemand die je kunt bellen als er iets stukgaat.
- Productownership. Iemand in je bedrijf die bepaalt wat er als volgende wordt gebouwd en de software laat aansluiten op hoe het team echt werkt.
Eén punt vergeet je makkelijk als je enthousiast bent over bouwen: de kosten voor beheer worden nooit nul. Software waar niemand naar omkijkt, wordt langzaam een risico. Wil je zien hoe wij bouw, hosting en onderhoud als één product behandelen, lees dan meer over SaaS ontwikkeling.
AI-ondersteunde ontwikkeling maakt bij het bouwen echt verschil. Senior engineers die met AI-tooling werken, schrijven merkbaar sneller werkende code. Wat het niet wegneemt: de kosten voor beheer, het beveiligingswerk en de noodzaak van een producteigenaar.
Total cost of ownership: zo bereken je het break-even punt
De total cost of ownership van software is alles wat je betaalt om een systeem aan te schaffen, te laten draaien en uiteindelijk weer te verlaten, over de hele levensduur, niet alleen het prijskaartje. Daarop vergelijk je beide routes, over dezelfde periode. Een termijn van drie tot vijf jaar geeft meestal een realistisch beeld.
| Kostenpost | Route A: abonnementen | Route B: eigen software |
|---|---|---|
| 1. Start | Onboarding- en opstartkosten (O_A) | Bouw van de eerste versie (B) |
| 2. Gebruik | Seats × prijs per seat × 12 (S × P × 12) per jaar | Hosting per jaar (H) |
| 3. Extra's | Add-ons, abonnementsniveaus en connectortools per jaar (X) | Onderhoud en beveiliging per jaar (M) |
| 4. Mensen | Beheeruren × uurtarief per jaar (A_A) | Uren voor productownership × uurtarief per jaar (A_B) |
| 5. Overstap | Vertrekkosten als je weggaat (E_A) | Datamigratie naar het nieuwe systeem (D) |
Over N jaar zien de totalen er zo uit:
TCO_A = O_A + N × (S × P × 12 + X + A_A) + E_A
TCO_B = B + D + N × (H + M + A_B)
Eigen software loont als TCO_B lager uitkomt dan TCO_A. Vul de tabel het best rij voor rij in, met echte cijfers uit je facturen en uit de offertes die je ontvangt. Wees hier streng voor jezelf: zet niets op nul, tenzij het echt nul is.
Een concreet voorbeeld: neem één tool, bijvoorbeeld je huidige CRM. Zet de factuur van vorig jaar onder rij 2 en 3, maak een eerlijke schatting van de beheeruren voor rij 4 en vraag een bouwer om B, D, H en M te offreren. Een uitgewerkt voorbeeld voor een CRM lees je in ons artikel over de keuze tussen een CRM op maat en HubSpot.
Wat gebeurt er met de uitkomst als je team groeit of prijzen stijgen
Het break-even punt is geen vast getal. Het verschuift als je bedrijf verandert, dus maak de som opnieuw voor elk van deze scenario's en kijk welke kant het op gaat:
- Je team groeit. Elke nieuwe collega maakt het abonnement duurder, elke maand. De kosten van eigen software veranderen nauwelijks met het aantal mensen, dus groei verschuift de uitkomst richting bouwen.
- De leverancier verhoogt zijn prijzen. Een hogere prijs per seat, of een gedwongen overstap naar een hoger niveau, maakt route A duurder voor elk resterend jaar. Ook dat verschuift de uitkomst richting bouwen.
- De scope van de bouw verdubbelt. Moet de eerste versie ineens twee keer zoveel kunnen, dan groeit B mee, en een deel van M ook. Dat verschuift de uitkomst terug richting abonnementen.
- Je team krimpt. Met minder seats wordt route A goedkoper, terwijl route B ongeveer gelijk blijft. Bouwen is dan moeilijker te rechtvaardigen.
Wat wij hieruit leren is simpel. Eigen software is het gevoeligst voor scope. Abonnementen zijn het gevoeligst voor het aantal mensen en de prijs. Houd je de eerste build klein, dan blijft je businesscase het best overeind.
Vendor lock-in: wat het is en wat vertrekken kost
Vendor lock-in bij software betekent dat vertrekken bij een product je zoveel tijd, geld of data zou kosten dat je blijft, ook als het niet meer bij je past. Het gebeurt zelden van de ene op de andere dag. Het sluipt er langzaam in, op drie manieren:
- Beperkte export. Je records kun je meestal exporteren, maar niet altijd de historie, bijlagen, relaties of automatiseringslogica. Een deel van wat je hebt opgebouwd, gaat simpelweg niet mee.
- Eigen workflows van de leverancier. Je automatiseringen, scripts en rapportages zitten in de tools van de leverancier zelf, en die moet je elders vanaf nul opnieuw bouwen.
- Prijsmacht bij verlenging. Zodra je processen van een tool afhangen, weet de leverancier dat overstappen duur voor je is. Daardoor sta je bij elke verlenging stilletjes zwakker.
Hoe langer je een tool gebruikt, hoe afhankelijker van je softwareleverancier je op deze manier wordt. Dat is geen reden om SaaS helemaal te vermijden. Het is wel een goede reden om de vertrekkosten (E_A in de formule hierboven) in je som op te nemen, en om de exportmogelijkheden te controleren voordat je iets tekent.
Lock-in bij eigen software: wat je contractueel regelt
Eigen software kan een nieuwe vorm van vendor lock-in opleveren: afhankelijkheid van het bedrijf dat het heeft gebouwd. Als alleen zij de code begrijpen, zit je net zo vast als bij een SaaS-leverancier. Het goede nieuws is dat je dit makkelijk voorkomt als je het vooraf regelt. Spreek deze punten met elke bouwer af, ook met ons:
- Eigendom van de code. In het contract staat dat de broncode en het datamodel van jou zijn, inclusief elke toekomstige wijziging.
- Toegang tot de repository. De code staat in een repository die van jou is, of waar je op elk moment bij kunt, en niet alleen op de systemen van de bouwer.
- Documentatie. De architectuur, het datamodel, de deployment en de koppelingen zijn goed genoeg gedocumenteerd om een ander team het werk te laten overnemen.
- Hosting op jouw naam. Servers, domeinen en cloudaccounts staan op naam van je bedrijf, of kunnen zonder voorwaarden aan je worden overgedragen.
- Overdrachts- en exitvoorwaarden. Het contract beschrijft wat er gebeurt als je ooit van bouwer wisselt: wat er wordt overgedragen, in welke vorm en binnen welke termijn.
Met deze afspraken wordt het risico op lock-in bij de bouwer klein. Zonder die afspraken kan je eigen software zelfs moeilijker te verlaten zijn dan welk abonnement ook.
Wanneer eigen software niet loont
Als bedrijven SaaS of maatwerk tegen elkaar afwegen, is het eerlijke antwoord vaak gewoon: kopen. Eigen software loont zelden in deze situaties:
- Je team is klein. Een handvol seats kost per jaar minder dan een eigen systeem draaiende houden.
- Je behoefte is standaard. Past een bestaande tool al bij hoe je werkt, dan kost opnieuw bouwen alleen geld, zonder dat het iets oplevert.
- Niemand kan eigenaar van het product zijn. Zonder iemand die prioriteiten stelt, en een onderhoudsafspraak daarachter, raakt je eigen software achterop en wordt het een risico.
Herken je een van deze situaties? Dan kun je beter de tools die je al hebt opschonen en de overlappende tools opzeggen. Dat alleen kan al meer besparen dan je verwacht.
Zo begin je klein: één tool vervangen als pilot
De veiligste manier om je businesscase te testen, is één tool vervangen, niet je hele stack in één keer. SaaS sprawl groeit abonnement voor abonnement, en zo kun je het ook terugdringen.
- Kies de tool. Kies de tool die het meest kost en het slechtst past: een hoge rekening, veel workarounds en data die nog steeds met de hand wordt overgetypt.
- Meet de nulmeting. Schrijf op wat die tool nu kost, met de kostenposten hierboven, en hoeveel tijd het team aan workarounds kwijt is.
- Baken de pilot af. Beperk de pilot tot de workflows die het team elke dag gebruikt. Dat is de MVP-aanpak: de kleinste versie die nog steeds het echte werk doet. Lees meer over MVP development.
- Laat de pilot naast de oude tool draaien. Gebruik beide een vaste periode naast elkaar en vergelijk de resultaten voordat iemand definitief overstapt.
- Vergelijk met de nulmeting. Zijn kosten, tijd en fouten gedaald? Zeg dan het abonnement op en bepaal welke tool de volgende is.
Werkt de pilot, dan kun je het platform vanaf daar stap voor stap uitbreiden. Hoe je van meerdere pakketten naar één platform gaat, lees je in onze gids over een nieuw ERP of één eigen platform.
Veelgestelde vragen
Je betaalt voor het bouwen van de eerste versie en het migreren van je data, en daarna jaarlijkse kosten voor hosting, onderhoud en productownership. Zet dat met de total cost of ownership-tabel hierboven naast wat je nu betaalt. Wil je vooral je softwarekosten verlagen, dan zie je in die vergelijking ook of bouwen de betere route is, of gewoon je huidige tools opschonen.
Zorg dat je eigenaar bent van de code, het datamodel en de repository, dat het systeem goed gedocumenteerd is en dat de hosting op naam van je bedrijf staat. Leg daarna duidelijke overdrachtsvoorwaarden vast in het contract.
Dat hangt af van de scope van de eerste versie en van hoeveel data je moet migreren. Door met één tool te beginnen, houd je die eerste stap klein en overzichtelijk.
Met eigendom van de code, toegang tot de repository en documentatie kan een ander team het werk overnemen. Zonder die afspraken is dit een echt risico, dus zorg dat het geregeld is voordat je begint.
Ja, en dat is de route die we aanraden. Vervang één tool als pilot, meet het resultaat en bepaal vanaf daar de volgende stap.
Zo pakken wij dit aan bij Interactivated
Als een bedrijf met deze vraag bij ons komt, beginnen we niet over wat we zouden kunnen bouwen. We beginnen met de cijfers. Samen zetten we de tools op een rij waarvoor je betaalt, bekijken we de echte facturen en vullen we de kostenposten uit dit artikel in met echte bedragen, inclusief de beheeruren die nooit op een factuur staan.
Is bouwen zinvol, dan zoeken we de ene tool die het meest kost en het slechtst past, en bakenen we een pilot af rond de workflows die je team elke dag gebruikt. Die pilot draait een tijdje naast de bestaande tool, zodat je het verschil kunt meten voordat iemand hoeft over te stappen.
Onze senior engineers bouwen met AI-tooling, waardoor we sneller een werkende eerste versie opleveren. Elk onderdeel wordt nog steeds gereviewd door ervaren engineers, omdat het datamodel en de beveiliging bepalen of de software over jaren nog makkelijk te onderhouden is.
We maken ook vooraf afspraken over eigendom: de code, de repository en de documentatie zijn van jou, dus ook aan ons zit je nooit vast. Na de lancering zorgen wij dat de software gehost, bijgewerkt en veilig blijft, en ontwikkelen we hem samen met je verder. En als onze eerlijke conclusie is dat een abonnement je beter helpt, dan zeggen we dat ook gewoon.
Je businesscase samen opstellen
Wil je weten of eigen software voor een van je tools zou lonen? We lopen graag samen de kostenposten door, kiezen een verstandige pilot en laten zien wat er nodig is om die te bouwen en te laten draaien. Blijft een abonnement de betere keuze, dan zeggen we dat ook. Plan een gesprek over één pilottool.

