The FDE Portfolio: What to Build to Demonstrate Deployment Velocity and Get Hired

Why Your Portfolio Needs to Prove Velocity, Not Just Code

A standard software engineering portfolio demonstrates technical depth. A Forward Deployed Engineer portfolio must demonstrate something different: deployment velocity. Hiring managers for FDE roles at companies like Palantir, Scale AI, and various defense-tech startups aren't primarily checking if you understand Big-O notation. They're checking if you can land in a customer environment on Monday and have a working integration—with error handling, auth, and a runbook—by Friday.

This changes everything about what you build and how you present it.

The core signal is time-to-value. Your projects need to scream: "I understand that shipped software in a messy enterprise environment beats elegant code that never leaves localhost." This means the artifacts you include—runbooks, monitoring dashboards, architectural decision records—often matter more than the code itself.

The FDE Portfolio vs. The SWE Portfolio

If you're coming from a forward deployed engineer bootcamp or self-study path, this distinction is critical. Bootcamp projects often optimize for local demos. Real FDE work optimizes for production resilience. Your portfolio must close that gap.

The Anatomy of a High-Signal FDE Project

Every project in your portfolio should contain three layers. Most candidates stop at Layer 1.

Layer 1: The Working Integration. This is table stakes. A script or small service that connects two or more systems. An API wrapper, a webhook handler, a data pipeline.

Layer 2: The Operational Envelope. This is where you separate yourself. Include:

• A runbook (a RUNBOOK.md) that documents common failure modes and step-by-step recovery procedures. If a service is down at 2 AM, can an on-call engineer who's never seen your code restore service using only your runbook?
• Observability. Structured logging (JSON format, not console.log strings), a Grafana dashboard screenshot, or even a simple health-check endpoint that reports dependency status.
• Fault injection evidence. Show what happens when an external API returns a 429, a database connection drops, or a payload exceeds size limits. Screenshots of graceful degradation are gold.

Layer 3: The Business Context. A short "why" section in your README:

• What customer problem did this solve?
• What was the time constraint? (e.g., "Built during a 48-hour customer trial to unblock a $500K deal")
• What was the outcome? (e.g., "Reduced manual triage time from 4 hours to 15 minutes per incident")

Project 1: The Integration Bridge (APIs, Auth, and Error Handling)

This project proves you can safely move data between two systems that were never designed to talk to each other. This is 40% of FDE work.

Scenario: A customer uses an on-premise ERP system that exposes a REST API. They need to push new purchase orders to a cloud-based fulfillment service. The ERP API uses OAuth 2.0 client credentials; the fulfillment service uses API keys. The ERP system occasionally sends malformed XML instead of JSON when under load.

What to build: A stateless bridge service (Python/FastAPI or TypeScript/Hono).

Critical implementation details:

• Auth translation: Implement OAuth 2.0 client credentials flow to get a token from the ERP, cache it until expiry, and inject it into requests. Simultaneously handle the fulfillment service's API key header.
• Circuit breaker: If the fulfillment service returns 5xx errors, stop sending requests for 30 seconds. Log the circuit state change. Return a 503 to the ERP with a Retry-After header.
• Malformed payload handling: The ERP sometimes sends XML with a Content-Type: application/json header. Your service must detect this (try json.loads, fall back to xml.etree.ElementTree, log the mismatch as a structured error with the raw payload truncated to 1KB).
• Idempotency: The ERP retries failed requests. Use an idempotency key (a field in the ERP payload) with a Redis or in-memory store to prevent duplicate purchase orders. Document the deduplication window.
• Runbook entry: "ERP sends XML instead of JSON" — step-by-step recovery: check logs for payload_type_mismatch, verify ERP load balancer health, contact ERP admin if >5% of requests affected.

Portfolio presentation: Include a 90-second video walkthrough where you deliberately trigger each failure mode and show the service recovering. Link to the runbook. Show a screenshot of structured logs during the failure.

Project 2: The Operational Artifact (Logs, Monitoring, and Runbooks)

This project flips the script: you're not showing off what you built, you're showing off how you'd keep it alive in production. This directly addresses the "deployment velocity" signal because it proves you don't throw code over the wall.

Scenario: Take a real project you've already built—ideally from a forward deployed engineer bootcamp or personal work—and add a production-grade operational layer.

What to build: Not new features. New operational artifacts.

Critical deliverables:

• Structured logging retrofit: Replace all print() or unstructured log statements with structured JSON logs. Include fields: timestamp, level, service, trace_id, error_code, user_id (if applicable), duration_ms. Use python-json-logger or pino for Node.js.
• Health check endpoint: A /health endpoint that returns 200 only if all critical dependencies are reachable. For a database, run SELECT 1. For an external API, call a lightweight status endpoint. Return JSON: {"status": "healthy", "checks": {"database": "ok", "fulfillment_api": "ok"}}. If a dependency is down, return 503 with details.
• Grafana dashboard: Even a simple one. Two panels: request latency (p50/p95/p99) and error rate by endpoint. Screenshot it. Explain what you'd alert on (e.g., "p95 latency > 2s for 5 minutes triggers PagerDuty").
• ADR (Architectural Decision Record): One page. "ADR-001: Chose Redis for idempotency key storage over Postgres because write throughput required <1ms latency and data loss of idempotency keys during a restart is acceptable (duplicate purchase orders are caught by the fulfillment service's own deduplication)."

Portfolio presentation: This project is a README that links to a runbook, an ADR, and a dashboard screenshot. The code itself is secondary. The narrative is: "I understand that software is a liability until it's observable and recoverable."

Project 3: The AI Deployment Sprint (Prompt Engineering to Production)

AI deployment is rapidly becoming a core FDE competency. Customers want LLM features integrated into their existing workflows, and they want them deployed in weeks, not months. This project proves you can ship an AI feature with the same operational rigor as a traditional integration.

Scenario: A customer support team spends 3 hours per day manually triaging incoming emails and drafting repetitive responses. They want an AI assistant that reads emails, classifies intent, and drafts replies for human review.

What to build: An end-to-end pipeline, not just a prompt. This is a perfect opportunity to demonstrate skills from a forward deployed engineer bootcamp project.

Critical implementation details:

• Prompt engineering with version control: Store prompts in a separate file (e.g., prompts/v1_classify.yaml). Log which prompt version was used for each inference. This allows rollback if a new prompt regresses accuracy.
• Guardrails: Before sending a draft to the human reviewer, run a validation step. Check for: forbidden phrases (e.g., legal promises), PII leakage (use a regex or a lightweight NER model), and off-topic responses. If a guardrail triggers, flag the draft for manual review and log the violation.
• Human-in-the-loop API: Expose an endpoint that returns a draft and a unique review_id. A separate endpoint accepts a review_id and an approved boolean. Only approved drafts are sent to the customer. This is the exact pattern used in enterprise LLM deployments.
• Cost tracking: Log token usage per request. Add a dashboard panel showing daily spend. Enterprise customers care deeply about cost predictability.
• Runbook entry: "Model returns gibberish" — check prompt version, check for prompt injection in the email body, fall back to a rule-based classifier, escalate to on-call.

Portfolio presentation: Show the pipeline with a real email example. Walk through a happy path (email -> classify -> draft -> approve -> send) and a failure path (email -> guardrail triggers -> flagged for review). Include the cost dashboard screenshot.

Structuring Your Portfolio Narrative

Your portfolio isn't a list of projects. It's a story about how you operate under deployment pressure.

Portfolio homepage structure:

1. One-line value proposition: "Forward Deployed Engineer. I ship integrations in days, not weeks, with production-grade observability and runbooks."
2. Three featured projects (the ones above), each with:
   • Problem and time constraint (1 sentence)
   • Architecture diagram (the ReactFlow JSON above, rendered)
   • Link to runbook and ADR
   • Screenshot of dashboard during a failure scenario
3. "Deployment Velocity Log" — a timeline of 3-5 short entries documenting real (or simulated) deployment events. Example: "Day 1: Deployed bridge service to customer staging. ERP auth flow failed due to expired cert. Updated runbook. Day 2: Cert renewed, integration live. P95 latency 120ms. Day 3: ERP sent XML under load. Circuit breaker opened. Service recovered automatically after 30s. Post-mortem filed."

This format directly mirrors the FDE interview loop, where you'll be asked to walk through a deployment, debug a failure, and present a demo. Your portfolio is your rehearsal.

FAQ: FDE Portfolio and Career Context

Q: Do I need to be an expert in a specific industry to get an FDE role?

No, but you need to demonstrate the ability to learn a customer's domain quickly. Your portfolio projects should show you can model a business process (purchase orders, support tickets) in code. If you're targeting a specific sector (defense, healthcare, fintech), build one project that uses domain-relevant data (e.g., synthetic HL7 messages for healthcare, FIX protocol messages for fintech).

Q: How important is the choice of programming language?

Python and TypeScript dominate FDE work because of their ecosystem velocity. Python for data pipelines and AI integration, TypeScript for webhook-heavy integrations and API bridges. Demonstrate proficiency in one, familiarity with the other. A Go project can be a differentiator for performance-sensitive deployments but is rarely a requirement.

Q: Can these projects be from a bootcamp or course?

Yes, but you must go beyond the curriculum. A forward deployed engineer bootcamp project is a starting point. Add the operational layer (runbook, structured logging, health checks) yourself. The difference between a bootcamp project and an FDE portfolio project is the operational envelope. No bootcamp will build that for you.

Q: What if I don't have access to real customer environments?

Simulate them. Use Docker Compose to spin up a local environment with multiple services. Introduce failure modes deliberately: use tc (traffic control) to add network latency, kill a container to simulate a dependency outage, use a proxy to inject malformed responses. Document how your service behaves. This is more impressive than a perfect-path demo because it shows operational thinking.

Q: How do I get the "deployment velocity" signal if all my projects are personal?

Time-box everything. In your README, state: "This project was built and deployed in 8 hours, end-to-end." Then include timestamps in your git commits and deployment log to back it up. The constraint itself is the signal. If you can build a working integration with a runbook in 8 hours, a hiring manager can reasonably extrapolate that you'll be productive in a customer environment within a week.

Q: What's the typical compensation for FDE roles?

FDE roles at top-tier companies (Palantir, Scale AI, Anduril) typically range from $130K-$180K base for early-career, with total compensation (including equity and bonuses) reaching $180K-$250K. More senior FDEs with a track record of closing large deals can exceed $300K. The premium over standard SWE roles reflects the customer-facing, travel-intensive nature of the work and the direct revenue impact.