Low-code development is applicaties bouwen met visuele ontwerpers, kant-en-klare componenten en configuratie, waarbij je alleen nog code schrijft voor de stukken die echt uniek zijn.
Je sleept een formulier in elkaar, legt een datamodel vast, tekent een workflow en publiceert. Wat je dan hebt is geen prototype maar een werkende applicatie met gebruikersbeheer, rechten, logging, een mobiele versie en hosting eromheen.
Wat het níet is: een manier om software te bouwen zonder dat iemand verstand heeft van software. Die belofte wordt in de markt vaak gedaan en hij klopt niet. Low-code haalt het schrijven van standaardcode weg, niet het nadenken over datamodellen, processen, rechten en beheer. Wie dat overslaat, bouwt snel iets dat net zo snel onhoudbaar wordt.
Dat eerlijk zeggen maakt de rest van het verhaal sterker, want de werkelijke voordelen zijn groot genoeg.
De tijdwinst zit niet in het typen. Een ervaren ontwikkelaar schrijft razendsnel code. De winst zit in alles wat je niet hoeft te bouwen.
Daar komt bij dat je veel eerder iets kunt laten zien. In een maatwerktraject zie je pas na maanden iets werkends; in low-code na dagen. Dat verschil is niet alleen prettig maar risicoverlagend, want negentig procent van de misverstanden in softwareprojecten komt pas aan het licht als iemand het scherm ziet.
Inlog en wachtwoordherstel, rollen en rechten, een database-opzet, formuliervalidatie, zoeken en filteren, rapportage, export, auditlogging, een mobiele weergave, hosting, back-ups, monitoring en een uitrolstraat. Dat is in vrijwel elke applicatie zeventig tot tachtig procent van het werk, en het is in elke applicatie hetzelfde werk.
Wat jij bouwt is de twintig procent die jouw organisatie onderscheidt: jouw datamodel, jouw proces, jouw schermen, jouw regels.
| Low-code | Maatwerkontwikkeling | |
|---|---|---|
| Tijd tot eerste werkende versie | Dagen tot weken | Maanden |
| Standaardfunctionaliteit | Ingebouwd | Zelf bouwen |
| Wijziging doorvoeren | Uren tot dagen | Sprint en release |
| Wie kan bijdragen | Business én ontwikkelaars | Alleen ontwikkelaars |
| Hosting, back-up, schaling | Onderdeel van het platform | Zelf inrichten en beheren |
| Beveiligingsbasis | Platformbreed onderhouden | Jouw verantwoordelijkheid |
| Continuïteitsrisico | Laag; meer mensen kunnen erin | Hoog bij één ontwikkelaar |
| Vrijheid in UX en architectuur | Begrensd door het platform | Onbeperkt |
| Kosten bij start | Laag | Hoog |
| Kosten op termijn | Licenties per gebruiker | Onderhoud en hosting |
Een paar van die punten verdienen toelichting, omdat ze in verkoopverhalen meestal onderbelicht blijven.
Een partij die alleen de voordelen noemt, verkoopt zichzelf. Dit zijn de situaties waarin wij maatwerk adviseren.
Zoho Creator is sterk wanneer je een afgebakende applicatie nodig hebt rond gegevens en formulieren: een registratiesysteem, een aanvraagproces, een inspectie-app, een voorraadmodule, een intern aanvraagportaal. Je bouwt formulieren, rapporten en workflows visueel, met scriptingtaal Deluge voor de stukken die verder gaan.
Het grootste voordeel is als je al met Zoho werkt: je applicatie deelt gebruikersbeheer en data met je CRM, Desk, People en de rest van de suite. Een aanvraag die in Creator binnenkomt kan rechtstreeks een deal of ticket raken, zonder tussenkoppeling.
Creatio is de keuze wanneer het proces leidend is in plaats van de data. Complexe workflows met vertakkingen, goedkeuringen, uitzonderingen en meerdere afdelingen bouw je visueel in BPMN, met de Freedom UI-ontwerper voor de schermen daaromheen.
Omdat BPM in het fundament van het platform zit, blijven de tekening en de uitvoering hetzelfde ding. Pas je het procesmodel aan, dan verandert de werking mee. Dat is waardevol bij processen die regelmatig wijzigen.
| Je vraag | Waarschijnlijk |
|---|---|
| Een registratie- of aanvraagapplicatie met formulieren en rapportage | Zoho Creator |
| Een proces met goedkeuringen over meerdere afdelingen | Creatio Studio |
| Een app die nauw samenwerkt met je Zoho-omgeving | Zoho Creator |
| Een proces dat je regelmatig wilt kunnen bijstellen | Creatio Studio |
| Een buitendienst- of inspectie-app met offline gebruik | Zoho Creator |
| Procesbewaking, doorlooptijden en casemanagement | Creatio Studio |
In de praktijk komt de keuze meestal voort uit wat je al hebt staan. Werk je al in Zoho of al in Creatio, dan is dat zelden een discussie waard.
In plaats van een duur maatwerktraject hadden we binnen een paar weken een werkende applicatie. Aanpassingen doen we nu in dagen, niet in maanden.
Dit is de belofte die low-code een slechte naam heeft bezorgd bij IT-afdelingen, en terecht.
Wat wél klopt: iemand uit de business kan een formulier aanpassen, een veld toevoegen, een rapportage bouwen of een goedkeuringsstap verleggen. Dat is reële winst en het is precies waarvoor je low-code kiest.
Wat niet klopt: dat je zonder vakkennis een applicatie kunt opzetten die over drie jaar nog klopt. Het datamodel bepalen, rechten ontwerpen, bedenken wat er gebeurt bij uitzonderingen, koppelingen inrichten, testen en beheer beleggen: dat blijft vakwerk. Low-code verandert niet wát je moet nadenken, alleen hoeveel je daarna moet typen.
De verstandige verdeling die wij adviseren: wij zetten het fundament neer en richten de eerste versie in, jullie team beheert en breidt uit, en wij komen terug voor koppelingen, grotere uitbreidingen en periodiek onderhoud. Zo houd je de snelheid van low-code zonder de puinhoop die ontstaat als iedereen maar wat bouwt.
Wat moet er gebeuren, voor wie, hoe vaak, en wat zijn de uitzonderingen? Vaak blijkt dat een deel standaard op te lossen is in software die je al hebt. Daarvoor kun je ook los een procesmapping-workshop afnemen.
Bestaat er al een pakket dat dit doet? Dan is bouwen zelden verstandig.
Voordat we schermen maken.
Zodat de misverstanden eruit zijn voordat ze duur worden.
Waar dat nodig is. Zie ook integraties tussen applicaties.
Inclusief afspraken over wie wat mag aanpassen.
Voor uitbreidingen en de momenten waarop het platform niet meer volstaat.
Low-code verdient zijn plek niet omdat het goedkoop is, maar omdat je er eerder achter komt of je het juiste bouwt, en omdat je het daarna kunt blijven aanpassen zonder dat elke wijziging een project wordt.
Dat maakt de belangrijkste vraag bij de start niet "welk platform", maar "hoe ziet dit er over drie jaar uit, en wie houdt het dan bij". Een partij die alleen over snelheid praat, heeft die vraag niet gesteld.
Wij werken met Zoho Creator en Creatio, en we bouwen daarnaast maatwerk wanneer low-code niet toereikend is. Juist omdat we beide doen, kunnen we eerlijk adviseren welke kant op.
No-code werkt volledig met visuele hulpmiddelen en is bedoeld voor gebruikers zonder programmeerkennis; de grens van het platform is de grens van wat je kunt. Low-code gebruikt dezelfde visuele aanpak maar laat je code toevoegen voor de stukken die uniek zijn. In de praktijk lopen beide termen door elkaar: de meeste platformen die zich no-code noemen, bieden ergens een scripting- of API-laag.
In de bouwfase vrijwel altijd, omdat je het fundament niet hoeft te maken. Op termijn hangt het af van je gebruikersaantallen: low-code rekent doorgaans licenties per gebruiker, terwijl maatwerk onderhouds- en hostingkosten kent. Bij een beperkt aantal interne gebruikers wint low-code ruim; bij duizenden externe gebruikers kan de rekensom omslaan. Reken altijd door naar je verwachte omvang over drie jaar.
Voor aanpassingen zeker: een veld toevoegen, een formulier wijzigen, een rapportage maken, een goedkeuringsstap verleggen. Voor het opzetten van een nieuwe applicatie is vakkennis nodig over datamodellering, rechten en beheer. De werkbare verdeling is dat wij het fundament leggen en jullie team daarna beheert en uitbreidt.
Dat is een normaal moment en geen mislukking. Meestal los je het op met een koppeling naar een extern systeem of met een stuk maatwerkcode binnen het platform zelf. Lukt dat niet, dan is het tijd om dat deel buiten het platform te bouwen en te koppelen. Waar je voor moet waken is het stapelen van omwegen: drie uitzonderingen op een uitzondering is het signaal dat je de verkeerde kant op aan het bouwen bent.
Er is platformafhankelijkheid, dat is eerlijk. Wel is het beeld genuanceerder dan vaak gesteld: ook maatwerk zit vast aan frameworks, cloudleveranciers en de kennis van wie het bouwde, en bij maatwerk is die afhankelijkheid vaak gekoppeld aan één persoon in plaats van aan een platform met een partnernetwerk. Wat de afhankelijkheid beperkt is een helder datamodel, exporteerbare data en documentatie.
Een afgebakende applicatie met formulieren, workflows en rapportage staat doorgaans in enkele weken, waarvan het grootste deel in de analyse en het datamodel zit. Een applicatie met meerdere rollen, complexe processen en koppelingen naar bestaande systemen loopt op naar enkele maanden. Het verschil met maatwerk zit vooral in het moment waarop je iets werkends ziet: dagen in plaats van maanden.
Zoho Creator als de applicatie draait om gegevens, formulieren en rapportage, en zeker als je al met Zoho werkt: dan deelt je app gebruikersbeheer en data met de rest van de suite. Creatio Studio als het proces leidend is: workflows met goedkeuringen, vertakkingen en uitzonderingen over meerdere afdelingen, en casemanagement voor dossiers zonder vast pad. Werk je al in een van beide, dan is dat meestal de doorslaggevende factor.
De beveiligingsbasis is doorgaans sterker dan bij zelfgebouwde software, simpelweg omdat de platformleverancier authenticatie, versleuteling, rechten, logging en certificering platformbreed onderhoudt. Waar je zelf op moet letten is de inrichting: rolgebaseerde toegang, bewaartermijnen, de datacenterregio en wie er mag bouwen. Voor organisaties met strikte eisen is dat laatste punt (governance over wie applicaties mag maken) belangrijker dan de techniek.
Leg het aan ons voor.
