Forward-deployed engineers: wanneer je AI-startup er een moet aannemen, en hoe je geen adviesbureau wordt (2026)

25 juli 2026
9 min read

25 juli 2026
9 min read
Scroll deze maand door founder-X en één functietitel duikt steeds weer op: de forward-deployed engineer. Het aantal vacatures voor de rol is in een jaar meer dan vertienvoudigd, AWS heeft een eigen organisatie voor forward-deployed engineering opgezet met naar verluidt een investering van een miljard dollar erachter, en halverwege 2026 probeert bijna elke AI-startup in de Series A met een contract van zes cijfers er minstens één aan te nemen. Op Reddit loopt hetzelfde gesprek, met meer onrust erbij: is dit de rol die enterprise-AI eindelijk live krijgt, of een beleefde manier om een adviesbedrijf op te bouwen en het een productbedrijf te noemen?
Beide lezingen hebben deels gelijk, en juist die spanning maakt de rol belangrijk voor founders. Een FDE is het antwoord op het laatste-mijlprobleem in AI: het model is het makkelijke deel, en het rommelige werk om het een echte taak te laten doen binnen de echte systemen van een klant is waar deals worden gewonnen of verloren. Doe je het goed, dan wordt het je snelste weg naar product-market fit. Doe je het fout, dan verandert je startup ongemerkt in een dienstverlener met slechtere marges dan je denkt. Dit is een gids voor founders over wat de rol echt is, wanneer je de eerste aanneemt en hoe je ervoor zorgt dat die product blijft bouwen.
Een forward-deployed engineer is een engineer met klantgevoel die zich zo'n 60 tot 180 dagen in de omgeving van een klant nestelt, echte integraties oplevert en een vaag zakelijk probleem omzet in werkende software. Het resultaat is productiecode, geen slidedecks of discoverydocumenten. Palantir bedacht de functie rond 2008; OpenAI en Anthropic bouwden haar in 2023 opnieuw op voor het tijdperk van taalmodellen; in 2026 heeft ze zich verspreid van de frontierlabs naar bedrijven als Sierra, Decagon, Databricks en een lange staart van goed gefinancierde startups.
Het onderscheid dat telt, is dat tussen een FDE en een traditionele solutions engineer. Een solutions engineer ondersteunt een verkoop en configureert bestaande functies. Een FDE schrijft code die in de stack van de klant belandt en die, als de aanpak gezond is, ook terugkomt in je eigen productrepo. Ze staan dichter bij een field engineer dan bij een presales-rol, en de besten voelen zich even thuis in de verouderde database van een klant als in je eigen codebase.
De FDE-boom is het logische gevolg van een verschuiving waar dit jaar veel over is geschreven: AI verlaat de demo en begint het werk te doen. Toen je product een copiloot was die dingen voorstelde, kon een klant het met een login in gebruik nemen. Nu je product een systeem is dat een afgebakende taak afrondt (facturen afstemmen, tickets oplossen, aangiftes voorbereiden), moet het aansluiten op rechten, goedkeuringen, verouderde software en menselijke workarounds die geen twee klanten delen. Dat integratiewerk is de laatste mijl, en het reageert niet op een betere prompt.
Daarom past de FDE ook zo natuurlijk bij de these van 'systems of action'. Als de duurzame AI-bedrijven de bedrijven zijn die een afgebakende workflow met geprivilegieerde toegang bezitten, dan moet iemand het product fysiek in de realiteit van elke klant inbouwen en wat hij leert terugvoeren naar het kernproduct. De FDE is het menselijke mechanisme dat één zwaarbevochten enterprise-implementatie omzet in een herhaalbare capaciteit die de hele productlijn erft.
Het laatste-mijlprobleem
In enterprise-AI is het model zelden het moeilijke deel. Het moeilijke deel is de laatste mijl: de vorm van de data van de klant, rechten, goedkeuringsketens en verouderde systemen. FDE's bestaan omdat die mijl niet te verkopen, te documenteren of weg te prompten is: hij moet ter plekke worden geëngineerd.
Dit is de fout die de Reddit-helft van het debat domineert. Founders hangen FDE's in de go-to-market-organisatie als omgedoopte solutions engineers, afgerekend op gesloten deals en afgehandelde tickets. Die structuur optimaliseert ongemerkt voor eenmalig maatwerk, omdat niets erin beloont dat maatwerk product wordt. Doe dat lang genoeg en je hebt een adviesbureau met een softwarelogo: veel omzet, dunne marges en een roadmap die wordt gedicteerd door de klant die vorig kwartaal het hardst riep.
Het patroon dat dit voorkomt, oorspronkelijk gebruikt bij Palantir en nu bij Anthropic, is FDE's onder engineering te plaatsen in plaats van onder sales. Fulltime engineers rouleren tussen klantlocaties en de kerncodebase, en van het werk dat ze in het veld doen wordt verwacht dat het product wordt. Rapporteren aan engineering creëert een permanente neiging om te productiseren wat er wordt gebouwd, omdat dezelfde mensen die de maatwerkintegratie opleveren haar ook moeten onderhouden, en dus gemotiveerd zijn om haar te generaliseren in het platform.
De productisatietest
Stel na elke implementatie één vraag: wat heeft de FDE voor deze klant gebouwd dat nu gratis naar de volgende gaat? Is het eerlijke antwoord 'niets, het was allemaal maatwerk', dan run je een dienstverlener. Is het een nieuwe connector, template of capaciteit in het kernproduct, dan run je een productbedrijf met een veldteam.
De timing is belangrijker dan de hire zelf. Het signaal om je eerste FDE binnen te halen is niet 'we willen aan enterprises verkopen', maar dat je al zo'n drie herhaalbare enterprise-pilots boven een betekenisvolle contractwaarde hebt gesloten, en dat jij, de founder, de bottleneck bent geworden in het integratiewerk bij klanten. Met andere woorden: neem de rol aan zodra de vraag bewezen is en je eigen tijd de beperking is, niet eerder.
Neem je te vroeg iemand aan, dan betaal je een senior engineer om vraag te fabriceren die nog niet bestaat, en kom je in de verleiding elk maatwerkproject aan te nemen om de kosten te rechtvaardigen. Neem je te laat iemand aan, dan loopt elke deal vast in de implementatie terwijl jij om middernacht zelf klantomgevingen debugt. Het venster gaat open wanneer het patroon over pilots heen duidelijk genoeg is dat een FDE het kan generaliseren, en sluit zodra trage integratie je groei begint af te remmen.
Founders moeten nuchter naar de kosten kijken, want dit is geen junior hire. De totale beloning voor de rol loopt van ongeveer $200K in de seedfase tot $450K–$550K en meer in de Series C, waarbij vacatures van frontierlabs boven de gangbare schalen voor product-engineers zitten; senior FDE's bij de toplabs rapporteren medianen rond $485K, en functies op staff-niveau nog hoger. Je betaalt voor een zeldzame combinatie van opleverkracht en klantgevoel, en de markt daarvoor is echt krap.
Die prijs is alleen zinvol tegenover echte contractwaarde. Als één FDE deals van zes cijfers ontsluit en uitbreidt die anders zouden vastlopen, is de rekensom makkelijk. Als hij contracten van minder dan $50K overeind houdt met veel maatwerk, staat het model op zijn kop, en is dat een teken dat het product nog niet klaar is voor de enterprise-aanpak.
Voor de meeste founders die dit lezen (vóór de Series A, op jacht naar de eerste handvol echte klanten) is de praktische les niet om een vacature te plaatsen. Het is erkennen dat je zelf al de forward-deployed engineer bent, en de aanpak bewust uit te voeren. Ga in de omgevingen van je eerste klanten zitten, lever de integratie zelf op en behandel elke maatwerkoplossing als een onderzoeksnotitie over wat het product native zou moeten doen. De patronen die je in deze fase ontdekt, zijn wat de latere FDE-hire productief maakt in plaats van duur.
De forward-deployed engineer is geen modetitel; het is de sector die toegeeft dat AI in de echte wereld krijgen een engineeringprobleem is, geen salesprobleem. Founders die dat begrijpen (die vroeg ingebed werken, onophoudelijk productiseren en de rol pas aannemen als het patroon bewezen is) maken van de laatste mijl, die eerst hun deals om zeep hielp, de slotgracht die hen beschermt.

IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.