Bij low code vs maatwerk kies je per app, en die keuze kan later veranderen. Low code past bij interne apps met standaardformulieren en vaste workflows, bij een snelle eerste versie en bij een organisatie zonder eigen ontwikkelaars. Maatwerk past zodra je businesslogica met omwegen bouwt, de app trager wordt bij groei of koppelingen buiten het platform vallen.
Mendix, OutSystems en Microsoft Power Apps zijn bekende voorbeelden van een low code platform, en voor veel apps blijven ze een goede keuze. Hieronder vind je een beslistabel, zes signalen dat een app het platform ontgroeit, wat verhuist en wat blijft, en hoe een overstap naar maatwerk in de praktijk verloopt.
Low code vs maatwerk in één tabel
De vraag low code of maatwerk beantwoord je per app. Loop de acht situaties hieronder langs met één app in gedachten.
| Situatie | Low code past als | Maatwerk past als |
|---|---|---|
| Soort app | Het een interne app met formulieren en goedkeuringen is | De app je kernproces draagt of klanten en leveranciers erin werken |
| Tempo | Je snel een eerste versie wilt om een idee te toetsen | Je software bouwt die jaren meegaat en blijft veranderen |
| Team | Collega's met proceskennis zelf bouwen, zonder ontwikkelaars | Je een eigen ontwikkelteam of een vaste partner hebt |
| Businesslogica | De regels in de bouwstenen van het platform passen | Elke nieuwe regel om een omweg vraagt |
| Gebruikers en data | Eén afdeling ermee werkt en de gegevens overzichtelijk blijven | Het aantal gebruikers of records snel groeit |
| Koppelingen | De connectors van het platform al je systemen dekken | Je systemen koppelt waarvoor geen connector bestaat |
| Testen en versiebeheer | Een of twee makers handmatig testen | Meerdere ontwikkelaars tegelijk werken, met automatische tests en codereviews |
| Afhankelijkheid | Je het goed vindt dat de app op de runtime van één leverancier draait | Je de code en de plek waar de software draait zelf wilt bepalen |
Staat je app in de meeste rijen links, dan doet het platform zijn werk. Schuift de app op drie of meer rijen naar rechts, lees dan de signalen hieronder.
Waar low code sterk in is
Met een low code platform bouw je apps met visuele modellen in plaats van code. Je zet schermen in elkaar, tekent de stappen van een proces en koppelt de app via meegeleverde connectors aan veelgebruikte pakketten. Inloggen, rollen en het uitrollen van versies regelt het platform.
Dat werkt goed voor:
- Interne apps met standaardformulieren en workflows, zoals een aanvraag indienen en goedkeuren.
- Een snelle eerste versie om een idee bij echte gebruikers te toetsen. Hoe je die klein houdt, lees je in wat een MVP is.
- Een team zonder ontwikkelaars, waarin collega's met proceskennis zelf bouwen.
- Een app die een gedeelde spreadsheet vervangt. Moet die veel meer kunnen, lees dan wanneer je Excel vervangt door een webapplicatie.
Voor zulke apps is maatwerk vaak meer dan nodig.
Zes signalen dat je app het platform ontgroeit
De grenzen van low code worden zichtbaar naarmate een app belangrijker wordt, meer gebruikers krijgt en met meer systemen moet praten. Let op deze zes signalen.
1. Businesslogica vraagt steeds vaker om omwegen
Elk platform heeft bouwstenen voor gangbare logica, zoals een verplicht veld of een statuswijziging. Regels met veel uitzonderingen passen er slechter in, bijvoorbeeld een planning die rekening houdt met ploegen, bevoegdheden en voorraad. Je bouwt dan omwegen met hulpvelden, extra stappen en stukjes eigen code. Samen maken die de app moeilijk te begrijpen en riskant om te wijzigen.
2. De app wordt trager met meer gebruikers of meer data
Een app die vlot reageert bij 20 gebruikers en duizenden records, kan haperen bij 200 gebruikers en een miljoen records. Het platform bepaalt hoe de app de database bevraagt, en daar heb je minder invloed op dan in eigen code.
Microsoft beschrijft zo'n grens voor canvas apps in Power Apps. Kan de gegevensbron een zoekvraag niet zelf uitvoeren, dan haalt Power Apps standaard de eerste 500 records op en werkt daarmee verder. Die grens kun je verhogen tot 2.000. Bevat de bron meer records, dan kan de uitkomst volgens Microsoft onjuist zijn. Met functies die de gegevensbron zelf uitvoert, omzeil je dat.
3. Koppelingen vallen buiten de connectors
Connectors dekken populaire pakketten goed. Je eigen ERP, een ouder systeem of een berichtstandaard uit je sector zit er vaak niet tussen. Dan bouw je een eigen connector of een tussenlaag, en leeft een deel van de app buiten het platform. Bij veel berichten per dag wil je bovendien zelf bepalen hoe een koppeling omgaat met fouten en nieuwe pogingen.
4. Testen en versiebeheer passen niet bij je team
Met een of twee makers volstaat handmatig testen. Werken er vijf ontwikkelaars aan dezelfde app, dan wil je aparte takken in versiebeheer, codereviews en automatische tests bij elke wijziging. In een low code platform staat de app in een model in het formaat van de leverancier, en vergelijken, samenvoegen en testen gaat vaak met de hulpmiddelen van dat platform. Sluit dat slecht aan op hoe je team werkt, dan kost elke release meer tijd dan nodig.
5. Je hangt aan de runtime en het licentiemodel van één leverancier
Een low code app draait op de runtime van het platform. De Mendix Runtime is volgens Mendix een interpreter die het model van je app uitvoert. Elke patchversie van Mendix heeft een eigen runtime, die alleen apps voor die versie kan draaien. Upgrades volgen dus het ritme van de leverancier.
Volgens de licentiedocumentatie van Mendix heb je per omgeving een licentie nodig om de beperkingen van een app zonder licentie op te heffen. Buiten Mendix Cloud stopt zo'n app na twee tot vier uur en werken er hooguit zes gebruikers tegelijk. Bij een licentie per gebruiker groeit het licentiemodel mee met het aantal gebruikers.
6. Je app en data meenemen is lastig
Een van de nadelen van een low code platform merk je pas bij vertrek. Je gegevens kun je meestal exporteren. De werking van de app zit in een model in het formaat van het platform, en een ander platform kan dat model niet inlezen. Vraag daarom vooraf wat je bij vertrek meekrijgt: gegevens, bestanden, logica en de geschiedenis van wijzigingen.
Herken je één signaal, dan los je dat vaak binnen het platform op. Zie je er drie of meer bij een app waar je bedrijf op draait, onderzoek dan een overstap.
Wat in low code blijft en wat verhuist
Een overstap hoeft niet te betekenen dat alles verhuist. Kijk per app.
Dit kan in low code blijven:
- Formulieren en goedkeuringen binnen één afdeling
- Apps met weinig gebruikers en overzichtelijke gegevens
- Tijdelijke apps en prototypes
- Apps waarvoor de connectors van het platform alle koppelingen dekken
Dit verhuist naar maatwerk:
- Het kernproces met de meeste regels en uitzonderingen
- Apps met veel gebruikers of grote hoeveelheden data
- Portalen waarin klanten of leveranciers werken
- De plek waar je systemen gegevens uitwisselen
De twee kunnen goed naast elkaar bestaan. De kern in maatwerk biedt een API aan, een vaste ingang voor andere software. Kleine low code apps eromheen gebruiken die API en werken door zoals ze deden.
Overstappen van low code naar maatwerk in vier stappen
Een overstap verloopt het veiligst als de oude app blijft draaien tot elk nieuw onderdeel zich heeft bewezen.
1. Breng in kaart wat de app in werkelijkheid doet
Loop samen met de makers elk scherm, elke workflow en elke geplande taak in het model langs. Noteer welke regels erin zitten, welke rollen er zijn, welke koppelingen lopen en welke meldingen de app verstuurt. Praat ook met gebruikers. Zij kennen de omwegen die ze zelf bedachten omdat de app iets niet kon.
2. Haal de data eruit en test de export vroeg
Begin met de export terwijl je licentie nog ruim doorloopt. Kijk wat er meekomt: tabellen en relaties, bijlagen, de geschiedenis van wijzigingen en de gebruikersaccounts. Draai de export en de import in het nieuwe datamodel een paar keer als proef, en laat gebruikers steekproeven nemen.
3. Bouw de kern opnieuw terwijl de oude app blijft draaien
Martin Fowler noemt deze aanpak de strangler fig, naar de wurgvijg die in een boom ontkiemt en uiteindelijk zelf wortel schiet. Je bouwt nieuwe onderdelen naast het bestaande systeem en laat oud en nieuw een tijd naast elkaar bestaan. Hoe dat gaat, lees je in ons artikel over legacy systemen.
Begin bij het onderdeel waar het signaal het sterkst is, zoals een planning die te traag wordt. Spreek per onderdeel af welk systeem de bron van de gegevens is. Hoe zo'n traject verder verloopt, staat in software laten maken: van idee tot livegang.
4. Zet de oude app stap voor stap uit
Zet gebruikers per groep of per afdeling over. Houd de oude app een korte periode beschikbaar met alleen leesrechten, zodat niemand gegevens mist. Zeg daarna de licenties op die je niet meer nodig hebt en ruim de connectors en accounts op.
Vijf valkuilen bij de overstap
- De oude app één op één nabouwen. Een deel van de schermen bestaat alleen omdat het platform iets niet kon. Neem het proces als uitgangspunt.
- Vergeten wat het platform zelf regelde. Inloggen, rollen, logboeken en het uitrollen van versies richt je in maatwerk zelf in. Plan ze vanaf het begin.
- Alles in één keer overzetten. Een overstap op één datum stapelt alle risico's op één dag. In stappen heb je steeds een weg terug.
- De makers buiten de deur houden. Zij kennen de regels en uitzonderingen het best. Geef ze een vaste rol bij de inventarisatie en het testen.
- De licentietermijn uit het oog verliezen. Loopt het contract af voordat de nieuwe software klaar is, dan verleng je onder tijdsdruk. Plan terug vanaf de einddatum.
Maatwerk laten bouwen met Isatis
Isatis bouwt bedrijfssoftware op maat, met teams in Nijmegen en Sarajevo. We doen dat al meer dan 30 jaar, met 30+ engineers en meer dan 100 projecten, en zijn gecertificeerd voor ISO 9001 en ISO 27001. Lees hoe we werken op onze pagina over maatwerksoftware laten ontwikkelen.
Twijfel je of een app in low code kan blijven, plan dan een gesprek. We zeggen het ook als het platform voor jouw app nog volstaat.
Veelgestelde vragen
Wat is het verschil tussen low code en maatwerk?
Bij low code bouw je een app met visuele modellen, en het platform van de leverancier voert die uit. Bij maatwerk schrijven ontwikkelaars de code en bepaal je zelf waar de software draait. Low code is sneller voor standaardapps, maatwerk geeft meer vrijheid bij complexe logica, veel gebruikers en lastige koppelingen.
Wanneer is low code de juiste keuze?
Bij interne apps met formulieren en vaste workflows, bij een eerste versie om een idee te toetsen en als je geen eigen ontwikkelaars hebt. Blijven logica, gebruikers en koppelingen overzichtelijk, dan kan zo'n app jaren goed werken.
Kun je low code en maatwerk combineren?
Ja. Bouw de kern in maatwerk met een API, en laat kleine low code apps via die API gegevens ophalen en wegschrijven. De belangrijkste regels staan dan op één plek.
Wat is een alternatief voor Mendix als je app niet meer schaalt?
Je kunt naar een ander low code platform of naar maatwerk. In beide gevallen bouw je de app opnieuw, want elk platform werkt met een eigen model. Groeit de app vooral in logica, gebruikers en koppelingen, dan ligt maatwerk meer voor de hand.
Hoe lang duurt een overstap van low code naar maatwerk?
Dat hangt af van de omvang van de app, de koppelingen en de hoeveelheid data. Omdat je in stappen werkt, gaat het eerste onderdeel vaak al live terwijl de rest nog in de oude app draait.
