Wat is no-code en low-code? Automatiseren en bouwen zonder (veel) programmeren. Waar het snel wint, wat het vastloopt en wanneer maatwerk beter past.
No-code is software bouwen zonder te programmeren, door schermen en stappen visueel samen te stellen. Low-code zit ernaast: een visuele basis met de mogelijkheid om waar nodig zelf code toe te voegen. Beide maken bouwen snel bereikbaar, maar blijven werken binnen de grenzen van het platform dat je kiest.
Een no-code-platform geeft je een doos met klaargemaakte onderdelen: formulieren, tabellen, knoppen, verbindingen naar bekende diensten. Je klikt het samen in plaats van het te programmeren, en iets staat al binnen enkele dagen. Low-code houdt het midden: dezelfde visuele basis, maar met de deur open voor eigen code op de plekken waar de standaardonderdelen uitlopen. In de praktijk vloeien beide begrippen in elkaar over, en leveranciers gebruiken ze door elkaar.
De sterkte is tempo. Een formulier met een opvolgmail, een kleine dashboardomgeving, een koppeling tussen twee bekende tools. Dat is no-code-terrein, en daar verslaat het elke andere route op snelheid. De grens zit op drie plekken. Ten eerste de mal: je bouwt met de onderdelen die het platform aanbiedt, en wat daar niet in zit, bouw je niet. Ten tweede de schaal: wat met tien records vlot loopt, kan met tienduizenden records traag worden en per gebruik ineens duur. Ten derde de deur: je gegevens en je bouwwerk staan in het platform, en verhuizen betekent opnieuw beginnen.
Een voorbeeld: een webwinkelier bouwt in een no-code-tool een retourformulier met automatische bevestiging, en dat werkt prima. Zodra de retourlogica ook voorraad aanpast, de boekhouding raakt en per product anders moet lopen, ontstaat er een web van regels dat in het platform steeds moeilijker te doorzien is. Dat is het moment waarop de afweging naar op maat gebouwd begint te kantelen.
De moeite waard is no-code voor het randwerk dat snel moet maar niet kern-onderscheidend is: een inschrijfformulier, een interne klusjescampagne, een klein overzichtje met meldingen. Ook als bewijsstap loont het: wie wil peilen of een idee aanslaat, bouwt het in no-code sneller dan het kan uitschrijven. En voor teams zonder technische collega is het de enige route die vandaag nog iets kan laten draaien.
Het loont niet voor het kernsysteem waar je bedrijf jaren op wilt draaien, en niet voor processen waar de regels buiten de mal vallen. Let op de kostencurve: veel platforms rekenen per gebruiker of per verbruik, dus wat bij een proef klein is, groeit mee met je succes. En wie een no-code-bouwwerk overdraagt aan een collega, verhuist ook de kennis van hoe het in elkaar zit. Die zit in geklikte instellingen, niet in leesbare code.
We zijn geen no-code-bureau en verhullen dat ook niet: waar een platform volstaat, zeggen we dat en adviseren we het, want niet elk probleem is gebaat bij gebouwd werk. Waar een platform op de kernplek tekortschiet, bouwen we maatwerk dat daar overneemt, vaak met de no-code-oplossing als bewijs dat de behoefte echt is. Op de pagina die no-code tegen maatwerk afweegt staan die grenzen uitgewerkt. Offertes volgen op nacalculatie, zonder pakketten.
Dat hangt af van de levensduur van wat je bouwt. Voor een kortstondige of eenvoudige oplossing is no-code vrijwel altijd voordeliger: geen bouwkosten, alleen abonnement en eigen tijd. Voor een systeem dat jaren meegaat en intensief gebruikt wordt, kunnen de maandelijkse platformkosten en de ingeslotenheid oplopen tot meer dan de bouw van een eigen oplossing. Reken daarom over meerdere jaren in plaats van alleen naar de eerste maand, en leg die rekening naast een offerte op nacalculatie.
De behoefte neem je mee, het bouwwerk zelf meestal niet. Wat je in een platform geklikt hebt, is niet te exporteren als code die een ander verder bouwt; de uitgang kan dus een herbouw zijn. Dat is niet erg als de no-code-versie zijn rol al gespeeld heeft: bewezen dat het proces werkt en de vereisten duidelijk maken. We gebruiken zo'n bewijsversie juist graag als vooronderzoek, zodat het echt gebouw niet op gissingen maar op praktijkervaring ontworpen wordt.
Het team dat hem bouwde, en dat is soms precies het risico. Kennis over hoe het in elkaar zit zit in geklikte instellingen en in het hoofd van degene die klikte; is die persoon weg of druk, dan staat niemand meer te schuiven. Maak daarom vanaf het begin een korte documentatie van de regels en houd de bouw zo simpel dat een tweede collega hem kan lezen. Voor kritische processen geldt: als het uitvalt, valt er werk stil. Behandel het daarom als systeem, niet als hobby.
Steeds meer platforms bieden kant-en-klare AI-stap-in: tekst samenvatten, een veld invullen, een mail opstellen. Voor lichte taken is dat een prima instap. De begrenzing zit in de controle: een AI-stap in een platform geeft weinig ruimte om te bepalen wat het model mag zien, waar het antwoord aan getoetst wordt en wat er gebeurt bij twijfel. Voor werkstroom waar fouten klanten raken, is een eigen gebouwde omgeving met expliciete controles de betere keuze.
EIGHTY8