Uncategorized
5 mei 2026
Waarom beheer het verschil maakt
Apps bouwen is bijna kinderspel geworden. En dat is fantastisch, totdat het niet meer fantastisch is.
Bij TwentyNext zien we het dagelijks gebeuren. Iemand heeft een idee op vrijdagmiddag, gaat in het weekend aan de slag met Cursor, Lovable of Claude, en op maandagochtend staat er iets werkends online. Wat vroeger een traject van maanden was, met requirements, sprintplanningen en een development team, is nu soms een kwestie van een paar avonden vibe coding. De drempel om iets te maken is gewoon weg.
En eerlijk? Ik vind dat een prachtige ontwikkeling. Het betekent dat ondernemers sneller kunnen valideren of hun idee deugt. Dat teams binnen organisaties niet meer hoeven te wachten op de prioriteitenlijst van de IT-afdeling. Dat innovatie eindelijk uit het laboratorium komt en gewoon… gebeurt.
Maar precies daar zit ook de adder onder het gras.
Bouwen is iets anders dan beheren
Want ja, je hebt een app. Maar zodra die app gebruikt wordt, door echte klanten, met echte data, in echte processen, dan heb je geen “appje” meer. Dan heb je een digitaal product. Of, voor je het weet, een platform.
En platforms hebben verantwoordelijkheden. Ze moeten beschikbaar zijn als jouw klant er om half zes ‘s avonds op klikt. Ze moeten veilig zijn als iemand er persoonsgegevens in achterlaat. Ze moeten meegroeien als het ineens hard gaat. En ze moeten stabiel blijven als je nieuwe functionaliteit toevoegt, want anders ben je elke vrijdagmiddag bezig met brandjes blussen in plaats van met je business.
Onderzoek van Gartner laat al jaren zien dat de Total Cost of Ownership van software voor het overgrote deel ná de eerste oplevering valt, soms tot wel tachtig procent (Gartner, 2023). De bouw is, hoe gek het ook klinkt, vaak het goedkoopste én het kortste deel van het verhaal.
De echte bottleneck zit in beheer, niet in bouwen
Hier wringt het in de praktijk. De opkomst van AI-gedreven development heeft het bouwen versneld. Heel goed. Maar de organisatie eromheen, het beheer, het eigenaarschap, de governance, die is in dat tempo niet meegegroeid.
Je krijgt dan situaties die ik tot vervelens toe voorbij zie komen:
- Niemand weet precies wie verantwoordelijk is als er iets stuk gaat
- Toegangsrechten zijn ooit “tijdelijk” ruim gezet en nooit meer aangepast
- De app werkt prima met tien gebruikers, maar kraakt bij honderd
- Er is geen monitoring, dus je hoort van je klanten dat het stuk is
- De technische schuld stapelt zich op tot doorontwikkelen voelt als waden door drijfzand
- Persoonsgegevens stromen door systemen waarvan eigenlijk niemand precies weet hoe ze zijn ingericht
Het vervelende is dat deze problemen zelden op dag één zichtbaar zijn. Ze sluipen erin. En tegen de tijd dat ze opvallen, is het opruimen vaak duurder dan het bouwen ooit was. Pijnlijk, maar waar.
Dit is overigens geen kritiek op vibe coding zelf. Integendeel. Maar zoals Conway’s Law (Conway, 1968) ons al decennia geleden leerde: de structuur van je software weerspiegelt de structuur van je organisatie. Als je razendsnel bouwt zonder een organisatie eromheen, krijg je software die dat ook laat zien.
Van snelle oplossing naar volwassen platform
Bij TwentyNext geloven we dat de echte waarde niet zit in het slim bouwen, maar in het duurzaam laten draaien. Dat klinkt misschien wat saai, en eerlijk gezegd, soms is het dat ook. Beheer is geen glamour. Maar het is wel het verschil tussen een product dat over twee jaar nog leeft en een product dat tegen die tijd in een digitale schoenendoos op zolder ligt.
Onze rol begint meestal waar anderen ophouden. De app staat live, er zijn de eerste echte gebruikers, en dan komt het moment dat iemand denkt: oké, hoe houden we dit nu eigenlijk in de lucht? Dat is waar wij binnenkomen.
Concreet betekent dat:
Onboarden van de applicatie. We duiken erin. Welke architectuur, welke afhankelijkheden, welke tools, welke datastromen, welke risico’s? Een soort technische APK, zeg maar.
Privacy en compliance op orde. Hoe worden persoonsgegevens verwerkt, en klopt dat met de AVG? Welke verwerkersovereenkomsten ontbreken er nog? Met de aankomende verplichtingen rond de EU AI Act (Europese Commissie, 2024) wordt deze laag alleen maar belangrijker.
Security en toegangsbeheer. De basis. Wie mag wat, hoe zijn accounts beveiligd, hoe gaan we om met wijzigingen? Niet glamoureus, wel essentieel.
Monitoring en performance. Want zonder monitoring vlieg je blind. En blind vliegen werkt prima, totdat het niet meer werkt.
Stabiliteit en doorontwikkeling. Hoe zorg je dat nieuwe features niet elke keer iets anders kapotmaken? Met een doordachte release-aanpak, beheerste deployments en een beetje gezond verstand.
Bouwen én beheren, beide kanten van dezelfde munt
Wat ons onderscheidt is dat we beide kanten kennen. We hebben jarenlang software gebouwd én jarenlang beheerd. Die combinatie is belangrijker dan je denkt.
Want goed beheren vraagt begrip van hoe software is opgebouwd. En goed doorontwikkelen vraagt begrip van wat er kan stukgaan in productie. Wie alleen het ene kan, mist altijd iets van het andere. Het is een beetje als koken en afwassen: pas als je beide doet, snap je echt wat je in de pannen aan moet richten.
Waarom dit nu speelt
De markt beweegt snel. AI verlaagt ontwikkelkosten, agents worden steeds capabeler, en de hoeveelheid software die organisaties draaien neemt explosief toe. McKinsey schatte recent dat AI-gedreven development de productiviteit van softwareteams met dertig tot vijftig procent kan verhogen (McKinsey & Company, 2024). Dat is geweldig nieuws voor wie bouwt. Maar het betekent ook: meer apps, meer data, meer afhankelijkheden, meer dingen die kunnen omvallen.
Wie z’n beheer nu professionaliseert, bouwt een voorsprong op. Wie het laat sloffen, krijgt vroeg of laat de rekening. En die rekening is meestal hoger dan het abonnement op behoorlijk beheer.
Wat we voor je overnemen
De meeste ondernemers en teams die we spreken willen vooral vooruit. Bouwen, klanten helpen, groeien. Dat snap ik volledig, dat is waarom je begonnen bent. Daarom nemen wij liever het beheer uit handen.
We doen dat op verschillende niveaus, afhankelijk van wat jij nodig hebt: van het volledig overnemen van een bestaand platform tot een lichter model waarin we de governance en monitoring inrichten en jouw team het dagelijkse werk blijft doen. Geen one-size-fits-all, want elke organisatie heeft een ander startpunt.
De kern in één zin
Vibe coding maakt bouwen sneller, maar snelheid zonder beheer is kwetsbaar.
De organisaties die over een paar jaar het verschil maken, zijn niet de partijen die het snelst iets live hadden staan. Het zijn de partijen die hun oplossingen ook veilig, stabiel en schaalbaar wisten te maken. Die balans tussen snelheid en soliditeit, dat is precies waar wij in geloven.
Tot slot
De toekomst van software wordt sneller, toegankelijker, slimmer. Daar mag je best enthousiast over zijn, ik ben dat in elk geval. Maar die toekomst vraagt ook om een dosis volwassenheid. Niet alleen in het bouwen, maar vooral in het verstandig laten draaien van wat we bouwen.
Even sparren?
Heb je iets gebouwd, of laten bouwen, en knaagt het gevoel dat het beheer eigenlijk nog niet helemaal lekker zit? Of wil je nu al voorkomen dat groei straks leidt tot security-, privacy- of performanceproblemen?
Neem gerust contact op. We kijken graag een keer met je mee, vrijblijvend.
Literatuur
Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28-31.
Europese Commissie. (2024). Verordening (EU) 2024/1689 betreffende geharmoniseerde regels inzake artificiële intelligentie (AI Act). Publicatieblad van de Europese Unie.
Gartner. (2023). IT Key Metrics Data: Application Total Cost of Ownership. Gartner Research.
McKinsey & Company. (2024). The economic potential of generative AI: The next productivity frontier. McKinsey Global Institute.
