The FDE Portfolio: What to Build to Get Hired in 2026

The standard software engineering portfolio is a liability for a Forward Deployed Engineer role. A React todo list, a full-stack CRUD app, or a clone of a popular SaaS tells a hiring manager you can follow a tutorial. It doesn’t tell them you can walk into a chaotic, non-technical customer environment, diagnose a broken procurement workflow, and ship a Python script that saves a $2M contract before the coffee gets cold.

Forward Deployed Engineering (FDE) sits at the collision point of sales, product, and engineering. You are the tactical nuke sent into the customer’s data center (or cloud tenant) to make the product work under live fire. The portfolio’s job is not to show code quality in a vacuum; it’s to simulate a customer rescue mission.

We’ll break down a three-project portfolio that has consistently converted interviews into offers at top-tier API companies and AI labs. We’ll cover the technical architecture, the non-obvious signals, and how to present it when the hiring manager asks, “Walk me through your most complex customer problem.”

The Portfolio Trap: Why Your Side Project Is Invisible

The FDE hiring bar is schizophrenic. You need the technical chops of a backend engineer, the communication skills of a solutions architect, and the commercial instincts of an account executive. The average portfolio focuses entirely on the first pillar and ignores the other two. A generic full-stack project screams: “I want a standard SWE job, but I heard FDE pays more.”

Hiring managers at companies like Palantir, Stripe, or Anthropic scan a portfolio for three distinct signals:

1. Evidence of external constraint manipulation: Did you work with a messy, real-world external system (a legacy SOAP API, a CSV dump from a mainframe, a scraped government PDF)?
2. Non-technical impact quantification: Can you translate a technical hack into dollars saved or hours returned?
3. Narrative control: Can you explain the trade-offs without sounding like you’re reading a Jira ticket?

If your portfolio is just a clean GraphQL endpoint with a perfect CI/CD pipeline, you’ve built a beautiful race car that has never touched a gravel road. The FDE interview is all gravel.

Architecture of a High-Signal FDE Portfolio

A winning FDE portfolio is a monorepo with three distinct projects, each targeting a specific stage of the deployment lifecycle. You’re not building a product; you’re building a case study of yourself as a force multiplier.

Host everything on a single GitHub Pages site. The URL should be firstname-lastname-fde.dev. Don’t use a generic portfolio template; the site itself is a demo of your ability to ship a polished, static artifact quickly.

Project 1: The Dirty Integration (Week 1-2)

This is the anchor. It proves you can handle the 80% of the FDE job that involves wrangling terrible data.

The Scenario: Pick a public, messy dataset. Not Kaggle’s clean Titanic dataset. Go to a government open data portal, find a PDF of quarterly financials, or use a rate-limited, poorly documented API from a logistics provider. Your task is to build a reliable ETL pipeline that turns this mess into a clean analytics table.

Tech Stack: Python, DuckDB (for in-process analytics), Docker, and a GitHub Action.

The Build:

1. Ingestion: Write a script that downloads a PDF, extracts tables using camelot-py or tabula-py, and handles the inevitable formatting errors. If you’re using an API, implement exponential backoff and retry logic for 429 errors. Comment your code explicitly: “The API docs say the field is timestamp, but in production it’s sometimes Timestamp with a capital T. This block normalizes the casing.”
2. Transformation: Don’t just clean the data; enrich it. If you have a list of addresses, geocode them. If you have company names, fuzzy-match them against a public SEC dataset. This shows you go beyond the minimum viable script.
3. Serving: Write the output to a data.parquet file and use a single app.py Streamlit script to visualize the “before” and “after.” The visualization doesn’t need to be fancy. It needs to show a raw PDF next to a sorted, filterable table of the extracted data.

The README Hook: Don’t title it “PDF Parser.” Title it “Automated Fiscal Reconciliation for [Government Agency].” The README must contain a “Business Impact” section: “Manual extraction of this quarterly report took analysts 4 hours. This pipeline runs in 3 minutes on a schedule, reducing error rate by 90% and saving an estimated $15K annually in labor.”

This project directly counters the “you’ve never worked with real customer data” objection.

Project 2: The ‘Zero-to-One’ Dashboard (Week 3-4)

FDEs are often dropped into a customer’s office (or Zoom room) with a vague request: “Can you build us a dashboard to track our fleet?” This project demonstrates you can build a functional UI under extreme time pressure and scope ambiguity, which is a core skill outlined in any realistic Forward Deployed Engineer roadmap.

The Scenario: Use the clean data from Project 1, or pick a live public API (like a weather service or transit feed). You are building an operational dashboard for a fictional logistics manager. The constraint: you must build it using a low-code or AI-assisted framework to simulate the speed required in the field.

Tech Stack: Streamlit or Gradio (Python), or Next.js with shadcn/ui and V0.dev for rapid component generation. The key is not raw code volume; it’s the speed of iteration.

The Build:

• Role-Based Access: Simulate a login screen that doesn’t just check a password but shows a different view for a “Driver” vs. a “Fleet Manager.” This doesn’t require a real auth backend; a dropdown selector that toggles state is sufficient. It shows you think about user personas.
• Real-time Simulation: Add a component that simulates a live feed. Use an asyncio loop in Python or a setInterval in JavaScript to push fake GPS coordinates onto a map. When the hiring manager clicks “Play,” the dashboard should look alive.
• The “Break Glass” Feature: Every FDE dashboard needs an emergency action button. Add a large red button that says “Reroute All Vehicles” or “Trigger Safety Alert.” When clicked, it should fire a webhook to a service like webhook.site and log the action. In the README, explain: “In a production scenario, this webhook integrates with the customer’s legacy on-prem dispatch system via a bespoke adapter.”

The README Hook: Title it “Real-Time Fleet Intervention Console.” Include a 90-second silent screen recording (use OBS) of the dashboard reacting to the simulation. A video thumbnail in the README increases click-through by an order of magnitude. State clearly: “Prototype built in 4 days to align stakeholders on a critical safety feature.”

Project 3: The Value Engineering Model (Week 5-6)

This is the project that separates FDE candidates from the pack. You must prove you understand why the code matters. This project is a financial model, not a traditional software artifact. It’s a direct nod to the commercial reality of the Forward Deployed Engineer salary band—you are paid to retain and expand revenue.

The Scenario: Build a Total Addressable Market (TAM) or Return on Investment (ROI) calculator for the fictional product you “deployed” in Projects 1 and 2. Use Excel or Google Sheets, but embed it in your portfolio site via an iframe.

The Build:

1. Input Assumptions: Create clearly named input cells (e.g., Number_of_Vehicles, Avg_Fuel_Cost_per_Gallon, Current_Idle_Time_Percentage). Use data validation to restrict inputs to realistic ranges.
2. The Logic Chain: Map the technical features of your dashboard to financial outcomes. Example: “Real-time rerouting reduces idle time by 15%. 15% idle reduction saves $Y per vehicle per year. Across a fleet of X vehicles, this equals $Z total savings.”
3. Sensitivity Analysis: Add a simple table showing how the ROI changes if idle time reduction is only 5% vs. 25%. This demonstrates you don’t just sell the best-case scenario; you understand risk and variance.
4. Integration: Write a Python script that reads the Excel file, runs the calculation headlessly, and outputs a JSON object. This simulates plugging the model into an automated customer health scoring system.

The README Hook: Title it “LogiCore ROI Model: From Idle Time to EBITDA Impact.” Write a “Customer Narrative” section: “Presented this model to the VP of Operations at a mid-market logistics firm. The model translated a technical integration (real-time GPS) into a projected $2.1M annual savings figure, securing the expansion deal.”

Packaging: The README That Reads the Room

Your portfolio’s landing page is a README.md. Do not use dense paragraphs. Use a structure that mirrors an internal memo to an executive:

• Headline: “Forward Deployed Engineer | Turning messy data and tight deadlines into customer revenue.”
• Project Matrix: A 3-column layout (Project, Business Problem, Technical Solution, Impact).
• “Live Fire” Log: A short markdown table listing 2-3 complex bugs you solved during the projects and how you debugged them. This is pure gold for an engineering manager who wants to see your scrappiness.

Deploy the site on Cloudflare Pages. It’s free, fast, and shows you know modern infrastructure.

The Portfolio Defense: Interview Walkthrough

When the interviewer asks about the portfolio, they are not asking for a technical deep dive on your first pass. They are testing your executive presence. Use the following narrative structure for each project:

1. Context (The Customer): “Imagine a logistics company with 500 trucks. They have no central data team.”
2. Conflict (The Mess): “Their dispatch data was trapped in a 1990s terminal emulator. We had to screen-scrape it.”
3. Resolution (The Hack): “I built a Python adapter that emulated keystrokes and parsed the buffer. It was ugly, but it unlocked the data in 2 days.”
4. Value (The Money): “This unblocked a $1M analytics contract.”

If you deliver this narrative calmly, you’ve passed the “customer-facing” bar. The technical bar is passed by having the code clean, commented, and functional in the repository. For more on this narrative style, study the Forward Deployed Engineer interview process.

FAQ: FDE Portfolios

Should I include collaborative projects?

Only if you can clearly delineate what you built. FDEs often work solo on customer sites. A solo project showing end-to-end ownership is more valuable than a group project where you “led the backend.”

Is a GitHub profile enough, or do I need a custom domain?

A custom domain costs $12/year and signals a minimal level of product polish. Buy firstname-lastname.dev. It’s an implicit signal that you understand the importance of a branded user experience.

What if I don’t have access to real customer data?

Public government data is your best friend. The messier the PDF, the better. The key is not the data itself, but the transformation logic and the business story you wrap around it. No one expects you to have proprietary Stripe data.

How much AI should I use in the portfolio?

Use it aggressively for boilerplate (CSS, chart configurations, docstrings). Never use it for the core integration logic. If you can’t explain the retry logic in the API adapter during the interview, the portfolio did you more harm than good. The role often involves debugging AI-generated code from customers; you need to show you are better than the bot.

Do I need to show full-stack mobile skills?

No. FDE is heavily backend and data-focused. A responsive web dashboard is sufficient. Mobile is a nice-to-have, but only if it naturally fits the customer scenario (e.g., a driver’s app). Don’t force it.

How do I host this for free?

Use GitHub for the repo, Streamlit Cloud for the Python dashboards, and Cloudflare Pages for the static site. Total cost: $0 (plus the optional domain). This is also a subtle demonstration of your ability to scope a lean, production-grade architecture without over-engineering.