Forward deployed engineer: de consultant die zelf bouwt
Waar de rol vandaan komt, hoe ze werkt, en waarom ze plots overal opduikt. Een volledig beeld van een functie die ongeveer twintig jaar bestond voor ze een naam kreeg.
Wat is het precies?
Een forward deployed engineer, kortweg FDE, is een ontwikkelaar die niet vanop afstand software oplevert maar bij de klant zelf komt zitten. De rol combineert drie dingen die zelden in één functie samenkomen: echt software bouwen, meewerken met de verkoopkant om een klant binnen te halen, en bijdragen aan het product zelf. De ene week schrijf je code op de systemen van de klant, de andere week zit je met hun mensen rond de tafel om uit te zoeken wat het echte probleem is. Bedrijven vragen doorgaans een stevige technische achtergrond: Palantir neemt soms mensen aan met maar één jaar ervaring, terwijl een scale-up als Ramp voor de senior-rollen liefst vijf jaar of meer ziet.
De naam komt van Palantir
De functie ontstond begin jaren 2010 bij het Amerikaanse Palantir, dat ze intern "Delta" noemde. Het bijzondere: tot ongeveer 2016 had Palantir méér forward deployed engineers dan gewone productontwikkelaars. Deltas hoorden bij de business-development-kant en hadden één opdracht, namelijk bij één klant een technisch resultaat neerzetten door het platform ter plaatse uit te rollen en op maat te maken. Toen Palantir in 2016 zijn dataplatform Foundry lanceerde, schoven veel van die mensen door naar de kernontwikkeling, met hun veldervaring op zak. Geen enkel bedrijf heeft vandaag meer FDE's dan Palantir, en geen enkel bedrijf heeft de rol zo sterk vormgegeven.
Eén klant, veel petten
De kern van het model zit in één tegenstelling: "één capaciteit, veel klanten" tegenover "één klant, veel capaciteiten". Een gewone productontwikkelaar bouwt één ding, en dat gaat naar alle klanten. Een forward deployed engineer draait dat om: één bedrijf, en alles wat dat bedrijf nodig heeft, van datamodellen tot koppelingen tot stabiliteitsfixes. Palantir vat de rol samen als iets wat lijkt op het werk van een startup-CTO: kleine teams, en van begin tot einde verantwoordelijk voor projecten waar veel van afhangt.
Wat doet zo iemand in een week?
De weken wisselen sterk, en dat is net het punt. Grofweg gaat de tijd naar drie dingen. Eerst het klantproject zelf, de hoofdmoot. Dan het platform: waar het product de oplossing in de weg zit, configureer je datamodellen of lever je een stabiliteitsfix aan de kernontwikkeling. En ten slotte het interne werk, overleg, mail en afstemming. Een flink deel van de tijd is ter plaatse, bij Palantir zo'n kwart, bij sommige bedrijven tot de helft. Dat kan letterlijk op een assemblagelijn van Airbus zijn, of op een fabrieksvloer. Eén vaardigheid komt in elk relaas terug: nee kunnen zeggen. Een goede FDE vraagt zich bij elk overleg af of het echt een vergadering moet zijn, en of hij er echt bij moet.
Hoe het verschilt van een gewone ontwikkelaar
Drie dingen maken het anders. Je werkt in veel onzekerheid: wat de klant tijdens de scoping beschrijft, klopt zelden met wat de data en de systemen ter plaatse zeggen, dus je beweegt snel, botst bewust tegen de muren aan en stuurt de scope bij. Je staat dichter bij de verkoop: je haalt een klant mee binnen door te tónen dat de integratie werkt, niet door het te beloven. En je voedt het product: de problemen die je in het veld tegenkomt, bepalen mee wat er gebouwd wordt. Het verschil met een klassieke consultant is de duur. Een consultant geeft een eenmalig advies en vertrekt weer, een forward deployed engineer blijft en bouwt.
Elk bedrijf geeft er zijn eigen invulling aan
Er is geen strak keurslijf, elk bedrijf kiest zijn eigen smaak. Bij OpenAI zitten FDE's bij de klant om samen oplossingen te ontwikkelen in vaak nog ongedefinieerde problemen, en ze schrijven code rechtstreeks op de infrastructuur van de klant, anders dan de meer adviserende solutions architects. Bij Ramp werken ze in kleine pods, dicht tegen de verkoop aan. Salesforce laat ze op maat gemaakte AI-agents bouwen en de volledige data-integratie beheren. Gecko Robotics stuurt ze op zoek naar de problemen met de grootste impact. Lindy gebruikt de rol eerder als technische consultant. Verwante functies als solutions architect, sales engineer of agent engineer lijken erop, maar verschillen vooral in hoeveel je geacht wordt aan het product zelf bij te dragen.
Waarom het nu plots overal opduikt
Sinds begin 2025 is de vraag naar forward deployed engineers ontploft, en de reden is AI. Grote taalmodellen en AI-agents echt aan de praat krijgen binnen een bedrijf is precies het soort werk waar deze rol voor gemaakt is: de technologie is krachtig, maar sluit niet vanzelf aan op de rommelige realiteit van een klant. Durfkapitaalfirma a16z noemde het de heetste job in tech. Het team bij OpenAI groeide op een half jaar van twee naar meer dan tien mensen, verspreid over acht steden op drie continenten. En het levert langs twee kanten iets op. Toen een OpenAI-klant een spraakmodel wilde inzetten voor een callcenter en het model tegenviel, bouwde de FDE meetlatten voor de kwaliteit, bracht de resultaten terug naar het onderzoeksteam, en het model werd beter, voor die klant én voor iedereen erna. Bij landbouwmachinebouwer John Deere reisde het team naar Iowa om, samen met boeren op het veld, gepersonaliseerd advies over onkruidbestrijding op tijd voor het volgende groeiseizoen werkend te krijgen.
De keerzijde
Het is geen rol voor iedereen. Je reist veel, je leeft in onzekerheid, en je schakelt constant tussen bouwen, verkopen en afstemmen. De grens tussen engineering en verkoop is dun, en dat schuurt soms. Bedrijven vinden de rol ook lastig in te vullen: je zoekt iemand die technisch sterk genoeg is om zelf te bouwen, en tegelijk sociaal genoeg om bij een klant vertrouwen te winnen in een omgeving die hij nog niet kent. Die combinatie is zeldzaam, en net daarom gewild.
Waarom ik dit deel
Omdat ik al zo werk sinds lang voor de term bestond. Veertien jaar ter plaatse bij banken, spoorwegen, telecom en energie: aansluiten op de systemen die er stonden, uitzoeken wat de data echt zei, en bouwen aan het probleem dat er echt was. Ik begin read-only, ik benoem wat niet meetbaar is als beperking en niet als kleine lettertjes, en op het einde is alles van jou. Bij een energiebedrijf leverde die aanpak onder meer 1.479 stil verloren ticketsluitingen op die niemand zag, 2,37 miljoen euro aan aanvaarde offertelijnen zonder gekende kostprijs, en een weekrapport van 70.000 API-calls dat ik naar nul bracht. Gemeten, niet geschat.
Dit stuk vat de rol samen zoals ze breder bekend is. De uitgebreide analyse waarop het steunt: Gergely Orosz, Forward Deployed Engineers, The Pragmatic Engineer.
Artikel · Nick Bosmans, 2026