Forward deployed engineers who stay until the system is running.

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 where its limits are. 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 that somebody else makes ready for production. 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 work with the people who will use the system, query the real tables, and produce the list of what differs from the description. That list arrives in the first two weeks and it is the most useful thing you will get early.

Something running in week one. Small, real, against production data. It is a tool for defining the scope 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 go live, who approves 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 get delayed.

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 calculation 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 limits

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 releases a real change through your real release path, without help, while we are still there in case it fails.

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 team 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 team, working under your brand or alongside it. This is the as-a-service route, and it exists because building the function inside your company takes a hiring cycle plus two or three engagements of learning.

What we will tell you not to buy

If your scope can be written down and you have senior technical leadership making the decisions, you want senior engineers 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 do setup work that a simple setup tool could do, and the money is better spent on implementation templates and documentation.

If your contract values cannot pay for an engineer for a quarter, no vendor arrangement fixes that. Compare the full cost of one engineer for one 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.