Forward deployed engineers who stay until it runs.

A forward deployed engineer works inside your organization rather than beside it: your repository, your data, your authentication, your release path. They write production code and they stay accountable until the system is running. That is the model Palantir created and AWS, OpenAI and Anthropic now run, and it is what we do.

This page is what we sell and how it is bounded. If you want the subject rather than the sales pitch, the forward deployed engineering guide is 46 pages of it, including the case against the model and the questions to ask us.

What you get

Engineers in your repository. Not a design document and not a proof of concept somebody else hardens. Code that gets merged and runs. Around 80 percent of the week goes on building, which is the split First Round Review describes as healthy and the one that separates this work from presales.

Discovery inside the environment. The reason the model exists is that the specification cannot be written from outside. We sit with the people who will use the thing, query the real tables, and produce the list of what differs from the description. That list arrives in the first fortnight and it is the most useful thing you will get early.

Something running in week one. Small, real, against production data. It is a scoping instrument rather than a demo: what breaks tells us more than a planning document would.

A mapped path to production. In week one we ask what has to be true for a change to reach live, who signs each step, and how long each has historically taken. That answer sets the schedule more than the build does, and discovering it in month three is how deployments slip.

What is different here

The code is AI-written and an eval suite proves it. Every change has to pass checks derived from the specification, written before the code exists, and graded by something other than the model that produced the code. Generated code is not secure by default, which is exactly why the verification is the product rather than an afterthought.

Which is why the price is different. We use AI instead of hiring more engineers, so the same build takes a small team, and that saving goes into your price rather than our margin. It applies to a portion of the work: discovery, integration and getting through your approval path still take human time. We do not publish a percentage, because no discount has been measured and a number we cannot show the working for is worth nothing.

The eval suite is also the handover. Documentation tells your team how the system works today. A runnable suite tells them whether their change broke it, which is the only version that lets them own it.

The boundary

Two dates go in the contract before we start.

A production date. The date the defined system is running for real users. Not a design delivery date and not a pilot date.

A handover date. The date we stop operating it and your engineers take over, with a named person on your side who has been involved since the production phase, and a handover test: your engineer ships a real change through your real release path, unaided, while we are still there to watch it fail.

We are explicit about this because the failure mode of the model is the engagement that never ends. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, and that is the right standard. An engagement without an ending has stopped being a deployment.

Two ways to buy it

A pod on your problem. You have an outcome that has to reach production inside your environment. We take it, with the two dates named.

Engineers into your customer accounts. You sell AI into large companies and the gap between your product working and your customer getting value is measured in weeks of engineering. We supply the delivery arm, working under your brand or alongside it. This is the as-a-service route, and it exists because building the function in-house takes a hiring cycle plus two or three engagements of learning.

What we will tell you not to buy

If your scope is writable and you have senior technical leadership making the calls, you want senior hands under your direction, which is staff augmentation and costs less. The comparison is here.

If your customers all want the same thing, an embedded engineer is an expensive way to run a configuration wizard, and the money is better spent on implementation templates and documentation.

If your contract values cannot carry an engineer for a quarter, no vendor arrangement fixes that. Work out one loaded engineer-quarter against the value of the deployment before you talk to anybody, including us. What it costs has the arithmetic.

What we cannot show you

We have no client testimonials and no completed-handover reference, because Reveneau is new and inventing either is the fastest way for a consultancy to become untrustworthy. What we will do is put both dates in the contract, tell you exactly what proves the code correct, and hand you an eval suite your team can run.

If you want to check us against the market first, how to choose a partner is the criteria we would want to be judged on.

References

• First Round Review, So You Want to Hire a Forward Deployed Engineer (24 February 2026): https://review.firstround.com/so-you-want-to-hire-a-forward-deployed-engineer/ . Source for the roughly 20 percent customer-facing and 80 percent building split.
• Amazon, AWS invests $1 billion to embed AI forward deployed engineers with customers: https://www.aboutamazon.com/news/aws/aws-1-billion-forward-deployed-ai-engineers . Source for customer self-sufficiency as a stated design goal and for pricing on business results rather than billable hours.
• Veracode, spring 2026 GenAI code security research: https://www.veracode.com/blog/spring-2026-genai-code-security/ . Generated code is not secure by default, which is why the eval suite is graded independently of the model that wrote the code.