Moet je bedrijf in 2026 zijn eigen interne software bouwen? (Wij deden het)

Ja. In 2026 is de beslissing om als bedrijf je eigen interne software te bouwen een verdedigbare financiële keuze, geen prestigeproject. We kunnen dat met een strak gezicht beweren omdat we er het afgelopen jaar zelf mee bezig zijn geweest: onze blog, kennisbank, release notes, enquêtes, nieuwsbrieven en het bijhouden van evenementen draaien allemaal op een platform dat we zelf hebben gebouwd. Het volledige antwoord heeft echter een tweede helft. Bouw de tools. Koop de infrastructuur. De meeste spijt bij deze beslissing komt voort uit het verwarren van die twee.

Waarom is de verhouding tussen zelf bouwen of kopen gekanteld voor interne tools?

Omdat de kosten voor het bouwen zijn gekelderd, terwijl de kosten voor huren bleven stijgen. Het gemiddelde bedrijf gebruikt nu 106 SaaS-applicaties (abonnementssoftware, maandelijks of jaarlijks betaald)¹, en de wereldwijde uitgaven aan SaaS zouden in 2025 naar verwachting 299 miljard dollar bereiken, tegenover ongeveer 251 miljard dollar het jaar daarvoor². Deze cijfers zijn nauwkeurig op het moment van publicatie; beschouw de details als een momentopname van een snel veranderende markt.

Elk van die abonnementen was op een gegeven moment goedkoper dan het in-house bouwen ervan. Die rekensom ging ervan uit dat bouwen betekende dat je een kwartaal lang ontwikkelaars moest inhuren. AI-codegeneratie heeft die aanname doorbroken: een interne tool die voorheen een maandenlang ontwikkelingsproject was, kan nu vaak in een paar dagen worden gerealiseerd door te prompten, te controleren en aan te passen. De abonnementskant van de balans kreeg geen vergelijkbare korting. Prijzen per gebruiker straffen je nog steeds af als je mensen aanneemt, en de functie die je nodig hebt, bevindt zich nog steeds net één niveau boven het abonnement waar je voor betaalt.

Dat maakt bouwen niet gratis. Het maakt bouwen wel goedkoop genoeg om de vergelijking eindelijk eens te maken.

Wat hebben we eigenlijk gebouwd?

We zijn een point-of-sale-bedrijf en we zijn begonnen waar de pijn het grootst was: content. Onze oude workflow voor de kennisbank betekende dat we hulpartikelen in een gedeeld document opstelden en vervolgens elke wijziging kopieerden en plakten in een helpdesktool waarvan de zoekfunctie niet in ingeklapte secties kon zoeken. Om dat op te lossen, moesten we ons eigen contentplatform bouwen. Toen dat er eenmaal was, verhuisden de blog, release notes, enquêtes, nieuwsbrieven en e-mailcampagnes daar ook naartoe, en in juni 2026 hebben we afscheid genomen van WordPress.

Sinds die tijd is de lijst blijven groeien: het bijhouden van evenementen, een tool voor het maken van offertes, een in-app chatwidget. De volgende op de lijst zijn de abonnementen voor marketingautomatisering, CRM (customer relationship management) en projectmanagement. Elke tool werd gebouwd wanneer de gekochte versie tekortschoot bij een specifieke, aanwijsbare workflow.

Twee kanttekeningen van binnenuit. Ten eerste was het niet gratis: onze oprichter en ontwikkelaars hebben hier echt tijd aan besteed, en die tijd had ook anders gebruikt kunnen worden. Ten tweede is elke tool die je bouwt voor altijd van jou. De bugs zijn van jou, de back-ups zijn van jou en er is geen supportlijn om te bellen, want jij bent de supportlijn. We hebben die afweging met open ogen gemaakt. Dat zou jij ook moeten doen, of je moet blijven kopen.

Welke software moet je nog steeds kopen?

Alles waarbij een fout geld kost of juridische risico's met zich meebrengt. Betalingsverwerking (het verplaatsen van kaarttransacties, gereguleerd door PCI-compliance, de beveiligingsstandaard van de kaartindustrie) staat bovenaan de lijst, gevolgd door belastingberekening, loonadministratie en je boekhoudsysteem (de bron van de waarheid waar al het andere mee wordt afgestemd). Met AI bouwen is handig voor de tool-laag: formulieren, dashboards, trackers, planners, contentsystemen. Het is niet geschikt voor infrastructuur die onder reële belasting altijd foutloos moet werken. Diezelfde kloof wordt zichtbaar wanneer mensen vragen of ze een POS kunnen bouwen met een algemene AI-appbouwer.

Distributie hoort bij dezelfde rekensom. Interne tools draaien in de browser en zijn direct live zodra je ze implementeert. Alles wat een vermelding in een app store nodig heeft, krijgt te maken met wekenlange beoordelingsprocessen die niet door AI zijn verkort.

We hebben hier onze eigen regel gevolgd. We hebben contenttools en trackers gebouwd bovenop de commerce-infrastructuur die we al gebruiken, and we hebben de betalingsinfrastructuur niet opnieuw gebouwd. We zouden je dat ook ten zeerste afraden.

Hoe beslis je wat je als eerste gaat bouwen?

Drie vragen hebben onze lijst goed gefilterd:

• Als deze tool op een dinsdag kapotgaat, is dat dan een ongemak of een ramp? Bouw de ongemakken eerst.

• Schiet de gekochte versie tekort bij een specifieke, aanwijsbare workflow? "De factuur irriteert me" is geen specificatie. "De zoekfunctie kan de helft van onze artikelen niet vinden" wel.

• Wie is er over een jaar de eigenaar van? Elke interne tool heeft één persoon nodig die er verantwoordelijk voor is. Geen eigenaar, niet bouwen.

Het voor de hand liggende bezwaar: dit is makkelijk praten voor een softwarebedrijf. Terecht. Maar de tools die we als eerste hebben vervangen, waren de minst technische: content, enquêtes en planning, meestal gespecificeerd door mensen die zelf geen productiecode schrijven. De werkelijke vereiste is specifieker dan 'een softwarebedrijf zijn'. Iemand binnen het bedrijf moet kunnen zien wanneer de tool fouten maakt, en kunnen beoordelen wat de AI heeft geproduceerd voordat het met echte gegevens in aanraking komt. Er is een verschil tussen een tool met AI-functies en een tool die door een AI gebouwd kan worden, en dat laatste werkt alleen als een mens het kan controleren.

Dus, moet je bedrijf in 2026 zijn eigen interne software bouwen?

Ja, voor de tool-laag: de trackers, dashboards, contentsystemen en planners die je momenteel huurt. Nee, voor de infrastructuurlaag: betalingen, loonadministratie, belastingen en bronsystemen, waar één verkeerd getal echt geld kost. We hebben de eerste categorie opnieuw gebouwd, zijn de tweede blijven kopen, en onze lijst met abonnementen wordt steeds korter. Bouw wat je alleen maar zou missen als het kapotging. Koop wat je de kop zou kosten als het fout was.

Als het eerste abonnement dat je wilt opzeggen in je commerce-stack zit, begin dan met het berekenen van de werkelijke kosten: hier zie je wat de software-abonnementen van een gemiddelde retailer daadwerkelijk per jaar kosten.