The FDE Portfolio: What to Build to Land a Forward Deployed Engineer Job

Most engineering portfolios are optimized for product companies. They show beautiful front-ends, clean CRUD apps, and isolated microservices. A Forward Deployed Engineer (FDE) role is none of these things. It is a role defined by high-variance environments: air-gapped networks, broken APIs, ambiguous customer data, and timelines measured in hours, not sprints.

If your portfolio looks like a bootcamp capstone, you’ve already lost the plot. Hiring managers for FDE roles at Palantir, Scale AI, or high-growth defense tech startups aren't looking for "full-stack engineers." They are looking for evidence of technical rigor under operational friction.

This guide breaks down exactly what to build to signal you can survive the chaos.

Why Standard Portfolios Fail the FDE Bar

A standard portfolio often contains:

• A React front-end with a Firebase backend.
• A REST API that serves predictable data.
• Unit tests with 100% coverage on a greenfield project.

These artifacts prove you can code in a vacuum. They do not prove you can deploy an LLM feature inside a customer’s on-premise Kubernetes cluster that has no internet access. They don't prove you can reverse-engineer a legacy SOAP API to pull critical logistics data into a modern dashboard by Tuesday morning.

FDE work is "integration-heavy engineering." Your portfolio must mirror the messy, third-party-dependent reality of the job.

The FDE Portfolio Trinity: Rigor, Scrappiness, and Business Impact

Before writing a single line of code, understand the three signals you must send:

1. Technical Rigor: Can you handle low-level protocols, streaming data, or on-device inference without a wrapper library doing the work for you?
2. Scrappiness: Can you ship a working prototype using a bash script, a cron job, and a free-tier LLM API in an afternoon?
3. Business Impact: Do you understand why you built it? Can you quantify the hours saved or revenue unlocked?

A "todo app" fails all three. A "daily standup bot that collects updates and posts a summary to Slack" passes all three.

Artifact 1: The Integration Bridge (Prove You Can Glue Enterprise Chaos)

Enterprise customers run on ancient systems. Your ability to bridge modern AI with legacy infrastructure is your highest-leverage skill.

The Build: The "CSV to Personalized Email" Bridge Don't build a generic email sender. Build a system that takes a raw, messy CSV export from a fictional CRM (HubSpot/Salesforce) and runs an LLM-powered personalization pipeline over it before sending.

Why this works:

• Parsing Hell: You aren't assuming clean JSON. You handle malformed CSV columns, missing names, and duplicate entries at the edge (Cloudflare Workers).
• Cost Awareness: You use a fast, cheap LLM (Groq) to keep inference costs near zero, proving you understand unit economics.
• Observability: You log every generated email to SQLite, allowing for a "recall" or debugging mechanism—critical when a customer says "the AI hallucinated a name."

We have a full walkthrough of this exact architecture. You can build it for free this weekend: Build an Email Cold-Outreach Personalizer from a CSV Using Groq and Cloudflare Workers.

Artifact 2: The Workflow Accelerator (Prove You Automate the Boring)

FDEs are force multipliers. You don't just write code; you replace manual operational overhead with software. The best portfolio piece here is an internal tool that saves a specific persona (e.g., an SRE, an Account Executive) 5+ hours a week.

The Build: The "On-Call Incident Summarizer" Simulate an on-call nightmare: a folder of unstructured log files and a 15-minute voice note from a panicked engineer. Your system ingests both, uses a speech-to-text model (Whisper), and a reasoning model (Gemini), and outputs a structured root-cause analysis.

Key Technical Decisions to Highlight:

• Multi-Modal Ingestion: You aren't just handling text. You are chunking audio and images (screenshots of dashboards) alongside raw logs.
• Structured Output: You force the LLM to output JSON with fields like severity_level, affected_services, and suggested_fix. This proves you think in APIs, not just prose.
• Edge Computing: If you can run the Whisper inference locally on a Mac, you demonstrate understanding of air-gapped environments where data cannot leave the machine. See our deep-dive on GPU Passthrough on macOS VMs: Accelerating llama.cpp Inference on Apple Silicon.

Why this beats a "ChatGPT Wrapper": A generic chat interface is a toy. A constrained input/structured output pipeline that solves a specific operational pain point is an FDE asset. Check out the full incident summarizer build here: Build an On-Call Incident Summarizer from Logs and Voice Notes with Whisper + Gemini.

Artifact 3: The Technical Deep-Dive (Prove You Don't Break Under the Hood)

Product engineers can often rely on managed services. FDEs often walk into environments where managed services are banned (air-gap) or too slow. You need one artifact that shows you can go low-level.

The Build: The "Codebase RAG Bot" with Local Inference Build a Q&A bot that answers questions about a large open-source codebase (like the Linux kernel or TensorFlow). The catch: it must run entirely locally, with no external API calls.

The Architecture:

Why this works:

• Quantization: You explicitly mention using 4-bit quantized models (GGUF format) to run on a laptop. This signals you understand resource constraints.
• Chunking Strategy: You don't just chunk by character count; you chunk by function/class using AST parsing. This shows software engineering maturity.
• RAG vs Fine-tuning: You explain why RAG is the correct pattern here (dynamic data, no training costs) versus fine-tuning.

You can build this entire system for free. We have a guide that uses Gemini’s local-capable patterns and LlamaIndex: Build a Codebase Q&A Bot with Gemini RAG and LlamaIndex for Free.

Structuring Your Narrative: The README That Gets You Hired

Code without context is invisible. For each artifact, your GitHub README must answer the "FDE Triad":

1. The Scenario (The "Why"): "A sales team of 15 spends 3 hours daily researching prospects. This tool cuts that to 5 minutes."
2. The Constraint (The "How"): "The customer CRM exports non-standard UTF-8 CSV files. We built a fault-tolerant parser that handles 12 edge cases."
3. The Impact (The "So What"): "Reduced time-to-first-contact by 90%. Estimated cost saving: $4,500/month based on average AE salary."

What to Avoid in the README:

• "Clone the repo and run npm start" without mentioning environment variables or API keys. FDEs expect broken environments.
• Generic descriptions. Never say "It uses AI." Say "It uses a zero-shot classification model to route the intent."
• Ignoring errors. Explicitly document what breaks. "If the CSV has a blank row, the worker will log an error to the console and skip the row." This honesty builds trust.

FAQ: FDE Portfolio Mistakes and Must-Haves

What are common portfolio mistakes to avoid?

The biggest mistake is building isolated, greenfield projects. Avoid:

• "Portfolio Websites" as the main artifact: Unless your website does something operationally complex (like a WebSocket-based live debugger), it’s just a static brochure. Focus on the repos.
• Ignoring the "Deployed" part: An FDE portfolio project running only on localhost is incomplete. Deploy it to a free tier (Cloudflare Workers, Fly.io, Hugging Face Spaces).
• Perfectionism: A messy, working script that solves a real problem is infinitely better than a pristine, unused template.

What do employers want to see in a portfolio?

They want to see you handle adversity. They look for:

• Error handling: What happens when the API is down? Do you have retry logic with exponential backoff?
• Data transformation: Did you reshape messy input into clean output?
• Technical writing: Can you explain a complex system clearly? Your README is often more important than the code.

What should a portfolio look like when applying for an FDE job?

It shouldn't look "designed." It should look like a collection of operational tools. A GitHub profile with 3-4 pinned repos, each with a dense README, a diagram.png (or Mermaid chart), and a LICENSE file. Skip the fancy personal branding site.

What are three things a portfolio should have?

1. A data-integration project that ingests messy data (CSV, logs, audio) and outputs structured value.
2. An automation script that replaces a manual workflow with a scheduled job.
3. A low-level optimization or local inference project proving you understand compute constraints.

How do I align my portfolio with FDE compensation expectations?

FDE roles often command a premium over standard SWE roles because of the travel and customer-facing chaos tolerance. If your portfolio demonstrates high business impact (dollar savings, time savings), you strengthen your case for the top of the band. Read more on this in our FDE Compensation Bands and How to Negotiate Your Offer in 2025.

I don’t know where to start. What is the fastest path?

Start with the Workflow Accelerator. Pick a manual process in your current life (sending weekly updates, summarizing emails) and automate it with a free LLM API. Ship it in one day. The speed of execution is itself the signal.