The FDE Portfolio: What to Build to Get Hired and Stand Out from the Stack

Most engineering portfolios are designed to answer a single question: "Can you write clean code in a vacuum?"

Forward Deployed Engineering (FDE) asks a fundamentally different question: "Can you write messy, high-impact code in a conference room while a customer’s production database is on fire?"

If your portfolio is a collection of isolated React apps and LeetCode solutions, you are optimizing for a standard SWE loop. An FDE hiring manager (often a CTO or Head of Engineering at a high-growth startup, or a lead at Palantir/Scale AI) is scanning for something else entirely: technical empathy, scrappiness, and the ability to ship under constraint.

This guide breaks down the exact projects you need to build to prove you aren't just a builder—you're a deployer. We’ll move past the "To-Do List" apps and into the messy, high-signal work that mirrors the day-to-day of a forward deployed engineer academy graduate.

Why a CRUD App Won't Get You an FDE Offer

Standard SWE portfolios demonstrate mastery of tools. FDE portfolios must demonstrate mastery of entropy. When you embed with a customer, you aren't handed a clean Jira ticket. You're handed an SFTP server, a legacy SOAP API, and a vague request to "make the dashboard faster."

Your portfolio needs to scream: "I can turn undocumented chaos into a structured, shipped solution without needing a product manager to hold my hand."

To do this, you must stop building isolated features and start building connective tissue. FDE work is the "last mile" of software. It’s the unglamorous Python script that saves a $2M contract. Your portfolio must reflect that.

The 4 Pillars of an FDE Portfolio

To stand out from the stack of generic applicants, your GitHub needs to hit four specific vectors. If a project hits at least two of these, it's portfolio-worthy. If it hits all four, you’re a top-tier candidate.

Project 1: The Reverse ETL & Data Unblocker

The most common FDE task is liberating data from a system that doesn't want to give it up. This project proves you can bridge the gap between a customer’s legacy operational stack and their modern analytics ambitions.

The Scenario: A customer uses an industry-specific ERP system from 2005. It only exports data via email attachments (CSV) or an insecure FTP drop.

What to Build:

• A stateless Go or Python service that polls an FTP server for new files.
• A parser that sanitizes messy CSV headers (spaces, special chars) and infers schema.
• A "Reverse ETL" pipeline that upserts the cleaned data into a modern sink (Postgres or SQLite).
• A simple CLI dashboard showing sync status, row counts, and validation errors.

Key FDE Signals:

• Fault Tolerance: What happens if the FTP server goes down mid-transfer? You need checkpointing, not just a try/catch.
• Schema Evolution: Show that your code doesn't crash if the customer adds a new column to their CSV dump without telling you.

Tech Stack: Python (pandas, paramiko), SQLite, Docker.

Project 2: The On-Prem / Air-Gapped RAG Bot

While everyone else is building ChatGPT wrappers, you need to build something that works where OpenAI’s API is blocked. Many high-value FDE engagements (defense, finance, healthcare) happen in air-gapped environments. If you can demonstrate RAG (Retrieval-Augmented Generation) running entirely locally, you prove you understand the physics of deployment, not just the API.

The Scenario: A customer wants an internal FAQ bot for their 10,000-page operations manual, but the data cannot leave the building.

What to Build:

• A local vector store using Qdrant or Chroma.
• An ingestion script that chunks PDFs and creates embeddings using a local model (e.g., all-MiniLM-L6-v2).
• A local LLM inference server (Ollama with Llama 3 or Mistral) for the chat interface.
• A Streamlit or Gradio UI for the "customer" to query.

Key FDE Signals:

• Hardware Constraints: Document the performance difference on a CPU-only machine vs. GPU. An FDE knows how to set realistic expectations for latency.
• Fallback Logic: Show what happens when the vector search returns low confidence results. Does it hallucinate, or does it politely say "I don't know"? This business logic is the difference between a prototype and a trusted tool.

For a deeper dive into this architecture, review our guide on how to Build a Discord Community FAQ Bot Backed by Your Docs with RAG and Qdrant.

Project 3: The High-Stakes Workflow Automation

This project is about removing humans from the critical path of a dangerous manual process. It’s the "if this script fails, we lose money" project.

The Scenario: A customer manually reconciles transactions at the end of the day. They compare a PDF report from a vendor against an internal SQL query. It takes an analyst 2 hours and is prone to copy-paste errors.

What to Build:

• A script that reads a PDF (using pymupdf or camelot for tables).
• A connector to the local SQL database.
• A reconciliation engine that flags mismatches.
• An automated email/Slack summary (using a webhook) that says "All clear" or "Discrepancy found: Row 45."

Key FDE Signals:

• Idempotency: The script must be safe to run twice. If the network blips and the script re-runs, it shouldn’t send duplicate emails or double-post data.
• Human-Centric Output: The output shouldn't be a JSON dump. It should be a formatted Markdown email that a finance manager can understand immediately.

Project 4: The Live Debugging & Observability Dashboard

FDEs are often the "first responders" to production bugs that standard support can't solve. You need a project that shows you can instrument a black box.

The Scenario: A customer complains that your integration is "slow." You have no access to their monitoring tools.

What to Build:

• A FastAPI middleware that logs request duration, payload size, and status codes.
• A lightweight background thread that calculates moving averages of latency.
• A real-time HTML dashboard (served from the same process) that shows a live histogram of response times without needing Grafana or Datadog.

Key FDE Signals:

• Zero-Dependency Debugging: The ability to ship a "sidecar" diagnostic tool that requires no installation. This is pure FDE utility.
• Bottleneck Identification: Show that you can distinguish between "the database is slow" and "the network is saturated" using basic metrics.

The 'Glue' Repo: Your Engineering Scrapbook

Not everything needs to be a full-stack app. Create a single repository called fde-utils or field-manual. This is where you stash the small, sharp tools that show technical depth.

What to include:

• A recursive JSON diff script: For comparing massive API responses in customer environments.
• A bulk data anonymizer: A script that scrubs PII from a SQL dump before you take it home for debugging. This shows you understand data security compliance.
• A jq-like CLI tool written in Go for parsing a proprietary log format.

This repo proves you don't just use tools; you fabricate them on the fly to solve specific, annoying problems.

Presenting Your Portfolio in the FDE Interview

When you land the interview for a top-tier forward deployed engineer academy role, don't just demo the happy path.

1. Start with the "Why": "I built this because a logistics company I advised had a 48-hour latency gap between their warehouse scanner and their ERP..."
2. Show the Failure Modes: Break the project intentionally. Kill the database. Corrupt the CSV. Show the interviewer the alert that fires. This demonstrates you design for the real world.
3. Discuss the Tradeoffs: "I chose SQLite over Postgres here to keep the on-prem install footprint under 50MB, sacrificing concurrent write speed for portability."

If you want to understand the broader context of how these skills apply to the role, compare the scope against adjacent roles in our breakdown of FDE vs Solutions Engineer vs Sales Engineer.

Frequently Asked Questions

Q: Do I need to be a full-stack expert to build these FDE projects? No. You need to be a "stack-agnostic" problem solver. FDE work often favors backend breadth (databases, scripting, networking) over frontend pixel-pushing. Knowing enough React to build a simple dashboard is useful, but deep Python/Go knowledge is more critical.

Q: How do I demonstrate these projects if they require "customer data"? Generate realistic synthetic data. Use faker in Python to create a 10,000-row CSV that looks like real healthcare or finance data. This actually adds to the signal—it shows you can simulate a customer environment to test edge cases before you deploy.

Q: Is a certification better than a portfolio for an FDE role? A certification validates knowledge. A portfolio validates execution. In the FDE interview process, execution is the only currency that matters. If you are looking for structured learning, ensure it is project-based. Focus on programs that force you to ship, not just watch videos.

Q: Should I host these projects on a live URL? Yes, but with a caveat. Hosting the "Reverse ETL" or "RAG Bot" on a cheap VPS is great. However, also have a 60-second video in your README showing the project running entirely locally (localhost). This proves you can handle air-gapped demos, which is a massive differentiator.

Q: How do I handle the "travel" aspect in my portfolio? You can't show travel in a repo, but you can show asynchronous collaboration. Include screenshots of Slack threads or Loom video links in your README where you explain the architecture to a hypothetical non-technical customer. This demonstrates the communication aspect of the Palantir-style FDE playbook.