Forward Deployed Engineer Projects: 7 Portfolio Ideas to Land the Role

Why Generic Portfolios Fail the FDE Bar

A standard software engineering portfolio showcases depth: a beautifully architected microservice, a complex state management system, or a greenfield app built over months. A Forward Deployed Engineer (FDE) portfolio must showcase breadth under velocity and constraint.

Hiring managers at Palantir, Scale AI, and similar high-growth defense/enterprise tech companies aren't looking for a pristine codebase. They are looking for evidence that you can parachute into a messy customer environment, understand a non-software problem (logistics, insurance underwriting, satellite imagery), and ship a working prototype before the week ends.

The top-ranking pages for "forward deployed engineer projects" often point to abstract roadmaps or generic "learn Python" advice. This guide cuts through the noise. We will define the exact technical archetypes that prove FDE readiness, provide concrete project specs, and show you how to architect the narrative.

The FDE Project Heuristic: Prototype, Not Product

Before we list the projects, internalize the heuristic. An FDE project is not a startup MVP. It is a high-leverage integration. It must demonstrate:

1. Data Ingress: Ingesting messy, real-world data (PDFs, screenshots, CSVs with bad encoding, or raw HTML).
2. Intelligence Augmentation: Applying an LLM or ML model not as a black-box API call, but as a reasoning step in a deterministic pipeline.
3. Constraint Awareness: Handling rate limits, cost control, or running in isolated environments (like customer VPCs).
4. Observability: Logging the why, not just the what.

Below are seven project archetypes that check these boxes. We provide the stack, the narrative, and the "FDE twist" that separates a toy from a signal.

Project 1: The Customer-Facing RAG Debugger

Retrieval-Augmented Generation (RAG) is the "Hello World" of enterprise AI in 2025. Most candidates build a simple "chat with PDF" app. That won't cut it.

The FDE Twist: Build a RAG system where the primary user is not the person asking the question, but the solutions engineer debugging the retrieval.

Spec:

• Ingest: A complex technical manual (e.g., a 500-page AWS service guide).
• Pipeline: Chunking, embedding with text-embedding-3-small, and storage in a vector DB.
• The Killer Feature: A debug UI that shows the exact chunk retrieved, the similarity score, and a diff between the user query and the retrieved text. Add a "re-rank" button that uses a cross-encoder to fix bad retrieval on the fly.
• Stack: FastAPI, ChromaDB (or Qdrant Free Tier), and a minimal vanilla JS frontend.

Why this wins: It proves you understand that FDE work is 80% plumbing and 20% modeling. You are building a tool to solve a customer's implementation friction. For a deep dive into building this exact architecture on a free tier, see our guide on Build a Discord Community FAQ Bot with RAG on Qdrant Free Tier.

Project 2: The Unstructured Data ETL Pipeline

Enterprise customers don't hand you clean JSON. They hand you a zip file containing 15 years of scanned invoices, crumpled receipts, and screenshots of spreadsheets.

The FDE Twist: Build a pipeline that turns images into structured JSON, but with a strict schema enforcement layer.

Spec:

• Input: A directory of receipt images.
• Process: Use a Vision Language Model (like Gemini 1.5 Flash or GPT-4o) to extract line items, totals, and vendor names.
• The Killer Feature: A Pydantic validation layer that catches hallucinations. If the LLM returns a total that doesn't match the sum of line items, flag it, log the raw image, and retry with a more constrained prompt.
• Stack: Python, Pydantic, and a free-tier Vision LLM API.

Why this wins: It shows you don't trust the model blindly. You treat LLMs as a brittle component in a deterministic system. You can see a production-grade version of this concept in our Build a Receipt-to-JSON Extractor with Google Gemini 1.5 Flash Free Tier walkthrough.

Project 3: The Multi-Tenant LLM Safety Guard

FDEs often deploy the same core logic across wildly different customers (a bank and a hospital). Data isolation and prompt injection are critical.

The FDE Twist: Build an API gateway that sits in front of an LLM and enforces per-customer content safety policies without mixing data.

Spec:

• Gateway: Accept requests with a tenant_id header.
• Logic: Route to tenant-specific system prompts stored in a secure vault (even a simple JSON file works for a demo).
• The Killer Feature: A regex and LLM-based firewall that detects prompt injection ("Ignore previous instructions") and sanitizes PII (names, SSNs) before the request hits the model and after the response comes back.
• Demonstrate: Show a video of a prompt injection attack succeeding against the raw model, but being blocked by your gateway.

Project 4: The Browser-Based Automation Agent

Many customer environments are air-gapped or SaaS-walled gardens with no API. The only interface is the DOM.

The FDE Twist: Build an agent that navigates a website to extract data, but runs entirely inside a sandboxed browser environment.

Spec:

• Task: Log into a public demo site (e.g., a demo e-commerce store) and scrape order data from the dashboard.
• Architecture: Use Playwright steered by an LLM that outputs structured DOM actions (click, type).
• The Killer Feature: Run it in a V8 isolate or a minimal Docker container with no external network access except to the target site. Prove you can operate in a security-constrained customer VPC.
• Stack: Playwright, an LLM with tool-calling (like Llama 3.2 Vision via OpenRouter), and a strict sandbox.

For a deep dive on this agentic pattern using vision models, read our guide on Build a Screenshot-to-Code Agent Using OpenRouter's Free Llama 3.2 Vision Model. The browser automation paradigm is also explored in our technical analysis of Cloudflare's Kitesurf, which runs agent-first browsers inside V8 isolates.

Project 5: The Real-Time Drift Monitor

Models rot. Customer data shifts. An FDE doesn't just deploy a model; they deploy a health-check system.

The FDE Twist: Build a system that simulates a production model and detects data drift live.

Spec:

• Model: A simple scikit-learn classifier deployed as a FastAPI endpoint.
• Data Stream: A script that sends feature vectors; slowly change the distribution over time to simulate drift.
• The Killer Feature: A real-time dashboard that plots the KS-statistic or PSI (Population Stability Index) and triggers a webhook (Slack alert) when drift exceeds a threshold.
• Stack: FastAPI, scikit-learn, Alibi Detect (or manual PSI calculation), and a simple websocket frontend.

Project 6: The Screenshot-to-Code MVP

This is a classic FDE demo. A customer draws a wireframe on a whiteboard, and they want a functional React component by the end of the meeting.

The FDE Twist: Don't just generate the code; generate a self-correcting code pipeline.

Spec:

• Input: A screenshot of a UI mockup.
• Step 1: Vision model generates HTML/Tailwind.
• Step 2: Render it in a headless browser.
• Step 3: Take a screenshot of the rendered output.
• Step 4: Use a vision model to compare the original screenshot to the rendered screenshot and iteratively fix layout bugs.
• Stack: Playwright, OpenRouter (for free Llama 3.2 Vision), and a simple control loop.

This project directly demonstrates the "shipping cadence" we discuss in What a Forward Deployed Engineer Actually Does in a Week. It's not about perfect code; it's about closing the gap between intent and output rapidly.

Project 7: The "Zero-Training" Document Classifier

Customers often have 10,000 documents and no labels. They can't wait for a fine-tuning job.

The FDE Twist: Build a few-shot classifier that uses an LLM to generate synthetic training data, then trains a tiny, fast model on that data.

Spec:

• Input: A directory of unlabeled contracts.
• Step 1: Use an LLM to generate 50 diverse examples of "contract types" (NDA, MSA, SOW) based on the document metadata or a quick skim.
• Step 2: Embed these synthetic examples.
• Step 3: Classify the real documents using cosine similarity against the synthetic centroids.
• The Killer Feature: An active learning loop where the user can correct 5 misclassifications in a UI, and the centroids update instantly without re-training.

Architecting the Narrative: The README That Gets You Hired

The code is only 50% of the project. The other 50% is the narrative wrapper. Every repo should follow a strict FDE-focused README template:

1. The Customer Scenario (1 paragraph): "Acme Corp has 50k unlabeled invoices and no data science team. They need a triage system by Friday."
2. The Constraint (1 paragraph): "They run on-prem with no internet access. The solution must use an air-gapped LLM or pure Python."
3. The Architecture Decision Record (ADR): A table explaining why you chose the tech stack.

1. The "Time to Ship": State how long the prototype took (e.g., "Built in 6 hours").
2. The "Next Steps" Pivot: Don't pretend it's production-ready. Write the exact next steps you'd take if this were a real engagement (e.g., "Week 2: Implement Auth, Week 3: Scale to 1M documents").

FAQ: Forward Deployed Engineer Projects

What makes an FDE project different from a standard SWE project?

An SWE project optimizes for scalability and elegance. An FDE project optimizes for speed of utility in a foreign environment. It must demonstrate integration with messy data, handling of constraints (rate limits, air-gap), and a focus on the "last mile" of user delivery.

Should I include AI/LLM projects even if the role doesn't explicitly mention it?

Yes. In 2025, an FDE who can't wield an LLM for rapid prototyping is like a carpenter without a hammer. The highest-leverage skills now involve prompting, data prep, and rapid modeling. We cover this shift in detail in The Highest-Leverage Skills for an FDE in the AI Era.

How many projects should my portfolio have?

Three high-quality, deeply documented projects are infinitely better than ten half-baked ones. Aim for a mix: one RAG/information retrieval project, one computer vision/automation project, and one data engineering/ETL project.

Do I need to deploy these projects to the cloud?

Not necessarily. An FDE often works in air-gapped environments. A project that runs 100% locally via Docker Compose, with clear documentation on how to boot it up offline, is a massive green flag. It shows you understand enterprise reality.

Should I build these projects from scratch or fork existing repos?

Build from scratch. The messy commit history is a feature, not a bug. An interviewer wants to see your problem-solving process: the failed attempts at parsing the PDF, the prompt engineering iterations, the moment you realized you needed a re-ranker. This is the "customer shipping cadence" in action.