Het probleem met "we doen het zelf wel met Power Apps"
Power Apps is fantastisch. Dat meen ik. Als je een simpel formulier nodig hebt waarmee buitendienstmedewerkers een rapport invullen, of een basisworkflow om verlofaanvragen goed te keuren, dan is Power Apps precies de juiste tool. Snel opgezet, draait binnen je Microsoft-omgeving, en je hebt er geen developer voor nodig.
Het probleem begint wanneer het daarbij niet blijft.
En het blijft daar nooit bij.
Hoe het begint
Het scenario is bijna altijd hetzelfde. Iemand in het team, meestal iemand met een talent voor techniek en een gezonde allergie voor Excel, ontdekt Power Apps. Of Power Automate. Of Zapier. Of Make. De specifieke tool maakt niet uit. Wat telt is het moment: iemand beseft dat je dingen kunt automatiseren zonder een developer in te schakelen.
En dat klopt. Je kúnt een heleboel automatiseren met low-code tools. Het eerste project is meestal een succes. Een formulier dat data opslaat in SharePoint. Een flow die een mail stuurt wanneer iemand iets invult. Een simpel dashboard dat cijfers uit een lijst trekt. Het werkt, het team is blij, en de persoon die het gebouwd heeft voelt zich terecht trots.
Dan komt de tweede vraag. En de derde. En de vierde. "Kun je er ook voor zorgen dat..." is de zin die het begin van het einde inluidt.
Waar het kantelt
Low-code tools zijn gebouwd om eenvoudige problemen snel op te lossen. Dat doen ze goed. Maar er zijn vier momenten waarop ze beginnen tegen te werken in plaats van mee te werken.
Moment 1: de logica wordt ingewikkeld
Zolang je proces lineair is (A gebeurt, dan B, dan C) werkt een low-code tool prima. Maar zodra er voorwaarden bijkomen ("als het bedrag boven de 5.000 euro is EN de klant in regio Noord zit EN het product niet op backorder staat, DAN route naar manager X, TENZIJ het een bestaande klant is met een raamcontract"), dan bouw je formules die drie schermen lang zijn en die niemand meer leest, laat staan onderhoudt.
In Power Apps zit die logica verspreid over tientallen schermen, in fragmenten van Power Fx die aan individuele knoppen en velden hangen. Er is geen centrale plek waar je de businessregels overziet. Het is alsof je een boek schrijft door op elke pagina losse post-its te plakken.
Moment 2: je hebt meerdere databronnen nodig
Power Apps werkt prima met één SharePoint-lijst of één Excel-tabel. Maar de meeste bedrijfsprocessen raken aan meerdere systemen. Je facturen zitten in je boekhoudpakket. Je klantgegevens in een CRM. Je voorraad in een ander systeem. Je planning in weer iets anders.
Low-code tools kunnen connecties maken met die systemen, in theorie. In de praktijk loop je tegen limieten aan. API-restricties, rate limits, data die niet in het verwachte formaat terugkomt, connectoren die plots stoppen met werken na een update. Elke connectie is een potentieel breekpunt, en hoe meer breekpunten je hebt, hoe meer tijd je kwijt bent aan onderhoud in plaats van aan verbetering.
Moment 3: meer dan vijf mensen gebruiken het
Low-code apps zijn zelden gebouwd met schaalbaarheid in gedachten. De performance wordt trager naarmate er meer data in zit. De gebruikerservaring is beperkt tot wat de tool toelaat. En het rechten- en rollensysteem is vaak te grof voor wat je eigenlijk nodig hebt.
Bij vijf gebruikers merk je dat niet. Bij twintig wel. En dan zit je met een tool die te traag is om prettig mee te werken, maar waar te veel proces op draait om zomaar te vervangen.
Moment 4: de bouwer vertrekt
Dit is het moment dat het echt pijn doet. De persoon die de Power App gebouwd heeft, die alle flows kent, die weet waarom er op scherm 7 een omweg zit die nergens gedocumenteerd staat, die gaat weg. Nieuw project, nieuwe baan, andere functie.
En nu zit je met een applicatie die niemand begrijpt. Klinkt dat bekend? Het is exact hetzelfde probleem als met die Excel-spreadsheet die niemand durft aan te passen. Je hebt de Excel vervangen door een low-code app, maar het onderliggende probleem is gebleven: je systeem zit in het hoofd van één persoon.
Wat low-code tools niet zijn
Low-code tools zijn geen vervanging voor maatwerk software. Ze zijn ook geen opstap naar maatwerk software. Het zijn fundamenteel andere dingen.
Een low-code tool is een manier om snel iets werkends te maken zonder te programmeren. Dat is de kracht en tegelijk de beperking. Je werkt binnen de grenzen van wat de tool toelaat. Zolang je probleem binnen die grenzen past, is alles perfect. Zodra je erbuiten valt, zit je vast.
Maatwerk software vertrekt vanuit je proces, niet vanuit de beperkingen van een tool. Als je proces een uitzondering heeft, bouw je die in. Als je een specifieke berekening nodig hebt, programmeer je die. Als je tien systemen moet koppelen, ontwerp je een architectuur die dat aankan.
Het verschil is niet beter of slechter. Het verschil is wanneer je welke nodig hebt.
Wanneer low-code de juiste keuze is
Wees eerlijk: voor een heleboel situaties is een low-code tool genoeg. Specifiek:
Je proces is eenvoudig en lineair. Iemand vult iets in, het wordt opgeslagen, iemand anders krijgt een melding. Klaar. Daar heb je geen developer voor nodig.
Je hebt minder dan tien gebruikers. De schaal is beperkt, de data is beperkt, de complexiteit is beperkt. Power Apps werkt hier prima.
Je wilt iets uitproberen. Je weet nog niet precies hoe je proces eruitziet en wilt snel iets testen. Low-code is perfect om te prototypen. Bouw iets in een week, gebruik het een maand, en leer wat wel en niet werkt. Die kennis is goud waard als je later de stap naar maatwerk maakt.
Je hebt één databron. Alles zit in SharePoint, of alles zit in een Google Sheet, of alles zit in Airtable. Zolang je niet meerdere systemen hoeft te verbinden, blijft het beheersbaar.
Wanneer het tijd is voor iets anders
De overgang van low-code naar maatwerk is zelden een bewust moment. Het is eerder een geleidelijk ongemak dat op een dag niet meer te negeren valt. Maar er zijn signalen die je kunt herkennen.
Je besteedt meer tijd aan het repareren van flows dan aan het verbeteren ervan. Je gebruikers klagen over traagheid of beperkingen. Je bouwer is de enige die het systeem begrijpt. Je hebt workarounds nodig om de beperkingen van de tool te omzeilen. Je wilt iets dat de tool simpelweg niet kan.
Op dat moment heb je twee keuzes. Je kunt de low-code app blijven oprekken en steeds meer pleisters plakken op de scheuren. Of je kunt een stap terug zetten, kijken naar wat je geleerd hebt over je proces, en dat laten bouwen als iets dat er wél tegen kan.
Het mooie is: als je al een tijdje met Power Apps of een vergelijkbare tool hebt gewerkt, dan heb je onbewust het belangrijkste voorwerk al gedaan. Je weet hoe je proces werkt. Je weet waar de uitzonderingen zitten. Je weet wat je gebruikers nodig hebben. Die kennis maakt een maatwerk project sneller, scherper, en goedkoper dan wanneer je vanuit het niets zou beginnen.
Die Power App was geen verspilling. Het was onderzoek.
De eerlijke conclusie
Power Apps en low-code tools zijn goede producten die een reëel probleem oplossen. Ze maken automatisering toegankelijk voor mensen die geen developers zijn. Dat is waardevol.
Maar ze zijn niet de eindbestemming. Ze zijn een tussenstap. En er is niks mis mee om te erkennen dat je die tussenstap ontgroeid bent.
De vraag is niet "Power Apps of maatwerk?" De vraag is: past de tool nog bij de schaal en complexiteit van wat je ermee probeert te doen? Als het antwoord ja is, werk er lekker mee door. Als het antwoord nee is, dan weet je wat de volgende stap is.
En die stap is kleiner dan je denkt. Je hoeft niet alles in één keer te vervangen. Begin met dat ene proces dat het meest vastloopt in je huidige setup. De rest volgt vanzelf.
Benieuwd wat dat voor jouw bedrijf zou betekenen? Gebruik onze budgetconfigurator voor een snelle inschatting, of neem vrijblijvend contact op.