The FDE Portfolio: Shipped Artifacts and Decision Logs That Get You Hired

Most engineering portfolios fail the Forward Deployed Engineer (FDE) bar before a hiring manager even looks at the code. They fail because they showcase what you built, not why it was hard, what broke, and how you recovered. An FDE is hired for signal processing in high-noise environments—technical skill under customer constraints, with imperfect data, and tight deadlines. Your portfolio must prove that.

This playbook breaks down the five shipped artifacts and the decision-log narrative structure that consistently get candidates hired at top FDE practices. No toy apps. No generic CRUD. Just concrete, high-signal evidence.

Why Toy Apps Fail the FDE Bar

A standard software engineering portfolio demonstrates competence. An FDE portfolio demonstrates deployment velocity and operational judgment. The difference is stark:

Hiring managers at companies with FDE practices are screening for one thing: Can this person land in a customer environment and unblock a critical workflow with incomplete information? Your portfolio is the evidence packet for that exact question.

The FDE Portfolio Architecture

A winning FDE portfolio is not a grid of project cards. It is a curated case study document—often a personal site or a dense GitHub README—that pairs shipped artifacts with decision logs. The artifacts prove you can build. The logs prove you can think.

Here is the architecture that works:

Each artifact answers a specific FDE competency question. Let’s build them.

Artifact 1: The Integration Bridge

Competency proven: Can you glue together systems that were never designed to talk?

The FDE’s core technical motion is integration. You are dropped into a customer’s stack—often legacy, often undocumented—and asked to pipe data into your company’s platform. Your portfolio must show you doing this for real.

What to build: A working bridge between two live, production systems. The messier the better. Examples that have landed offers:

• A Cloudflare Worker that polls a customer’s on-prem SFTP server, parses fixed-width flat files, and pushes normalized JSON to a webhook.
• A Python script that scrapes a supplier’s status page (no API), diffs the HTML for changes, and posts alerts to a Slack channel.
• An n8n workflow that ingests RSS feeds, runs them through an LLM for categorization, and writes to a Supabase table. See the AI Cron Newsletter Agent guide for a concrete implementation pattern.

The decision log entry: Document the three ugliest things about the integration. What broke? Did the SFTP server have a self-signed certificate? Did the flat file schema drift silently? How did you detect and recover? This log is more important than the code.

Artifact 2: The Operational Decision Log

Competency proven: Can you reason about trade-offs under uncertainty and communicate them?

This is the single highest-signal artifact in any FDE portfolio. It is a written document—Markdown, Notion, or a blog post—that walks through a real technical decision you made. Not a hypothetical. A real one, with real consequences.

Structure of a high-signal decision log:

1. Context: The customer problem, the deadline, the constraint (budget, data access, regulatory).
2. Options considered: At least three, with honest pros/cons. One option should be the “obvious” choice you rejected, and you must explain why.
3. The decision: What you chose and why the trade-off was acceptable.
4. The outcome: What happened. Did it work? What would you do differently?

Example excerpt from a real FDE hire’s log:

“The customer needed a sentiment dashboard on 50k reviews by Friday. Option A: fine-tune a BERT model (accurate, but 3 days of labeling). Option B: zero-shot GPT-4o (fast, but $0.03/review = $1,500). Option C: Gemini Flash with a structured prompt and a Supabase cache layer (fast, $0.0001/review, but lower accuracy on sarcasm). Chose C. Shipped Thursday. Sarcasm F1 was 0.72, acceptable for the use case. Would add a human-in-the-loop flag for low-confidence predictions next time.”

For a full walkthrough of building exactly this kind of system, see Build a Customer Sentiment Dashboard from Scraped Reviews.

Artifact 3: The Customer-Facing Prototype

Competency proven: Can you build something a non-technical user can touch, and iterate based on their feedback?

FDEs are not backend-only engineers. You sit with customers. You watch them use the thing. You fix it while they’re at lunch. Your portfolio needs a shipped prototype with a UI that a real human used.

What to build: A small, functional web app that solves a specific pain point for a real person you know. Not a hypothetical user. Your dentist, a friend in accounting, a local non-profit.

Examples that signal FDE readiness:

• A browser extension that autofills job applications using local LLM inference—proving you can build privacy-sensitive tools that run on-device. See the Job Application Autofill Extension guide for the architecture.
• A personal finance categorizer that ingests bank CSV exports, uses Gemini to classify transactions, and stores results in Supabase. See the Personal Finance Categorizer build.
• A YouTube-to-blog repurposing agent that takes a video transcript and generates a formatted article using Groq and LlamaIndex. See the YouTube-to-Blog Agent walkthrough.

The decision log entry: Record the user’s first reaction. What did they click that you didn’t expect? What did you change in the 24 hours after they used it? This shows you ship, observe, and iterate—the core FDE loop.

Artifact 4: The Performance Tear-Down

Competency proven: Can you diagnose and fix performance issues in production systems you didn’t write?

FDEs are often the first person to stress-test a customer’s integration. When the pipeline falls over at 10x expected volume, you’re on the hook. Your portfolio should show you can profile, diagnose, and fix.

What to build: Take any API or data pipeline—your own or an open-source one—and write a performance tear-down. This can be a blog post or a README with benchmarks.

Structure:

1. Baseline measurement: Latency, throughput, error rate under load.
2. Bottleneck identification: Flame graphs, query plans, network traces. Show your work.
3. Fix applied: With before/after numbers.
4. Lesson: What architectural pattern caused the bottleneck?

Example: Profile an LLM inference pipeline. Compare latency and cost across providers. For a deep dive on the engineering trade-offs in sub-100ms inference, see the Gemini 3.7 Flash latency analysis. This kind of artifact shows you understand the stack from silicon to UI.

Artifact 5: The Internal Tool Hack

Competency proven: Can you identify and automate internal friction without being asked?

FDEs don’t wait for product roadmaps. They see a manual process—a sales engineer copying data between spreadsheets, a support team running the same SQL query 20 times a day—and they automate it. This artifact proves you have the instinct.

What to build: A script, bot, or mini-tool that automated a real task for a real team. The tool doesn’t need to be elegant. It needs to have saved hours.

Examples:

• A Slack bot that queries a database and returns formatted results, replacing a manual process.
• A Python script that diffs two CSVs and flags discrepancies for an ops team.
• A cron job that monitors a log file for specific error patterns and emails a digest.

The decision log entry: Quantify the impact. “This script saved the support team 5 hours/week. It ran for 6 months before being replaced by a proper feature.” That sentence is worth more than any LeetCode score.

Packaging the Narrative

Raw artifacts are not a portfolio. They are evidence. The portfolio is the narrative that connects them. Here is the structure that works:

1. The hook: One sentence that describes the kind of problems you solve. “I build integration bridges and automation tools that ship in days, not sprints.”
2. The case studies: 3-5 artifacts, each with a link to the code and a link to the decision log. The decision log is the primary artifact; the code is supporting evidence.
3. The operational footprint: A section that lists the tools, APIs, and infrastructure patterns you’ve worked with in production. Not a skills list. An operational list: “Have deployed Cloudflare Workers to production with >10k req/day. Have reverse-engineered three undocumented REST APIs. Have built and maintained n8n workflows with 20+ nodes.”
4. The signal loop: A short, honest reflection on what you’re learning now and what you want to learn next. This shows you’re a self-directed learner—a non-negotiable FDE trait.

FAQ: FDE Portfolio Questions

How to get into FDE role?

The most reliable path is to build the portfolio described above, then apply directly to companies with dedicated FDE or Solutions Engineering practices. The role values shipped artifacts over credentials. If you can show you’ve integrated messy systems, built customer-facing prototypes, and documented your operational decisions, you’re already speaking the language of the interview loop. For interview-specific preparation, see The FDE Interview Loop guide.

Is FDE a good role?

For engineers who want high autonomy, customer exposure, and the chance to ship code that unblocks real revenue, it’s one of the highest-leverage roles in tech. Compensation typically tracks with senior engineering roles, often with a variable component tied to customer impact. The trade-off is context-switching and travel, but for the right engineer, it’s a career accelerator.

What items should you include in your career portfolio?

Include shipped artifacts (working code, live URLs), decision logs (written trade-off analyses), and an operational footprint (what you’ve run in production). Exclude toy projects, unfinished repositories, and generic skill lists. Every item should answer: “What did this prove I can do in a customer environment?”

What are three things a portfolio should have?

1. A shipped integration bridge connecting two real systems.
2. A written decision log documenting a hard trade-off with real outcomes.
3. A customer-facing prototype that a real user touched and gave feedback on.

What about GitHub and Reddit discussions on FDE portfolios?

Communities on GitHub and Reddit often share specific project ideas and feedback. The consensus from these discussions aligns with this playbook: build things that solve real problems for real users, document the messy parts, and ship fast. The artifacts that get discussed most positively are integration tools, automation scripts, and performance analyses—exactly the five artifacts above.