The FDE Portfolio: Shipped Artifacts and Decision Logs That Get You Hired

Most portfolios fail for one simple reason: they showcase what you built, not what the business unlocked. A Forward Deployed Engineer isn't hired to write pristine code in a vacuum. You are hired to parachute into a high-value customer account, diagnose a broken data pipeline, ship a Python script that patches a $2M contract, and document exactly why you chose a brittle regex over a 3-day ML training pipeline.

This guide breaks down the exact artifacts and decision logs that signal FDE readiness to hiring managers at Palantir, Scale AI, and similar high-stakes engineering cultures. We are optimizing for one signal: high-agency problem solving under technical ambiguity.

Why Standard Dev Portfolios Fail the FDE Bar

A typical software engineering portfolio contains a beautiful front-end, a clean REST API, and 100% test coverage. An FDE reviewer will skim this and ask: “Where is the mess?”

FDE work lives in the messy seams between systems. You aren't building greenfield apps; you are coercing a legacy SOAP API to talk to a modern gRPC service while the customer’s firewall drops 30% of packets. A portfolio that only shows a perfect, isolated environment signals that you have never fought a production fire with a bash one-liner and a prayer.

To get hired, your portfolio must demonstrate:

• Integration pragmatism: Connecting systems that were never designed to connect.
• Customer obsession: Tools built to unblock a specific human, not a generic user.
• Technical narrative: Why you chose speed over accuracy, or duct tape over elegance.

The Two-Pillar Portfolio: Artifacts and Decision Logs

We will build a portfolio with two distinct layers:

1. Shipped Artifacts: The actual code, scripts, or lightweight tools you deployed.
2. Decision Logs (Architecture Decision Records): Markdown files explaining the context, constraints, and trade-offs.

A GitHub repository with just a script is noise. A repository with a script and a DECISIONS.md file explaining that you had 4 hours to fix a data corruption issue and chose a linear scan over an index rebuild because of memory constraints? That is an FDE hire signal.

Artifact 1: The Cross-System Integration Glue

Do not build a to-do app. Build a bridge. The classic FDE artifact is a lightweight adapter that syncs data between two horrifically incompatible enterprise systems.

The Scenario: A mock customer uses Salesforce for CRM but runs fulfillment through a legacy on-premise PostgreSQL database. They need real-time order status updates, but the VPN tunnel drops hourly.

What to Build: A stateless Go or Python service that polls Salesforce for updated opportunities via SOQL, transforms the payload, and upserts into Postgres. The critical piece is the resilience layer: implement exponential backoff, a dead-letter queue (even just a SQLite table), and idempotency keys so duplicate webhooks don't double-ship orders.

The FDE Signal: This isn't just an API. It shows you understand network unreliability, exactly-once semantics, and the reality that enterprise middleware is often just a well-written Python script.

Artifact 2: The Customer-Facing Diagnostics Tool

FDEs are often the first line of defense when a customer says "your software is broken." Usually, it's their data. Build a tool that lets a non-technical user diagnose a complex system without calling you.

The Scenario: A customer uploads CSV files to an S3 bucket, which triggers a data pipeline. 20% of files fail silently.

What to Build: A local-first web app (HTML/JS only, no server needed) where a user drags a CSV onto the browser. The tool validates schema, runs regex checks on email/phone fields, and outputs a highlighted "error report" they can send to their data team. Use Web Workers to handle large files without freezing the UI.

The FDE Signal: You didn't just fix the bug; you built a self-service tool to reduce support tickets. This demonstrates the core FDE loop: See a pattern of failure, automate the diagnosis, and empower the user.

Artifact 3: The High-Stakes Migration Script

FDE interviews love "data migration under duress" stories. This artifact proves you can move fast without breaking things (permanently).

The Scenario: A database table has 50 million rows, and the status column (TEXT) needs to be split into status_code (ENUM) and status_detail (TEXT) with zero downtime on reads.

What to Build: A Python script using psycopg2 or asyncpg that performs an online schema change. Do not just run ALTER TABLE on a small database. Simulate the real thing: use batch updates in chunks of 10,000 rows, sleep between batches to avoid replication lag, and implement a dual-write strategy where the application writes to both the old and new columns during the migration window.

The Decision Log to pair with this:

Context: We needed to refactor the status column to enforce data integrity. Downtime was unacceptable per the SLA. Decision: We chose a batched backfill with dual-writes over using a trigger-based migration. Triggers would have added 15% overhead to write transactions, threatening the upcoming Black Friday peak. Consequences: The migration took 8 hours instead of 2, but write latency remained flat.

The Decision Log: Your Secret Weapon

Code tells me what you did. A Decision Log tells me how you think. This is the single highest-ROI document in your portfolio.

Create an /adr directory in your repo. For each artifact, write a short markdown file:

• Title: Short noun phrase (e.g., "ADR-001: SQLite for Dead-Letter Queue over Redis")
• Status: Proposed / Accepted / Deprecated
• Context: The problem. The customer constraint. The time pressure.
• Decision: The specific architecture or tool you chose.
• Alternatives: What you rejected (e.g., "Kafka was rejected because the customer environment doesn't support Java/JVM dependencies").

This format (inspired by Michael Nygard's Architecture Decision Records) immediately signals to a hiring manager that you operate with the rigor of a senior engineer, even when writing a "duct tape" script. It proves you aren't just hacking; you are making calculated trade-offs.

Structuring the README for an FDE Reviewer

An FDE hiring manager has 90 seconds to scan your repo. Do not bury the lede.

1. The Problem Statement (Top): "Acme Corp had a 20% data ingestion failure rate due to malformed CSVs. Support tickets took 4 hours to resolve."
2. The Impact (Metrics): "This tool reduced diagnosis time to 2 minutes and eliminated 85% of related support tickets."
3. The Architecture Diagram: A simple flow diagram (use the Reactflow JSON above as a guide).
4. Quickstart: docker-compose up must work flawlessly. If I can't run it in 2 minutes, the signal is broken.

FAQ: The FDE Portfolio

How to get into FDE role?

Transitioning into an FDE role requires demonstrating a blend of backend engineering fluency and customer-facing communication. You don't need a specific certification, but you do need a portfolio that proves you can debug production systems under pressure. If you are coming from a pure backend or frontend role, focus on building artifacts that cross system boundaries. For a deeper tactical breakdown, read our guide on How to Break Into FDE Roles from a Backend or Frontend Background.

What items should you include in your career portfolio?

Include shipped code (not tutorials), architecture decision records (ADRs), and metrics of impact. Avoid generic "full-stack" clones. Focus on integration glue, diagnostics tools, and migration scripts as described above. A great portfolio also includes a link to a technical document you wrote, proving you can communicate with executives. See our breakdown of Writing Customer-Facing Technical Docs That Actually Get Read and Used.

Is FDE a good role?

Yes, if you hate being siloed. FDE is a high-agency, high-compensation role that sits at the intersection of engineering, product, and sales. It often involves travel (20-50%) and direct ownership of revenue outcomes. The total compensation for senior FDEs can rival top-tier pure engineering roles because your impact is directly visible on the P&L. To understand the rhythm of the job, check out What a Forward Deployed Engineer Actually Does in a Week: A Diary Breakdown.

Do front-end developers need a portfolio?

Front-end developers applying for standard product roles need a design-focused portfolio. Front-end developers applying for FDE roles need to pivot. Your portfolio should not just show beautiful components; it should show a lightweight tool that solves a messy enterprise data problem (like the CSV diagnostics tool above). You need to signal that you are willing to debug a backend issue or write a SQL query, even if your primary skill is React.

How do I build a portfolio when I have a full-time job?

You don't need 10 projects. You need 2-3 high-signal artifacts. Re-purpose a script you already wrote at work (anonymizing the logic) or automate a painful manual process for a non-profit. The key is the DECISIONS.md file—that takes an hour to write and triples the perceived value of the code.