Code is goedkoop, goede software niet

Alleen: dat bouwen is maar 20% van het verhaal. De 40% ervoor en de 40% erna, dáár gaat het eigenlijk over. En laat dat nou net het stuk zijn dat Henk vrolijk oversloeg. In dit blog nemen we je mee in die 80% waar bijna niemand het over heeft. 

Bouwen is het gave stuk, niet het grootste 

Een applicatie bestaat grofweg uit drie delen: ontwerpen, bouwen en onderhouden. Reken maar op 40% ontwerp vooraf, 20% bouwen en 40% beheer achteraf. Het bouwen, de code, is dus het kleinste stukje. En laat dat nou net het stuk zijn waar AI en vibecoding het snelst en goedkoopst in zijn geworden. 

Klinkt als goed nieuws - en dat is het ook. Maar er zit een addertje onder het gras. Hoe goedkoper dat middelste stuk wordt, hoe zwaarder de andere 80% gaat wegen. Wie sneller bouwt, zonder dat het ontwerp en het beheer op orde zijn (looking at you, Henk), produceert vooral sneller iets dat straks weer rechtgetrokken moet worden.  

De vragen die niemand stelt 

Voordat er ook maar één regel code geschreven wordt, ligt er een stapel vragen op je te wachten. Wat heeft de business nou écht nodig, los van de oplossing die ze al in hun hoofd hebben? Wie wordt straks eigenaar van deze app? Hoe is het onderhoud geregeld als de bouwer ergens anders gaat werken? Wat gebeurt er als de hele applicatie omvalt op een vrijdagmiddag? En misschien wel de belangrijkste: is het echt veilig of belandt je klantdata straks per ongeluk op straat? 

Dit zijn de vragen uit die eerste 40%. En ja, ze kosten je vooraf een paar goede gesprekken. Maar sla je ze over, dan kosten ze je achteraf nog veel meer. Dit is precies de paraplu die over elk bouwtraject hoort te hangen - en die bij een snel in elkaar geklikt appje meestal ontbreekt. 

Werkend is niet hetzelfde als goed 

Het verraderlijke aan een (te) snel gebouwde app is dat het meestal gewoon werkt. Je opent 'm, klikt door en het ziet er in eerste instantie prima uit. Totdat je je afvraagt wie erin mag en wie niet, wat er gebeurt als hij crasht, en wie het beheer oppakt. Dan blijkt ineens dat die “werkende” app tóch niet zo stabiel was als gehoopt. 

Neem een simpel appje waarin bestellingen binnenkomen en klaargezet worden voor verwerking. In de demo werkt het perfect. Totdat een klant een afwijkende bestelling doorgeeft, twee artikelcodes niet matchen en er geen enkele controle is die dat opvangt. In een middag in elkaar geklikt, dat wel. Maar juist die uitzonderingen, de logging en de vraag wie ingrijpt als het misgaat: daar zit het echte werk. En dat werk wordt maar al te vaak vergeten door wie het ontwerp oversloeg.  

Waar de winst wél zit 

Goede, stabiele software vraagt om ruimte voor ontwerp en onderhoud. Niet om een verbod op snel bouwen. Vibecoding is fantastisch voor de juiste klus: een intern prototype, iets met een korte levensduur of een app met een laag risico. Het staat niet voor niks als volwaardige optie in onze beslisboom. Regel je die 80% eromheen goed, dan maakt de bouwtechniek daarna een stuk minder uit. 

De kunst zit 'm dus niet in sneller bouwen. Die zit in eerst de juiste vragen stellen - en pas daarna kiezen hóe je bouwt. 

We've got your back 

Als IT-manager wist je dit waarschijnlijk allang. Maar de kans is groot dat er binnenkort een Henk aan je bureau langskomt met “ik heb zelf al even een appje gebouwd, dat kan tegenwoordig toch zo?”. Speciaal voor dat gesprek maakten we de applicatiebeslisboom. Die helpt je de juiste vragen te stellen en de juiste keuze te maken vóórdat er iets gebouwd wordt. Zo sta jij goed beslagen ten ijs zodra de business weer eens iets wil.