35% van de teams heeft een SaaS-tool vervangen door maatwerksoftware. Jij ook?

Begin februari veegde een productupdate van Anthropic op één dag miljarden van de beurswaarde van enterprise-softwareaandelen. Handelaren noemden het de SaaSpocalypse: de markt prijsde even een wereld in waarin bedrijven stoppen met software kopen en beginnen met bouwen. Twee weken later publiceerde Retool zijn Build vs. Buy-rapport voor 2026, en de enquêtedata bevestigden de stemming. Van de 817 ondervraagde builders had 35% al minstens één SaaS-tool vervangen door iets zelfgebouwds, en 78% is van plan dit jaar meer te bouwen.

Wij bouwen maatwerksoftware voor de kost, dus je zou verwachten dat we juichen. Meestal krimpen we ineen. Wat het rapport eigenlijk beschrijft is een golf van snel en grotendeels ongecontroleerd bouwen, die een aantal echte successen zal opleveren en een hoop verlaten tools die niemand onderhoudt. In welke groep jij belandt, wordt bepaald voordat iemand een prompt typt.

Wat het rapport echt zegt

Eerst de kanttekening die de persberichten overslaan: Retool ondervroeg eind 2025 zijn eigen klanten en builders, 817 in totaal. Dit zijn mensen die al een platform voor het bouwen van tools hadden gekocht. Hun vragen of ze graag tools bouwen is een beetje als een sportschool polsen over bewegen. De richting is informatief; de exacte percentages neem je met een korrel zout.

Met dat filter erop zeggen de bevindingen nog steeds genoeg. Elke SaaS-categorie staat onder vervangingsdruk: workflow-automatiseringen (35%) en interne beheertools (33%) lopen voorop, met BI-tools op 29%, CRM's en formulierbouwers op 25%, projectmanagement op 23%, klantsupport op 21%. De casestudy's zijn concreet. ClickUp bouwde zes interne AI-tools en bespaarde $200K per jaar op automatiseringssoftware. Harmonic was een tool van $20,000 per jaar beu waarvan de support trager was dan het product zelf herbouwen, dus herbouwden ze het, en nu draaien er 33 interne apps.

En dan de statistiek die je zou moeten afremmen: 60% van de builders leverde het afgelopen jaar iets op buiten het toezicht van IT om. Gevraagd naar het waarom zeiden ze dat ze sneller konden bouwen dan IT kon inkopen (31%), dat de bestaande SaaS niet deed wat ze nodig hadden (25%), of dat het proces van IT simpelweg te traag was (18%). Dit zijn geen stagiairs met een weekendproject; 64% van de respondenten was senior manager of hoger.

Waarom de rekensom kantelde

Twintig jaar lang was de build-vs-buy-berekening stabiel. Bouwen betekende engineers aannemen, twee kwartalen wachten en het onderhoud voor altijd op je nemen. Kopen betekende een creditcard. Voor alles wat niet je kernproduct was, won kopen standaard, en meestal was dat de juiste keuze.

AI heeft die berekening niet bijgesteld. Het heeft één kant ervan omvergegooid. Een werkende interne tool (een dashboard, een goedkeuringsworkflow, een CRM-achtig ding dat past bij je net iets eigenaardige salesproces) is nu dagen werk, soms uren. Als het bouwen zo weinig kost, is een abonnement van $15,000 voor software die je team half gebruikt geen veilige standaard meer, maar een kostenpost waar iemand vraagtekens bij zou moeten zetten.

Maar let op wat het abonnement wél had: een prijskaartje. Je wist wat het kostte. Een maatwerkbouw verstopt zijn kosten op plekken waar finance niet kijkt, en dat is precies waar dit bij veel bedrijven op dit moment misgaat.

Het deel dat niemand begroot

Hetzelfde rapport noemt de grootste organisatorische blokkades voor automatisering: onduidelijke ROI (33%), budget (30%), onderhoudslast (26%). En 35% van de organisaties heeft helemaal geen metrics voor AI-productiviteit opgesteld. Leg die naast elkaar en je krijgt het ongemakkelijke beeld: bedrijven ruilen meetbare abonnementen in voor ongemeten interne tools, op grote schaal, vaak zonder dat IT weet dat de tool bestaat.

We schreven al eerder over het Maand 3-probleem in AI-ondersteunde ontwikkeling: het prototype komt snel en voelt als magie, en de rekening valt rond maand drie op de mat, wanneer het ding ineens authenticatie, rechten, auditlogs en iemand met piketdienst nodig heeft. Interne tools volgen dezelfde boog. De ops-lead die het dashboard bouwde wisselt van team. De API waarop het leunt verandert van vorm. Niemand anders kan de gegenereerde code lezen. En nu draait een flink stuk van je revenue operations op een tool met een busfactor van één.

Live gaan met een vibe-coded oplossing is uitgesloten. Voor demo's werkt het misschien, maar wij bouwen technologie van enterprise-niveau die moet schalen over 30 landen.

Dat citaat is van Pierre Yves Calloc'h van Pernod Ricard, in hetzelfde Retool-rapport dat de bouwgolf viert. Beide dingen zijn tegelijk waar. Het bouwen is echt en de successen zijn echt, en de lat voor productie is geen centimeter verschoven.

Er is een precedent voor hoe dit afloopt als je de meting overslaat. Gartner voorspelt dat de helft van de bedrijven die klantenservicemedewerkers schrapten voor AI, die rollen tegen 2027 weer aan het invullen is. Software kan dezelfde lus volgen: zeg het abonnement op, geniet van de demo, en sluit na achttien maanden stilletjes weer een abonnement af zodra de interne tool wegrot. Retools eigen rapport zegt het treffend: vervanging zonder meting is gewoon churn.

Een kort beslissingskader

Vervang wanneer de tool generiek is en je proces dat niet is. De categorieën bovenaan de druklijst (workflow-automatisering, intern beheer, dashboards) zijn vooral dunne softwarelagen over je eigen data. Betaal je voor honderd seats en gebruik je er twaalf, of betaal je voor tweehonderd features en gebruik je er negen, dan wint passendheid het van features en wint maatwerk. Het verhaal van Harmonic is de blauwdruk: zodra het abonnement meer kost aan omwegen dan de bouw in totaal zou kosten, ga je bouwen.

Blijf kopen wanneer je proces niet bijzonder is (salarisadministratie, boekhouding, e-mail), wanneer compliance het eigenlijke product is, of wanneer de waarde in het ecosysteem van de leverancier zit in plaats van in zijn schermen. Niemand zou zelf het systeem in elkaar moeten knutselen dat hem HIPAA-compliant houdt om $400 per maand te besparen.

En wat je ook bouwt, maak het bewust saai: een echte repository, toegangsbeheer, foutmonitoring, een eigenaar wiens naam iedereen kent, en één cijfer dat je bijhoudt: bespaarde uren, gesloten tickets of geschrapte dollars. Dat is het hele verschil tussen een asset en een last. De Retool-data laat zien dat builders dit instinctief al begrijpen: 72% van de mensen die echte software opleveren gebruikt AI om stukken code te schrijven die ze testen en integreren, terwijl maar 31% zich een weg prompt naar complete apps. Productiesoftware leeft in de eerste groep.

Die kloof tussen een geprompt prototype en een tool waar je bedrijf op kan bouwen, is waar teams zoals het onze worden binnengehaald, meestal rond maand drie. Het prototype is geen verspild werk, laat dat duidelijk zijn. Een vibe-coded tool die je ops-lead bouwde en die het hele team al gebruikt, is het beste requirementsdocument dat we ooit in handen kregen. Het is alleen niet het eindproduct, en het zo behandelen is hoe de heraboneer-lus begint.

Dus, moet je het doen? Als een tool op de lijst met hoge vervangingsdruk duur is, half wordt gebruikt en om je eigen data heen is gebouwd: waarschijnlijk wel, en de economie kantelt alleen maar verder die kant op. Beantwoord alleen één vraag voordat je iets opzegt: wie is hier in maand drie de eigenaar van? Is er een naam, bouw dan. Is er een schouderophalen, blijf dan betalen.