Je vacature staat online, de eerste reacties komen binnen en toch blijft dezelfde twijfel hangen: zijn dit echt de mensen die je low-code team verder helpen, of vooral kandidaten met een mooi cv en weinig relevante platformdiepte?
Die vraag speelt bij low-code vaker dan bij traditionele softwarefuncties. Niet omdat het vakgebied kleiner is alleen, maar omdat titels veel minder zeggen dan in de praktijk nodig is. Een Mendix developer is niet automatisch inzetbaar op OutSystems. Een Power Platform consultant is niet per definitie sterk in complexe enterprise-implementaties. En iemand die technisch prima is, kan alsnog vastlopen als stakeholdermanagement of teamfit ontbreekt.
Hoe vind ik low-code developers zonder tijd te verliezen?
De kortste route begint meestal niet bij sourcing, maar bij scherpte. Veel organisaties starten te breed. Ze zoeken “een low-code developer” terwijl ze eigenlijk iemand nodig hebben die binnen een specifiek platform productief kan zijn, ervaring heeft met een bepaald type landschap en past bij de fase van het team.
Daarom is de eerste vraag niet alleen hoe vind ik low-code developers, maar vooral: wát voor low-code developer zoek je precies?
Gaat het om nieuwbouw of doorontwikkeling? Werk je in een productteam of projectorganisatie? Zoek je iemand voor loondienst of juist interim capaciteit om een piek op te vangen? En minstens zo belangrijk: op welk platform moet deze persoon direct waarde leveren? In Nederland zie je duidelijke niches rond Mendix, OutSystems, Thinkwise, Microsoft Power Platform en WEM. Kandidaten bewegen niet altijd makkelijk tussen die platformen, zeker niet als je inzet op bedrijfskritische applicaties.
Wie dat vooraf niet helder heeft, krijgt vaak veel profielvolume maar weinig kwaliteit. Dan voer je gesprekken die nergens landen, loopt de time-to-hire op en raakt het team intern gefrustreerd.
Begin met platform, rol en context
Een goede intake voor low-code recruitment is concreter dan bij veel andere IT-rollen. Natuurlijk kijk je naar senioriteit en beschikbaarheid, maar de echte selectie zit in de combinatie van platformervaring, rolzwaarte en omgevingsfactoren.
Een developer die uitstekend functioneert in een consultancycontext, met meerdere klanten en veel afwisseling, hoeft niet automatisch gelukkig te worden in een interne enterprise-omgeving met langere besluitvorming. Andersom geldt hetzelfde. Iemand die sterk is in governance, releaseprocessen en stakeholderafstemming binnen een grote organisatie, mist soms juist de snelheid die een scale-up vraagt.
Daar komt nog iets bij: binnen low-code zijn rollen vaak hybride. Je zoekt misschien een developer, maar in de praktijk wil je ook iemand die requirements ophaalt, een business owner meeneemt en technische keuzes kan uitleggen aan niet-techneuten. Zeker in kleinere teams is die combinatie doorslaggevend.
Een bruikbare intake bevat daarom minimaal deze drie lagen: het platform, de inhoud van de rol en de teamcontext. Pas als die drie scherp zijn, kun je gericht zoeken.
Platformervaring is geen detail
Dit klinkt logisch, maar hier gaat het vaak mis. Veel organisaties accepteren een cv met “low-code ervaring” als voldoende basis. In de praktijk zegt dat te weinig. Er is een groot verschil tussen iemand die een platform kent op gebruikersniveau, iemand die enkele projecten heeft gedaan en iemand die echt zelfstandig kan bouwen, troubleshooten en meedenken over architectuur.
Vraag dus niet alleen of iemand met Mendix, OutSystems, Thinkwise of Power Platform heeft gewerkt. Vraag hoe diep die ervaring gaat. Heeft de kandidaat zelfstandig modules ontwikkeld? Werkt hij of zij met integraties, security en deployment? Is er ervaring met governance, performance of complexe procesinrichting? Dat soort vragen scheidt snel de profielen die interessant lijken van de profielen die direct inzetbaar zijn.
Let op de fase van je team
Een eerste of tweede low-code hire vraagt iets anders dan een aanvulling op een volwassen deliveryteam. In een vroege fase heb je vaak iemand nodig die zelf structuur aanbrengt, keuzes durft te maken en comfort heeft met onduidelijkheid. In een groter team draait het vaker om specialisatie, voorspelbaarheid en samenwerking binnen bestaande standaarden.
Dat verschil moet je meenemen in je zoektocht. Anders selecteer je iemand die technisch geschikt is, maar operationeel niet past.
Waar vind je low-code developers in de praktijk?
De open markt is beperkt. Goede low-code developers reageren niet altijd actief op vacatures, zeker niet als ze al op een passend platform werken. Dat betekent dat alleen een vacaturetekst publiceren meestal onvoldoende is.
Je hebt in de praktijk grofweg drie routes. Zelf sourcen via je eigen netwerk en recruitmentkanalen. Actief kandidaten benaderen via platformgerichte zoekopdrachten. Of samenwerken met een partij die al een niche-netwerk in low-code heeft opgebouwd.
Zelf zoeken kan prima werken als je intern tijd, marktkennis en voldoende bereik hebt. Maar het kost vaak meer dan vooraf gedacht wordt. Je moet weten op welke functietitels je zoekt, welke platformen wel en niet uitwisselbaar zijn, hoe je senioriteit leest in cv’s en welke kandidaten daadwerkelijk openstaan voor een gesprek.
Bij specialistische profielen wordt dat snel een vak apart. Juist dan helpt het als de eerste selectie niet alleen op trefwoorden gebeurt, maar ook op inhoud. Een generalistisch bureau ziet sneller “developer = passend”. In low-code is dat te oppervlakkig.
Hoe beoordeel je of iemand echt past?
De grootste fout is selecteren op beschikbaarheid of schaarste. Ja, de markt is krap. Maar een snelle mismatch kost uiteindelijk meer tijd dan een iets langere, gerichte search.
Een goed gesprek met een low-code kandidaat gaat daarom niet alleen over techniek. Natuurlijk wil je weten wat iemand gebouwd heeft, op welk platform en in welke setting. Maar je wilt ook scherp krijgen hoe iemand samenwerkt, keuzes onderbouwt en omgaat met business stakeholders.
Dat is extra relevant omdat low-code teams vaak dicht op de business opereren. Een kandidaat kan technisch sterk zijn, maar als requirements vaag blijven, prioriteiten schuiven en eindgebruikers aangehaakt moeten worden, heb je iemand nodig die daarin overeind blijft.
Vraag dus door op concrete situaties. Hoe is een complexe integratie aangepakt? Wat gebeurde er toen requirements veranderden? Welke rol pakte de kandidaat in refinement of demo’s? Hoe werd omgegaan met kwaliteit, documentatie en overdracht? Daar haal je meer uit dan uit certificeringen alleen.
Freelance of vast – het hangt af van je vraag
Ook dit is geen detail. Als je direct capaciteit nodig hebt voor een lopend traject, is een interim low-code developer of consultant vaak de snelste oplossing. Zeker bij piekbelasting, tijdelijke vervanging of specialistische kennis voor een projectfase.
Zoek je juist continuïteit, teamopbouw en langdurige productontwikkeling, dan is vaste werving logischer. Maar het hangt af van je interne volwassenheid. Sommige organisaties starten bewust met interim om eerst grip te krijgen op platformkeuzes en teaminrichting. Daarna volgt pas de vaste opbouw.
De juiste keuze is dus minder ideologisch dan praktisch. Kijk naar urgentie, kennisbehoefte en de duur van het werk.
Veelvoorkomende valkuilen bij de zoektocht
De eerste valkuil is een te brede functiebeschrijving. Als alles gevraagd wordt, voelt niemand zich echt aangesproken en wordt selectie diffuus.
De tweede is onderschatting van cultuurfit. In kleine low-code teams heeft één verkeerde hire direct impact op snelheid, kwaliteit en samenwerking.
De derde is traagheid. Goede kandidaten zijn vaak snel in gesprek. Als je intake, terugkoppeling en planning te lang laat duren, verlies je mensen die inhoudelijk wel passen.
De vierde is verwarring tussen businessprofiel en technisch profiel. Niet elke consultant is een developer en niet elke developer wil of kan een klantgerichte voortrekkersrol pakken.
Hoe vind ik low-code developers die ook communicatief sterk zijn?
Dat begint met accepteren dat dit schaarser is dan puur technische capaciteit. Juist daarom moet je vooraf bepalen hoeveel communicatie je echt nodig hebt in de rol.
Moet iemand vooral bouwen binnen een duidelijk kader? Dan zijn technische diepgang en leverbetrouwbaarheid leidend. Moet iemand ook workshops draaien, stakeholders meenemen of junioren begeleiden? Dan moet communicatie volwaardig onderdeel zijn van je selectie, niet een bijzin in de vacature.
De beste manier om dat te toetsen is eenvoudig: laat kandidaten hun eigen werk uitleggen. Niet op hoog abstractieniveau, maar concreet. Wat was het probleem, welke keuze is gemaakt en waarom? Kandidaten die techniek kunnen vertalen zonder vaag te worden, zijn vaak ook in de praktijk sterker in team- en klantcommunicatie.
Sneller zoeken zonder in te leveren op kwaliteit
Snelheid en kwaliteit worden vaak tegenover elkaar gezet, terwijl dat niet nodig is als de intake goed staat en de search gericht is. Juist in een nichemarkt helpt focus. Als je weet welk platform, welk niveau en welke context nodig zijn, kun je snel schakelen zonder ruis.
Daar zit ook de meerwaarde van een gespecialiseerde aanpak. Niet meer cv’s, maar eerder de juiste. Niet eindeloos afstemmen, maar korte lijntjes en duidelijke terugkoppeling. Voor organisaties die serieus bouwen met low-code is dat meestal het verschil tussen maanden zoeken en binnen afzienbare tijd echt in gesprek zijn met passende mensen.
Wie in Nederland gericht zoekt naar low-code professionals op Mendix, OutSystems, Thinkwise, Power Platform of WEM, heeft vaak meer aan een inhoudelijke intake dan aan nog een extra vacatureplaatsing. Via Schouten Low-Code Recruitment zien we in de praktijk dat juist die scherpte aan de voorkant de doorlooptijd fors verkort.
Als je nu met die vraag zit – hoe vind ik low-code developers die technisch én menselijk passen – begin dan niet met harder zoeken, maar met preciezer definiëren. Dat bespaart je meestal meer tijd dan welke recruitmenttool dan ook.