The FDE portfolio: what to build and how to document it

A strong forward deployed engineer portfolio has two or three projects, each built against messy, realistic data and each carrying a decision log: what you chose, what you rejected, who accepted the risk, and what you handed back. A demo shows that code ran once. A decision log shows how you reason when a customer’s constraints push back, and that is most of the job.

Why a decision log beats a demo

A demo answers one question: can you build the thing? The role asks a different one. According to the Pragmatic Engineer, Palantir describes its forward deployed engineers as having a mandate to achieve technical outcomes for customers, and as measuring success by impact on the customer’s goal. Outcomes depend on choices made under constraint, and a recording of a working prototype hides those choices.

The First Round Review stresses that, unlike a solutions consultant or sales engineer, the FDE is still an engineer who writes and debugs production code. So a portfolio needs real code. But the same piece quotes a Palantir alumna who says the role has drifted towards implementation work, away from its origins. Configuration alone does not make a forward deployed engineer. Judgement about what to build, and what not to, does.

Demand makes this matter. According to Deep Engineering, forward deployed engineer postings were roughly 729 per cent higher in April 2026 than a year earlier on an Indeed index reported by Business Insider, though that covers one job board rather than the whole market. Rising demand brings rising applications, and a reviewer is likely to see the same retrieval demo many times. A dated record of a hard trade-off is much harder to fake.

An analysis of roughly 1,000 postings by Perspective AI found discovery skills, such as requirements discovery and stakeholder management, listed in more than 70 per cent of them. Decision records are where those skills become visible on the page.

How to become a Forward Deployed Engineer: skills, portfolio, credential

Three projects worth building

Pick projects that cover different stages of a deployment, not three variations on one chatbot. Each of these can be built on public data, synthetic data, or a real workflow for a willing small organisation with written permission.

1. A discovery and scoping pack. Take an ambiguous business problem, such as invoice triage or support-ticket routing, and interview the people who own it. Produce interview notes, a scope statement with explicit exclusions, and decision records for every scoping choice. The code can be thin here. The reasoning is the artefact.
2. A deployed system with an evaluation set. Build something that runs against realistic inputs, with an evaluation set drawn from real cases, a written account of where it failed, and a list of things the system will not do. Deploy it somewhere a stranger can reach it, not only on your laptop.
3. A hand-back pack. Take the second project and make it ownable by someone else: a runbook, monitoring, access arrangements, and a record of who ran it without you. Betts Recruiting reports that AWS’s forward deployed organisation is built around embedding engineers to deploy agents and leave customers able to run them independently. That is the behaviour to evidence.

Two projects done properly beat five half-finished ones. If time is short, merge the second and third.

How to write the decision log

Borrow the architecture decision record, a format software teams already use. Martin Fowler’s bliki describes it as a short document capturing a single decision, a couple of pages at most, with the decision, its context and its significant ramifications. It also advises listing the serious alternatives that were considered, with their pros and cons.

Not every choice deserves a record. Safeguard suggests writing one when a decision is hard to reverse, affects several teams or shapes risk, and warns that a log full of trivia will not be read. For a deployment, good candidates are what data you ingest, how you evaluate, what the system refuses, how personal data is handled, and where a human stays in the loop.

A workable template, in plain Markdown stored beside the code:

• Title, date and status (proposed, accepted, superseded).
• Context: the customer constraint that forced the choice.
• Options considered, with the reason each was rejected.
• Decision and the trade-off you accepted.
• Confidence, and what would change your mind.
• Review trigger and the person who accepted the risk.

Microsoft Learn recommends recording the confidence level of a decision, since a low-confidence call is worth flagging for later reconsideration. A candidate who writes “medium confidence, sample came from one supplier” sounds like someone who has been burned before.

Never rewrite history. Fowler advises linking an accepted record to its superseding decision rather than editing it, which leaves a clear log of how long each decision governed the work. Superseded entries are evidence that the project met reality. Safeguard also advises writing records before or during the work, not after. Retrospective logs read as retrospective.

For any record that touches who is accountable for a risk, apply the Signature Test:

Who signs the risk statement before go-live?

If the answer is “nobody”, the record has found a gap worth fixing before it reaches a reader.

Show the hand-back and the measures

Many portfolios stop at build. A deployment does not. Each project should leave traces of the stages around the build as well.

AIU teaches the deployment lifecycle in seven stages: post-sale handoff, discovery, scoping, build, deploy, iterate and hand-back.

The last stage is the one portfolios skip. Hand-back means the customer’s team owns the system: they can run it, change it and explain it. One check is the handover rehearsal:

Five tasks the client team performs while the deployment engineers observe.

Record the result in the log, including what the client team got wrong. A rehearsal that went perfectly is less believable than one that exposed a missing runbook step.

A portfolio is also easier to read when each project maps to what the job is measured on.

AIU teaches that Forward Deployed Engineers are measured on three things: deployment velocity, customer success and product feedback quality.

Dated records let a reviewer see how long you took between scoping and first deployment. A short “product feedback” note, naming what you would change in the underlying tooling, covers the third measure. The Pragmatic Engineer notes that FDEs also contribute to core products, adding features when a customer needs a missing capability. Feedback written down, with evidence, is a small version of that habit.

Packaging it so a reviewer reads it

Put each project in its own repository with a README that opens with the problem, the result and a link to the decision log. Keep the log in the repository so it goes through review like code. Link a short architecture diagram, the evaluation results and the hand-back pack. Reviewers will not click through ten pages, so make the first screen carry the argument.

Leave out anything confidential. Check your contract before reusing employer work, and use synthetic or public data when in doubt. Structured practice on all of this is where the Certified Forward Deployed Engineer (CFDE)™ comes in.

If you want a guided route through these projects, AIU explains how to start below.

Explore the CFDE Foundation programme →

Frequently asked questions