Jarenlang gold low code vaak als hét wondermiddel om softwareontwikkeling te versnellen. Iedereen, ook degenen zonder diepgaande programmeerkennis, zou er in recordtijd professionele applicaties mee kunnen bouwen. Maar nu de hype wat bekoelt, klinkt er steeds vaker scepsis. “Low code is programmeren voor managers. En als het fout gaat, zit de techneut met de ellende.”
Het was de IT-ondernemer Thijs Kuperus, directeur van SoftTech Automatisering & FlowMonitor, die recent de kat de bel aanbond. Hij gaf in een druk besproken en gedeelde LinkedIn-post aan dat hij de stekker uit zijn low code-diensten ging trekken. “Terwijl ik er eerst lyrisch over was”, voegde Kuperus toe.
Wat begint als een snelle succeservaring, eindigt volgens hem vaak in frustratie, complexiteit en oplopende kosten. We sommen de ervaringen, reality checks én best practices rond low code-ontwikkeling even op, en leggen ze voor aan low code-leveranciers als Mendix.
Bezwaar 1. De 90/10-valkuil
Low code geeft een vals beeld van applicatieontwikkeling. “Je bouwt 90 procent van de functionaliteit in 10 procent van de tijd”, oppert Thijs Kuperus. “Alles lijkt perfect te gaan tot je op maatwerk overgaat. Maar met de laatste tien procent ‘bijzondere wensen’ ben je negentig procent van de tijd kwijt”, zo oppert hij.
Die zogenoemde 90/10-valkuil herkennen meer ontwikkelaars. Ook Huub van Niekerk, onafhankelijk IT-consultant, plaatst kanttekeningen bij de tijdswinst. “Het moet snel even geprogrammeerd worden; echte kennis van zaken is niet per se nodig,” zegt hij. “Maar als het fout gaat, is de fout meestal moeilijk te vinden.”
Volgens Menno Odijk, Field CTO bij Mendix, is die ervaring niet uniek voor low code, maar kenmerkend voor elke vorm van softwareontwikkeling. “Het is een bekende vuistregel dat tachtig procent van de ontwikkeltijd gaat zitten in de laatste twintig procent van de features – de details, uitzonderingen en bugfixes,” zegt hij.
En Odijk gaat verder: “Low code is volwassen en heeft dat al lang bewezen bij complexe toepassingen. Bovendien versnelt het de hele ontwikkelcyclus, omdat de wensen van de business sneller en nauwkeuriger vertaald worden naar functionele software”, werpt hij op.
Bezwaar 2. Low code is voor kleinere automatiseringen
Bij veel ontwikkelaars heerst het gevoel dat low code niet bedoeld is voor het grote werk. “Ik was eerst enthousiast over no en low code, omdat ik dacht dat we eindelijk kleinere bedrijven met een beperkt budget konden helpen. Maar de werkelijkheid bleek een domper”, vindt Thijs Kuperus. “Het is vooral geschikt voor eenvoudige automatiseringen, waar eigenlijk een business consultant of een ‘mannetje’ goed mee uit de voeten kan. Zodra je iets serieus wilt bouwen, knal je tegen het plafond aan van de mogelijkheden.”
Menno Odijk wil dit nuanceren. “Niet alle low code-platformen zijn hetzelfde,” benadrukt hij. “Wij bieden met Mendix bijvoorbeeld een volwassen platform waarmee al talloze bedrijfskritische applicaties zijn gebouwd, bijvoorbeeld bij ABN AMRO en Rabobank in Nederland, en Proximus en Securex in België.” Concurrent Outsystems deed bijvoorbeeld recent een project bij supermarktketen PLUS.
Al is het, volgens Odijk, een kwestie van inschatten. “Per toepassing moet gekeken worden welke omgeving het beste gebruikt kan worden om de applicatie te realiseren. Dit verschilt ook per organisatie.”
Bezwaar 3. Oplopende kosten en gebrek aan transparantie
Een ander terugkerend punt is de prijs. Zo halen sommige low code-gebruikers aan dat projecten duurder kunnen uitvallen. “Zo blijken er plotseling kosten te zijn voor licenties en modules, vierhonderd euro of meer per maand”, illustreert Thijs Kuperus. Verrassingen die de businesscase van een project kunnen aantasten.
Op dat vlak kan Menno Odijk zich wel inleven. Hij erkent dat het low code-kostenmodel niet overal even helder is, maar stelt dat transparantie centraal moet staan. “Onze licentiekosten zijn gebaseerd op het aantal gebruikers en de benodigde cloudcapaciteit. Die zijn volledig voorspelbaar”, beweert hij. “Daarnaast leveren de kortere ontwikkeltijd, minder compliance-checks en herbruikbare componenten juist forse kostenbesparingen op”, zo klinkt het.
Bezwaar 4. Vendor lock-in en onderhoud
Sommige ontwikkelaars ervaren dat low code leidt tot afhankelijkheid van een platform. En dan is er nog de uitdaging dat er maatwerk wordt toegevoegd. “Al je eigen maatwerk zorgt voor complexe, lastig onderhoudbare software met hoge kosten en veel issues,” aldus Kuperus. “En als je dan vastloopt, zegt support: ‘Succes ermee, dit stuk eigen maatwerk is niet onze verantwoordelijkheid.’”
Odijk begrijpt de zorg, maar vergelijkt het met de algehele situatie in IT. “Organisaties maken een strategische keuze voor een low code-platform en bouwen in de meeste gevallen zelf een center of excellence om het platform heen”, stelt hij. “Die kennisopbouw over zo’n low code-platform creëert dan inderdaad een zekere afhankelijkheid van dat platform. Maar dit is niet anders dan voor veel andere IT-platforms en -systemen.”
Organisaties die low code gebruiken, zouden volgens Odijk duidelijke afspraken moeten maken over wat er wel en niet met low code gebouwd wordt, en met welk low code platform. “Als er geen kant-en-klare bouwblokken voor een bepaalde integratie of voor complexe elementen voor user interactie aanwezig zijn, kunnen deze gemaakt worden. En als die er eenmaal zijn, kunnen ze weer makkelijk gebruikt worden voor andere toepassingen.”
Bezwaar 5. De schijn van eenvoud
Low code wekt soms de indruk dat iedereen kan programmeren. Volgens Huub van Niekerk schuilt daarin een risico. “Het is programmeren voor managers, als het ware,” zegt hij. “Als het fout gaat, zit de techneut met de ellende.”
Odijk erkent dat toegankelijkheid niet mag betekenen dat vakkennis overbodig wordt. “In een team van low code-ontwikkelaar is wél gedegen software-ontwikkelkennis aanwezig”, werpt hij op.
Bezwaar 6. De lokroep van vibe coding
Intussen krijgt low code-ontwikkeling– en ook in de vakpers – meer en meer concurrentie van vibe coding, een fenomeen dat intussen al wat hoger op de hypecyclus staat dan low code-ontwikkeling. En ook met succesvolle tech scale-ups als het Zweedse Lovable, een van de snelst groeiende softwarebedrijven van dit moment.
Al vindt Menno Odijk dat toch iets helemaal anders. “Maar vibe coding, dat is het genereren van code via prompts door mensen zonder ontwikkelachtergrond”, kadert de Mendix-CTO. “Dit soort code is prima voor prototypes en persoonlijke toepassingen, maar mist de betrouwbaarheid, compliance en kwaliteit die absoluut nodig zijn voor bedrijfskritische toepassingen. Een vibe coder is vaak ook niet in staat om de door AI geproduceerde code te valideren, fouten op te sporen of wijzigingen door te voeren.”
Bezwaar 7. De overbodigheid van low code in tijden van AI
Sommigen voorspellen intussen wel dat AI de rol van low code zal overnemen. Odijk ziet dat anders: “De AI in Mendix genereert geen code, maar een visueel model op basis van gevalideerde bouwblokken,” legt hij uit.
Zelf ziet Odijk het dus eerder omgekeerd. “Artificiële intelligentie versnelt bij ons het hele ontwikkelproces, niet alleen het programmeren zelf”, beweert hij. “De ontwikkelsnelheid van low code, zeker in combinatie met AI, ligt daardoor nog altijd hoger dan puur vibe coding met AI”, klinkt het.
Lego versus Duplo
De discussie over low code laat zien dat de euforie van de eerste jaren plaatsmaakt voor realisme. Het wordt volop gebruikt, vaak ook uit kostenoverwegingen.
Al is die hype rond low code ook wel gecreëerd, oppert Maurits Dijkgraaf, oprichter van PAQT, maar wel niet altijd met een even getrouw beeld. “Het is een aantal jaren geleden wel in de markt gezet als de vervanging van software ontwikkeling”, merkt hij op. “Met beloftes dat het tien keer sneller software zou opleveren.”
Low code is dus geen wondermiddel, maar wordt tegelijk volop ingeschakeld. Zoals Dijkgraaf het zelf samenvat: “Low code is geen vervanging van softwareontwikkeling, maar simpelweg een andere toepassing”, meent hij.
En hij schuift hiervoor een speelgoed-metafoor naar voren. “Ik vergelijk het met Duplo en Lego”, haalt hij aan. “Met Duplo bouw je sneller, maar minder gedetailleerd. Wil je meer detail, dan moet je overstappen op Lego – en dat kost tijd.”