Wat is een forward deployed engineer?

De term duikt sinds 2025 overal op in Amerikaanse vacatures, en sinds kort ook in Nederlandse. In het Nederlands is er nauwelijks uitleg over te vinden. Deze pagina beschrijft wat de rol inhoudt, waar hij vandaan komt, hoe hij verschilt van een consultant of een softwareleverancier, en wanneer een middelgroot bedrijf er iets aan heeft.

Wat is een forward deployed engineer?

Een forward deployed engineer is een softwareontwikkelaar die binnen uw organisatie meeloopt in plaats van op afstand te werken. Hij ziet het werk zelf gebeuren, schrijft de oplossing ter plekke en blijft verantwoordelijk tot uw mensen ermee werken. Adviseren en bouwen liggen bij dezelfde persoon. De rol komt uit de Amerikaanse software-industrie.

Het Nederlands heeft er geen goed woord voor. “Ingebedde ontwikkelaar” dekt de lading, maar niemand gebruikt het. Het zwaartepunt zit trouwens niet in het woord *engineer* maar in *deployed*: uitgezonden, geplaatst, aan de voorkant. Iemand die niet wacht tot de opdracht is uitgeschreven, maar naar de werkvloer gaat om te zien waar het schuurt.

Waar komt de rol vandaan?

De rol is groot geworden bij Palantir, een Amerikaans softwarebedrijf dat data-analyse levert aan overheden en grote concerns. Hun software was te eigenaardig om per handleiding uit te leggen. Dus stuurden ze ontwikkelaars mee naar binnen. Nu AI-modellen dezelfde vertaalslag vragen, nemen andere techbedrijven en adviesbureaus die aanpak over.

Dat laatste is de reden dat u de term ineens tegenkomt. Een taalmodel of een AI-dienst is op zichzelf niets waard voor een bedrijf. De waarde ontstaat pas als iemand precies begrijpt hoe uw offertes eruitgaan, welke uitzonderingen uw planners dagelijks handmatig oplossen, en welk veld in uw boekhouding altijd verkeerd wordt ingevuld. Die kennis staat nergens opgeschreven. Ze zit in de hoofden van uw mensen, en je haalt haar er alleen uit door ernaast te gaan zitten.

Wat doet een forward deployed engineer anders dan een consultant of een softwareleverancier?

Een consultant schrijft op wat er moet gebeuren en gaat weg. Een softwareleverancier levert een pakket waar u zich naar voegt. Een forward deployed engineer doet allebei niet: hij formuleert het probleem samen met uw mensen, bouwt de oplossing zelf en is pas klaar als die in gebruik is.

Het verschil zit in vijf vragen. Waar zit iemand, wie formuleert het probleem, wie bouwt, wanneer is het klaar, en wat gaat er mis als het misgaat.

Geen van deze vier is per definitie de beste keus. Een consultant is sterk wanneer u een oordeel van buiten nodig hebt. Een standaardpakket is verstandig zodra uw vraag hetzelfde is als die van duizend andere bedrijven. Een eigen IT’er is onmisbaar voor beheer. De ingebedde ontwikkelaar wint bij één type probleem: het probleem dat niemand vooraf precies kan opschrijven.

Hoe groot is deze rol geworden?

Groot, en snel. Het aantal vacatures voor deze rol op Indeed steeg tussen april 2025 en april 2026 met ongeveer 729 procent. In de Verenigde Staten bracht een wervingsbureau ongeveer 17.000 mensen met dit profiel in kaart. Minder dan 2.000 daarvan had het meermaals aantoonbaar tot in productie gebracht.

Dat tweede getal is het interessantste. Het profiel is zeldzaam omdat het twee dingen tegelijk vraagt die zelden in één persoon zitten: kunnen bouwen, en een gesprek kunnen voeren met een magazijnchef die geen zin heeft in verandering. Wie alleen het eerste kan, levert software die niemand gebruikt. Wie alleen het tweede kan, levert een presentatie.

In Nederland is de rol vooral zichtbaar bij grote techleveranciers en adviesbureaus, die er in Amsterdam op werven. Een betrouwbare telling voor de Nederlandse markt bestaat voor zover wij konden nagaan niet. De cijfers hierboven gaan over de Verenigde Staten; wie ze op Nederland plakt, verzint iets.

Bronnen bij deze cijfers: vacaturedata van Indeed, gedeeld met Business Insider; en onderzoek van executive-searchbureau Christian & Timbers, gepubliceerd door TechCrunch op 30 juli 2026.

Wanneer heeft dit voor een mkb-bedrijf zin?

Het heeft zin als het probleem in uw eigen manier van werken zit en niemand het van tevoren precies kan opschrijven. Dan wint u bij iemand die naast uw mensen gaat zitten. Zit de oplossing in een pakket dat duizend bedrijven ook gebruiken, koop dan dat pakket.

In de praktijk gaat het meestal om werk dat is vastgelopen tussen systemen. Uw urenregistratie kent uw projecten niet. Uw boekhouding in Exact Online of SnelStart weet niet welke offerte erbij hoort. Iemand typt elke maandag hetzelfde rijtje over. Dat is geen probleem dat een pakket oplost, want geen pakket weet hoe uw bedrijf werkt. Het is ook geen probleem dat een advies oplost, want u wist zelf allang dat het niet klopt.

Wanneer is het juist niet de goede keuze?

Deze werkwijze is niet de goede keuze wanneer de vraag al scherp op papier staat en er standaardsoftware voor bestaat. Ook niet wanneer u niemand kunt vrijmaken die beslissingen mag nemen, want de aanpak leunt op toegang tot uw mensen. En niet voor werk dat over een half jaar toch verdwijnt.

Er is nog een reden om het niet te doen: als u eigenlijk alleen extra handen zoekt. Iemand die binnenloopt en meebouwt, kost aandacht van uw kant. Hij stelt vragen aan uw planner, loopt een dag mee op kantoor en wil weten waarom dat ene veld altijd leeg blijft. Hebt u die ruimte niet, dan is een afgebakende opdracht bij een bouwer op afstand eerlijker — en verstandiger.

Wat kost een forward deployed engineer?

Dat hangt af van welke vraag u stelt. Vraagt u wat iemand per dag kost, dan koopt u aanwezigheid en zegt het tarief weinig. Vraagt u wat het kost om uw probleem opgelost te krijgen, dan koopt u een uitkomst en valt dat uiteen in drie stukken: scherp krijgen wat er moet gebeuren, bouwen, en in gebruik nemen.

Wat de prijs werkelijk bepaalt is geen tarief maar de vraag hoe helder het probleem is. De vormen, de valkuilen en de manier om klein te beginnen staan op een forward deployed engineer inhuren.

Bestaat er een opleiding of certificaat voor?

Nee, en dat is geen tekortkoming maar het gevolg van hoe de rol is ontstaan.

Er wordt inmiddels van alles aangeboden onder deze naam, en er zijn grote adviesbureaus die er een functietitel van hebben gemaakt. Een papiertje zegt hier alleen niets, want wat de rol vraagt is niet één vaardigheid maar een combinatie: kunnen bouwen, én bij een vreemd bedrijf binnen kunnen lopen en de goede vragen stellen aan iemand die geen zin heeft in een gesprek.

Dat leert u niet op een cursus. Dat blijkt uit wat iemand eerder heeft opgeleverd en uit hoe hij zich gedraagt in de eerste week. In de volgende paragraaf staat waar u dan op let.

Wat merkt u ervan als iemand bij u binnenloopt in plaats van adviseert?

U merkt het aan het tempo en aan de vragen. Er komt geen rapport na zes weken, maar iets werkends na een paar dagen. De vragen gaan over uitzonderingen: wat gebeurt er als een order afwijkt, wie belt de klant dan. En het werk stopt niet bij de oplevering, maar bij het gebruik.

Dat verandert ook wat u er zelf voor moet doen. U levert geen bestek aan, maar toegang: tot uw mensen, tot uw systemen, tot het rommelige echte werk. Daar staat iets tegenover. Omdat de bouwer het werk met eigen ogen heeft gezien, hoeft u niet te hopen dat hij het goed heeft begrepen. En omdat er vroeg iets werkends is, kunt u bijsturen voordat de rest gebouwd is — in plaats van erna.

Hoe herkent u iemand die deze rol echt invult?

Vraag drie dingen na. Loopt hij daadwerkelijk mee bij de klant, of alleen tijdens de kennismaking. Levert hij werkende software, of een document. En kan hij noemen wat er ná livegang veranderde in de cijfers van die klant. Ontbreekt dat laatste, dan koopt u advies met een nieuwe naam.

De term is nieuw en aantrekkelijk, en dat trekt bordjes aan die de lading niet dekken. Een ontwikkelaar die één keer op locatie is geweest, is nog geen ingebedde ontwikkelaar. Het onderscheid zit in eigenaarschap ná de livegang.

Sinds de rol populair werd, is er in de internationale ontwikkelaarsgemeenschap een tamelijk eensluidend beeld ontstaan van wat iemand moet kunnen. Vertaald naar uw kant van de tafel levert dat vijf toetsen op die u kunt uitvoeren zonder zelf technisch te zijn:

Bouwt hij, of stelt hij in? Iemand die deze rol invult schrijft software die de productie in gaat, kent databases en kan koppelingen leggen. Wie alleen bestaande pakketten kan instellen, is een consultant met een moderner bordje.

Kan hij een vage vraag opdelen? Dit is de kern van het werk. “Onze offertes moeten sneller” is geen opdracht maar een klacht. Iemand die daar binnen een gesprek concrete stappen van maakt, en durft te zeggen welk deel hij níét gaat doen, kan het. Iemand die alles opschrijft en met een wensenlijst terugkomt, niet.

Blijft staan wat er al staat? Nieuwe software moet werken naast wat er al draait, ook als dat oud is. Vraag hoe hij dat aanpakt. Het antwoord “dat vervangen we gewoon” is een groter risico dan het probleem waarvoor u hem haalt.

Is het een ervaren iemand? In de gemeenschap waar deze rol vandaan komt, is men het er breed over eens dat dit geen functie is voor iemand die net begint. Het vraagt breedte, niet één specialisme. Krijgt u onder deze naam een junior aangeboden tegen een seniortarief, dan klopt er iets niet.

Praat hij in uw woorden? Een afweging tussen twee oplossingen moet hij kunnen uitleggen in wat het u kost en oplevert, niet in techniek. Dit is de belangrijkste toets en tegelijk de enige die u vooraf niet hard kunt maken. Die merkt u in de eerste week — en dat is precies waarom een korte eerste opdracht zoveel beter werkt dan een lang gesprek.

Wanneer weet u of iemand dit kan?

Niet aan een diploma, want dit wordt nergens onderwezen. En ook niet alleen aan jaren ervaring, want ervaring leert u hoe het vorige geval liep en niet hoe dit geval anders is.

Wat het wél vraagt is een ongebruikelijke stapeling. Een probleem kunnen ontleden. Er iets voor kunnen bedenken dat nog niet bestaat. Dat technisch kunnen maken. En het daarna kunnen uitleggen in gewone woorden, kunnen presenteren, en op papier kunnen laten zien — want een oplossing die niemand kan navertellen, wordt niet gekozen.

De scherpste toets zit in dat uitleggen, en die is makkelijker dan hij lijkt. Aan tafel zitten altijd drie soorten mensen: iemand die er niets van snapt en er wel over beslist, iemand die het vak kent en meteen doorheeft waar het wringt, en degene die het uiteindelijk moet programmeren. Alle drie moeten ze hetzelfde verhaal krijgen, in andere woorden, zonder dat het een ander verhaal wordt.

Wie dat kan, kan dit werk. Wie alleen de eerste of alleen de laatste kan bedienen, is iets anders — een adviseur of een bouwer, allebei nuttig, maar niet dit.

Waarom lost iemand die anders denkt dit vaker op?

Omdat de oplossing bijna nooit de voor de hand liggende is.

Denk aan wat iemand doet die geen kleuren kan onderscheiden. Die zoekt een omweg: op de volgorde af, op de plek, op de vorm, op wat er nog meer klopt. Het resultaat is hetzelfde — hij weet welke het is — maar de route ernaartoe heeft hij zelf moeten uitvinden. Hetzelfde geldt voor iemand met dyslexie, met ADD of met ADHD: de gewone weg werkte niet, dus is er een andere bedacht en die is jarenlang bijgeschaafd.

Wat daarvan overblijft is geen beperking maar een gewoonte. Nooit de makkelijkste weg nemen omdat die er niet was. Altijd blijven zoeken naar een deur die wél opengaat. Hersenen die aan blijven staan op een manier die niet standaard is, omdat ze dat nooit anders hebben geleerd.

Precies dat is wat er nodig is als een probleem niet in een bestaand pakket past. En het is een waarneming, geen regel: u heeft dit niet nodig om er goed in te zijn, en het is geen garantie dat u het bent.

Het aardige is dat de uitkomst er meestal niet ingewikkeld uitziet maar juist eenvoudig. De beste oplossingen die wij hebben gebouwd, leken achteraf voor de hand te liggen. Dat waren ze niet, want dan had iemand ze al bedacht. Als het makkelijk kon, kon iedereen het.

Voor u als opdrachtgever is dat een bruikbare toets. Vraag naar iets wat ooit vastliep en hoe het alsnog is opgelost. Komt daar een lang technisch verhaal uit, dan koopt u complexiteit. Komt er een eenvoudige ingreep uit die u zelf niet had bedacht, dan zit u goed.

Waarom gaat bijna alles wat u hierover vindt over banen?

Omdat de vraag naar deze mensen harder groeit dan het aanbod, en de meeste teksten dus geschreven zijn voor ontwikkelaars die de stap willen maken. U vindt vacatures, salarisvergelijkingen, cursussen en discussies tussen programmeurs onderling over wat je ervoor moet kunnen.

Dat is nuttig om te weten, want het verklaart waarom u zo weinig vindt over de vraag die u waarschijnlijk hééft: niet hoe u er één wordt, maar of u er één nodig heeft en waar u dan op let.

Kort antwoord daarop: u heeft dit nodig als uw probleem nog niet scherp is, en u heeft het niet nodig als u precies weet wat er gebouwd moet worden. In dat tweede geval koopt u een afgebakende opdracht bij een bouwer, en dat is goedkoper. Waar de grens ligt, staat hierboven onder wanneer het wél en niet de goede keuze is.

En let op de cursussen en certificaten die inmiddels onder deze naam worden verkocht. Die zijn er voor de mensen die de baan willen, niet voor de bedrijven die het werk willen laten doen. Er bestaat geen keurmerk dat u iets vertelt over de vraag of iemand bij ú het verschil gaat maken.

Hoe schakelt u er een in?

Niet met een vacature, en meestal ook niet met een bureau dat capaciteit per dag levert. Wat werkt is een kleine eerste opdracht met een duidelijk einde: iemand loopt een paar dagen mee, legt vast wat er echt gebeurt, en levert een voorstel op waarin ook staat wat er bewust níét gebouwd wordt.

Let daarbij vooral op of degene die het gesprek voert ook degene is die komt. De drie manieren om dit te regelen en wat u bij elke vorm precies koopt, staan op een forward deployed engineer inhuren.

Hoe noemen wij het zelf?

Bedrijfsanalist. Dat is het woord dat wij in gesprekken gebruiken, en het dekt de lading beter dan de Engelse term. Wat zo iemand precies oplevert en waarin hij verschilt van een consultant of een projectleider, staat op een bedrijfsanalist inhuren.

Wat zo iemand doet, is vertalen wat iemand bedoelt naar een functioneel ontwerp en daarna naar een werkende oplossing. Dat klinkt eenvoudiger dan het is, want een klant beschrijft zelden een oplossing. Hij beschrijft last. De kunst zit in het doorvragen tot duidelijk is wat er werkelijk moet gebeuren, en daarna in het bedenken van iets wat er nog niet is.

Want die oplossing ligt meestal niet in een schap. Er bestaat geen pakket dat precies uw manier van werken kent, dus moet er iets worden bedacht, gemaakt en vervolgens net zo lang bijgeschaafd tot het klopt. Dat gaat met proberen. Iets bouwen, ernaar kijken, voelen dat het nog niet goed is, en het anders doen. Wie belooft dat het in één keer raak is, heeft dit werk niet gedaan.

Het zit in uw hoofd — hoe krijgt u het eruit?

Dit is waar de meeste goede ideeën blijven steken, en het is zelden een gebrek aan techniek.

U weet wat het moet doen. U ziet voor u hoe het zou werken, u weet welke stap dan verdwijnt en waarom uw mensen er blij mee zouden zijn. Wat u niet heeft is de vertaling: de omschrijving waarmee iemand anders het kan bouwen zoals u het bedoelde en niet zoals hij het las.

Dat vertalen is het lastigste deel van het hele traject, en het is precies wat er misgaat als u het overslaat. Een bouwer die een half begrepen opdracht krijgt, bouwt netjes het verkeerde. Hij vraagt niet door, want hij denkt dat hij het begrijpt — en u merkt het pas als het er staat.

Wij vinden dat vertalen niet lastig; dat is nu juist waar wij voor komen. Wij zijn doeners die denken en bedenkers die bouwen, en dat is geen woordspel maar het verschil tussen een rapport en iets dat werkt. Zet het op papier, werk het uit, en maak het.

En technisch gezien kan er veel meer dan de meeste mensen aannemen. Een samensteller die een prijs uitrekent, een proces dat zichzelf afhandelt, een vervelende taak die verdwijnt, of dat ene ding dat u al jaren wilt maar waarvan u niet wist hoe u het moest uitleggen. De vraag is bijna nooit of het kan. De vraag is of het de moeite waard is, en dat rekenen wij liever eerlijk voor dan achteraf.

Waarom is dit voor de helft mensenwerk?

Omdat een oplossing die op papier klopt, nog door mensen gedragen moet worden.

Er zijn bijna altijd meerdere wegen, met elk hun eigen prijs. Kiezen betekent concessies doen, en die concessies raken zelden alleen de techniek. Ze raken hoe iemand zijn dag indeelt, wie waar over gaat en welke stap er verdwijnt. Dat moet u niet mededelen maar bespreken, en soms moet u een heel team meekrijgen voor iets waar één iemand enthousiast over is.

En er is nog een gevoelig moment dat er bijna altijd komt. Tijdens het uitzoeken blijkt dat iets al jaren op een omslachtige manier gebeurt terwijl het veel eenvoudiger kon. Dat is een prettige ontdekking voor het bedrijf en een ongemakkelijke voor degene die het al die jaren zo deed — zeker als hij het zelf zo heeft ingericht.

Hoe u daarmee omgaat, bepaalt of het traject slaagt. Wij brengen zo’n vondst dus niet als een fout maar als informatie, met de context erbij: waarom het toen wél logisch was, en wat er sindsdien is veranderd waardoor het nu anders kan. Iemand goed informeren is hier het werk, niet gelijk krijgen. Dat onderwerp gaat verder op wat als uw mensen er niet op zitten te wachten.

Heet dit ook anders?

Ja, en de termen lopen door elkaar. In het Engels heet het *forward deployed engineer*, afgekort FDE, en dat is ook de naam waaronder u er het meeste over vindt. In vacatureteksten en op internationale sites komt u *forward deployment engineer*, *embedded engineer*, *solutions engineer* en *field engineer* tegen. In het Nederlands is er geen ingeburgerde vertaling en de term blijft in de praktijk gewoon Engels. Wordt hij toch vertaald, dan is het meestal *op locatie gedetacheerde software engineer*, *on-site technisch consultant* of *implementatie engineer* — drie namen die elk een ander stuk van het werk benadrukken: waar iemand zit, wat hij adviseert, en dat het werkend moet worden binnen wat er al draait. Wij noemen het zelf bedrijfsanalist, om de reden die hierboven staat.

Het woord *forward deployed* komt overigens uit militair taalgebruik en betekent daar zoiets als vooruitgeschoven: niet op de basis, maar in het veld. Dat is precies het verschil dat de term wil maken.

De Engelse omschrijving die het vaakst wordt aangehaald, luidt: iemand die zich binnen de organisatie van de klant nestelt om daar software of AI te bouwen, aan te passen en in gebruik te nemen, in de omgeving waarin het echt moet werken. Dat dekt de lading, met één aanvulling die er zelden bij staat: het werk is pas af als het gebruikt wordt.

Werkt Cloudzicht op deze manier?

Ja. Cloudzicht noemt de werkwijze Forward Deployed Engineering: wij lopen mee, zetten uw wens om in een functionele omschrijving die u zelf kunt nalezen, en bouwen daarna zelf de software. Wij zijn pas klaar wanneer uw mensen ermee werken, niet wanneer de oplevering getekend is.

Wat dat oplevert, leest u bij software laten maken en systemen aan elkaar knopen. De branche waar wij vandaan komen staat beschreven bij software voor installatiebedrijven, met een offerteconfigurator die zichzelf doorrekent als voorbeeld. Wilt u weten of uw vraag zich hiervoor leent? Bel 036 52 98 447 of mail info@cloudzicht.nl.