The FDE Portfolio: 5 Projects That Get You Hired, Not Just Side Projects

You are not a software engineer applying for a product role. You are a forward deployed engineer. The distinction matters because the portfolio that gets you hired at a product company will get you rejected from an FDE team.

The core misunderstanding: an FDE portfolio is not a collection of polished side projects. It is a body of evidence that you can ship working software inside a customer’s messy, broken, undocumented environment without breaking production.

This guide gives you five concrete projects to build. Each one maps to a specific, high-frequency FDE task. Each one is designed to be discussed in a 45-minute technical interview. None of them are tutorial-driven todo apps.

Why CRUD Apps Kill Your FDE Chances

The standard advice for software engineers is wrong for FDEs. A full-stack SaaS clone signals that you can follow a tutorial and manage clean state. An FDE hiring manager sees that and asks: “But have you ever ingested a 2GB malformed CSV from a mainframe export while the customer’s VP of Engineering watches you sweat?”

FDE work is defined by three constraints that side projects never simulate:

Your portfolio must demonstrate that you can operate under these constraints. You do this by showing your work, not just your final commit.

The FDE Portfolio Architecture: Signal vs. Noise

A strong FDE portfolio has three layers, and you should make each layer visible to the reviewer:

1. The Artifact: A README, a design doc, a video walkthrough. This is the story of the problem.
2. The Code: Not just the final main branch. Show the PRs where you fixed a silent encoding bug. Show the issue where you documented a customer’s weird data shape.
3. The Deployment Log: A DEPLOYMENT.md that lists the exact shell commands you ran on the customer’s bare-metal box. Include the failures.

Here is the architectural pattern that underpins the five projects below. This is the flow you are implementing in different flavors.

Project 1: The Enterprise Data Liberation Rig

The FDE Scenario: A logistics customer has 10 years of shipment data locked in PDF bills of lading. They need a searchable database by Friday.

What to Build: A pipeline that ingests a directory of scanned PDFs, extracts text and tables, and loads them into a queryable SQLite database.

Key Components:

• PDF Ingestion: Use pdfplumber for text and table extraction. Do not use a SaaS API. The customer’s data cannot leave their VPC. Show you can run extraction locally.
• Schema Inference: The PDFs have no consistent schema. Write a script that samples 100 pages, extracts all table headers, and uses a small local model (like Llama 3.2 3B) to suggest a unified SQL schema. Show the prompt you used.
• Error Handling: At least 5% of the PDFs will be scanned images. Your pipeline must detect a text extraction failure, log the file, and continue processing the rest. Do not crash the pipeline.
• Deployment Artifact: A single Dockerfile and a run.sh script that takes an input directory and an output database path.

Why This Signals FDE Readiness: This project proves you can handle the most common FDE task: liberating data from a proprietary format without breaking the customer’s security boundary. For a deeper dive on extraction patterns, see our guide on building a Receipt-to-JSON Extractor with Google Gemini 1.5 Flash Free Tier.

Project 2: The Legacy System Wrangler

The FDE Scenario: A bank has a critical internal tool that runs on Java 8 and exposes a SOAP API. They need a modern REST wrapper so a new React dashboard can query it.

What to Build: A Python FastAPI service that translates REST JSON requests into SOAP XML, calls the legacy endpoint, and transforms the XML response back to JSON.

Key Components:

• WSDL Parsing: Use zeep to dynamically read the WSDL. Do not hardcode the XML structure. Show that your adapter can survive a minor WSDL change.
• Error Translation: SOAP faults must become meaningful HTTP error codes. A soap:Server fault with a Java stack trace is useless to a frontend developer. Map it to a 502 with a structured JSON error body.
• No Internet Simulation: In your README, include a docker-compose.yml that spins up a mock SOAP server using mocksoap (or a custom Flask app) and your adapter, all inside a network with network_mode: none for the adapter container. This proves you can work in air-gapped environments.

Why This Signals FDE Readiness: FDEs spend 40% of their time building adapters. This project shows you can wrap, not rewrite, legacy systems. The air-gapped simulation is the detail that wins offers.

Project 3: The Multi-Modal Triage Agent

The FDE Scenario: A customer support team receives bug reports as screenshots, screen recordings, and text. They need a single tool that classifies the report, extracts the error message, and drafts a Jira ticket.

What to Build: A single Python script that accepts a file path (image, video, or text), routes it to the correct model, and outputs a structured JSON ticket.

Key Components:

• Input Routing: Use python-magic to detect MIME type. If it’s an image, use a vision model. If it’s a video, extract a keyframe with opencv-python and then use a vision model. If it’s text, use a text model.
• Model Selection: Use OpenRouter’s free Llama 3.2 Vision model for images, and a cheap text model like Mixtral for text classification. Show that you can swap models with a config change. The implementation pattern is similar to our Screenshot-to-Code Agent Using OpenRouter's Free Llama 3.2 Vision Model.
• Structured Output: The final output must be valid JSON matching a predefined Pydantic schema. Show the schema in your repo. Show a test case where the model hallucinates a field and your validation catches it.

Why This Signals FDE Readiness: This project demonstrates the core FDE skill of chaining models and traditional code into a single, reliable pipeline. It’s not a chatbot. It’s a tool.

Project 4: The Bare-Metal RAG Implementation

The FDE Scenario: A legal customer wants to ask questions about their internal policy documents. They cannot use OpenAI. They have a single server with no GPU.

What to Build: A Retrieval-Augmented Generation (RAG) system that runs entirely on CPU using quantized models and a local vector store.

Key Components:

• Embedding Model: Use BAAI/bge-small-en-v1.5 via sentence-transformers. It runs fast on CPU and is small enough to commit to the repo.
• Vector Store: Use Qdrant in local mode (file-based, no Docker required). Show that you can persist and reload the collection.
• LLM: Use llama.cpp with a quantized GGUF model (e.g., Llama 3.2 3B Q4_K_M). Your run.sh script should download the model from Hugging Face on first run.
• Evaluation: Include a eval.py script that runs 10 hand-written questions against the system and logs the retrieved context and the generated answer. Show the output in your repo. This is the artifact that proves it works.

For a guided walkthrough of a similar RAG architecture, see our post on building a Discord Community FAQ Bot with RAG on Qdrant Free Tier.

Why This Signals FDE Readiness: This project proves you understand the full stack, from model quantization to vector search, and that you can deploy AI where the cloud is not an option.

Project 5: The Deployment Audit Trail

The FDE Scenario: You shipped a critical fix to a customer’s production server at 2 AM. Two weeks later, the customer asks, “What exactly did you run on our box?”

What to Build: Not a standalone project, but an addition to every other project in your portfolio. A DEPLOYMENT.md and a Makefile that records every action.

Key Components:

• Makefile as Interface: Every command the customer might run is a make target: make setup, make run-pipeline, make verify-output.
• Script Logging: Every shell script logs its stdout and stderr to a timestamped file in a logs/ directory. Include a make logs target that tails the latest log.
• DEPLOYMENT.md: A document written for a tired SRE. It lists:
  • Exact OS and Python version tested.
  • Required environment variables with example values.
  • A step-by-step “first run” guide.
  • A troubleshooting section: “If you see ImportError: libopenblas.so.0, run sudo apt install libopenblas-dev.”

Why This Signals FDE Readiness: The difference between a side project and a shipped project is the operations manual. This project proves you understand that your code will be run by someone else, at 2 AM, under pressure. This is what an FDE’s week actually looks like, as detailed in What a Forward Deployed Engineer Actually Does in a Week.

How to Present This to a Hiring Manager

Do not send a link to your GitHub profile. Send a single PDF or Notion page titled “FDE Portfolio: [Your Name]”. Structure it like an internal memo:

1. Topline: 3 bullet points summarizing your FDE experience.
2. Project Deep-Dives: For each project, include:
   • The Customer Scenario: 2 sentences. Who was the imaginary customer, and what was their broken environment?
   • The Architecture Decision: Why did you choose pdfplumber over an LLM for extraction? Why did you use SQLite instead of Postgres?
   • The Hardest Bug: Show a screenshot of a terminal error, and the 3-line fix. This is the most important part.
   • Link to Code: A single link to the repo.
3. Deployment Philosophy: A short paragraph on why you include a DEPLOYMENT.md and a Makefile. This signals maturity.

FAQ: FDE Portfolio Projects

Q: Should I build these with a specific company’s stack in mind? Tailor the language and domain to the company you’re applying to. If you’re applying to Palantir, use government logistics scenarios. If you’re applying to an AI startup, use customer support triage scenarios. The core technical pattern remains the same.

Q: How long should each project take? Aim for one weekend per project. The goal is a working pipeline, not a polished application. Perfection is a liability in FDE work. Ship a working v0.1, document its flaws in the README, and move on.

Q: I don’t have enterprise customer experience. Can I still build these? Yes. The “customer scenario” in your write-up can be hypothetical, but it must be specific. “A regional bank with a COBOL mainframe” is a good scenario. “A company with some data” is not.

Q: What if my portfolio projects are all private because they were for real clients? Build public, anonymized versions of the core patterns. You can say, “This is a generalized version of a pipeline I built for a logistics customer.” The code is public; the specifics of the customer’s data are not.

Q: What’s the one skill these projects don’t test that I still need? On-site presence. FDEs travel. Your portfolio cannot prove you can sit in a windowless conference room with a frustrated customer and calmly debug a network issue. But a well-documented DEPLOYMENT.md shows you’ve thought about the person on the other side of the screen. That’s a start.

The highest-leverage skills for an FDE go beyond code. They include prompting, data prep, and rapid modeling. We cover those mental models in depth in The Highest-Leverage Skills for an FDE in the AI Era.