5 FDE portfolio projects to build in 2026 (with stacks and briefs)

You can code. You have probably built a RAG chatbot, maybe two. And yet when you read a forward deployed engineer job description, your GitHub feels like it belongs to someone else, because every line of that description talks about customers, legacy systems, security reviews and deadlines, and none of your repos mention a single one of them.

That gap is the whole problem. A forward deployed engineer (FDE) is hired to take an AI product into somebody else's environment and make it work there. So the portfolio that gets read is not the one with the cleverest prompt. It is the one that looks like something a client could have signed off on. If you are still getting to grips with the role itself, start with our explainer on what a forward deployed engineer is, then come back here.

This guide walks through five FDE portfolio projects, each framed as a client brief, with what to build, what to build it with, and what it proves.

The short answer: The best FDE portfolio projects are deployed, secured, measured and explained, like a client deliverable. Five worth building are a legacy-system migration assistant, a permission-aware RAG assistant, an MCP ticket agent with approval gates, a multilingual voice support agent, and a multi-tenant AI service with cost per client. Two built properly beat five built loosely. No portfolio guarantees an interview, but these give a reviewer concrete things to ask about.

Table of contents

• Why an FDE portfolio is judged differently
• Four checks every capstone should pass
• The 5 capstones
• Quick reference table
• How to package your projects
• Common mistakes
• How to choose where to start
• Thinking about structured guidance?
• FAQ

Why an FDE portfolio is judged differently

A standard software portfolio answers one question: can this person build? An FDE reviewer asks a harder one: if we put this person in front of a customer next month, would what they ship survive?

Three things are hard to fake and easy to check. First, can you work inside systems you did not build, with messy data and thin documentation? Second, does what you built hold up under pressure, meaning real security rules, real load and a real bill? Third, can you explain a technical decision to someone who does not code?

A tutorial clone shows none of the three. A project that deals with all of them, even at small scale, shows all three at once.

Four checks every capstone should pass

Before you start any project below, hold it to this standard:

• Deployed. It runs somewhere other than your laptop, behind a real URL or in a recorded walkthrough of the live system.
• Secured. Sign-in, role-based access, secrets kept out of the repo, and a written note on how it handles sensitive data and prompt injection.
• Measured. A fixed test set, named metrics and a results table that includes the cases that fail. "It works well" is an opinion; "84% of answers cite the right source, and these three question types fail" is evidence.
• Explained. A README a stranger could follow, written around the problem rather than the tech stack.

The 5 capstones

1. Legacy migration assistant

The brief.

A company runs an order-management application written years ago. The original developers have left, the documentation is thin, and every change risks breaking something nobody remembers.

What to build. Pick an open-source legacy application with a database. Build an assistant that reads the code and extracts business rules into plain-English specs a human can approve. Then have it rewrite one module at a time on a modern stack. The key move is golden-master testing: record transactions, replay them through both the old and new versions, and only call a module migrated when the outputs match exactly. The old system keeps running throughout.

Stack. Python, FastAPI, PostgreSQL, Docker, GitHub Actions, an LLM API (Claude, Gemini or OpenAI) and a vector store for code search.

What it proves. You can enter an unfamiliar codebase and change it safely, which is the most FDE-specific skill on this list.

Stretch goal. Document which business rules the model extracted wrongly and how your review step caught them.

2. Permission-aware RAG assistant

The brief. A company wants one assistant for its policy documents, but HR files must never surface in an engineering employee's answer.

What to build. An ingestion pipeline that tags every chunk with metadata such as team, sensitivity and version. A retrieval step that filters by the signed-in user's role before searching, not after generating. Answers that cite the exact source chunk and say "I don't know" when retrieval is weak. Then a test set of 30 or more questions, including ones with no answer in the documents and ones that deliberately try to cross permission lines.

Stack. Python, FastAPI, PostgreSQL with pgvector, OAuth or SSO sign-in, Docker, and an evaluation tool such as Ragas.

What it proves. Retrieval is an access-control problem as much as a relevance one, and you can measure answer quality instead of guessing at it.

Stretch goal. Add document versioning so a superseded policy stops appearing the moment a new one is ingested, and add a test that proves it.

3. Ticket agent over MCP with approval gates

The brief.

A support team is buried in repetitive tickets. They will let an agent read and draft, but nobody will let it write to the system of record unsupervised.

What to build. An MCP server that exposes a handful of typed tools: search tickets, read a ticket, add a note, change a category. An agent that classifies each ticket and drafts a reply. Reads run freely, but every write pauses for a human to approve. Add a step limit so the agent cannot loop, and an audit log recording who approved what.

Stack. Python, MCP, a Jira cloud free tier or an open-source helpdesk, an LLM API and PostgreSQL for the audit log.

What it proves. You can give an agent real tools while keeping its permissions narrow and its actions reviewable, which is what a client's security team will ask about first.

Stretch goal. Write a second MCP server for a different ticketing tool and swap it in without touching the agent.

4. Multilingual voice support agent

The brief. A broadband provider's phone lines flood during an outage. Callers speak different languages, ask the same handful of questions, and expect an answer within seconds.

What to build. A speech-to-text, agent, text-to-speech loop working in two or three languages. Give it tools to check outage status (a mock service is fine), explain a bill and book a technician visit, and make it hand over to a human with a summary of the call. Set a latency target per turn, simulate a sudden surge of calls with a load-testing tool, and track what each call costs.

Stack. Python, FastAPI, speech models from Hugging Face or a cloud speech API, an LLM API, Docker, a load-testing tool such as Locust, and AWS or Azure.

What it proves. You think about latency, load and cost, the constraints that decide whether an AI demo can become a live service.

Stretch goal. Measure how many scripted test calls the agent resolves without a human, and report the number honestly, including where it hands off.

5. Hardened multi-tenant AI service

The brief. Two clients share your AI service. Client A must never see Client B's data, and the finance team wants to know what each client costs per month.

What to build. A versioned FastAPI service with OAuth or SSO sign-in and role-based access. Tenant isolation at the data layer. Sensitive data masked before any model call, plus guardrails against prompt injection. Logging, tracing and alerts, a load test, and a dashboard showing cost per tenant. Deploy it with containers, CI/CD and Terraform on AWS or Azure.

Stack. FastAPI, PostgreSQL, Docker, GitHub Actions, Terraform, OpenTelemetry, and AWS or Azure.

What it proves. Production ownership: you can be trusted with security, monitoring and cost, not just features.

Stretch goal. Build a small red-team set of injection and data-leak prompts, then report how many your guardrails block.

Quick reference table

Time estimates are rough, for one person building alongside a job.

How to package your projects

The build is half the work. Every capstone above should ship with five things:

• A README that opens with the problem. Two sentences on who the users are and what hurt, before any mention of tools.
• An architecture diagram. Components, data flow, and the points where sign-in and sensitive-data masking happen.
• An evaluation report. Test set size, metrics, a results table and three to five failures you found and fixed.
• A one-page decision record. What you chose, what you rejected and why, and what you would change with more time.
• A short demo video. Three to five minutes, problem first, one failure handled well. Link it at the top of the README.

If something broke while you built, write a short post-mortem about it. Interviewers tend to ask about failure, and a written answer is rare.

Common mistakes

• Cloning a tutorial. A weather app or MNIST classifier shows you can follow instructions, not that you can handle a messy brief.
• Only testing the happy path. Reviewers look for what happens when an API times out or a user asks something off-limits.
• Showing no numbers. A project with no metrics cannot be defended in an interview.
• Leaving it on localhost. If nobody else can run it, it is hard to believe it works.
• Hiding the failures. A results table with a 100% pass rate looks like easy tests. A fix that lifts you from 73% to 91% looks like real work.
• Writing a README about tools. Lead with the problem and the decisions, not the stack.

How to choose where to start

You do not need all five. If you are earlier in your career, build the permission-aware RAG assistant first: it is the smallest, and its test set carries over into later projects. Then add the hardened service on top of it. If you already have integration or backend experience, start with the legacy migration assistant, which stands out the most. Whatever you pick, finish it, document it and put it somewhere a stranger can run it before starting the next.

Thinking about structured guidance?

Building these alone works, but most self-taught engineers stall in the same place: nobody reviews the design, nobody pushes back on the trade-offs, and no deadline forces the project to ship.

The Leap FDE Cohort by Masai is built around that gap. It is a 12-week program for engineers who can code but have never owned a problem with a client. It opens with four days in Goa, where you learn what the FDE role involves, ship a live product in a pod and get a Python-for-production session. Ten weekends of online building follow, covering data pipelines and secured APIs, legacy SQL and SOAP systems, deployment on AWS or Azure, containers, CI/CD and Terraform, RAG with citations and evals, MCP agents with limits and approval steps, and security, monitoring and cost per client. Alongside the technical work, five client and business engagement sessions cover stakeholder management, objections, compliance conversations, handover and ROI, and pricing and negotiation.

Each participant builds one production-grade AI capstone, deployed live, with their own data, an agent that takes action and a security check before it ships. Sample capstones include an AI legacy application migration system and a multilingual AI voice support agent, close cousins of projects 1 and 4 above. Participants who score at least 45% across evaluations and attend at least 65% of sessions are invited to a 36-hour hackathon in Bangalore, where they take on a real partner company's problem and present to that company.

Some practical details. It needs at least one year of hands-on technical experience, costs ₹1,50,000 + GST, and starts on 6 December 2026. Applying costs ₹999. Masai is clear that it is not a placement program: the outcome is a deployed project and demonstrated ability to take over and run a system for a client, not a job guarantee.

Either path works. What matters is that you keep finishing projects.

FAQ

How many FDE portfolio projects do I need?

Two or three deep ones are enough, provided each is deployed, secured, measured and documented. Depth beats count.

Which FDE project should I build first?

Start with the permission-aware RAG assistant. It is the smallest of the five, and the test set you build for it can be reused in later projects.

Do I need paid enterprise software to build these?

No. Open-source applications, free tiers of tools like Jira, and small cloud budgets cover most of it. Shut cloud resources down when you are not using them, and watch model credits, since LLM calls add up during testing.

Should I use AWS or Azure?

Pick one and deploy everything there properly. Both are widely used in enterprises, and showing you can map the design to the other in your README is a bonus.

Are RAG chatbot projects still worth building?

A basic upload-a-PDF chatbot adds little. A RAG system with permission-aware retrieval, citations, versioning and an evaluation report is still a strong piece, because those are the problems clients actually have.

How long does one capstone take?

Roughly two to four weeks of evenings and weekends, depending on the project. If one is taking much longer, shrink the scope and ship a smaller version.

Can projects alone get me an FDE role?

They help, but they work best next to engineering experience. Most FDE roles expect solid fundamentals, and projects are how you prove you can apply them to messy, client-style problems. No project set guarantees an interview.

What do reviewers look at first in an FDE portfolio?

Usually the README and whether the project actually runs. A clear problem statement, a working setup guide and an honest limitations section make a good first impression.

What is the Leap FDE capstone?

It is one production-grade AI product, built in the last online build week and deployed live, using your own data, with an agent that acts and a security check before it ships.

Is the Leap FDE program a placement program?

No. It does not guarantee a job. The outcome is a deployed project and demonstrated ability to run a system for a client.

What does the Leap FDE Cohort cost, and what is not included?

It costs ₹1,50,000 + GST. It covers shared accommodation and scheduled meals during the Goa and Bangalore stays, practitioner and mentor sessions, and learning materials. Travel, visas, cloud and model credits, APIs and your laptop are not included.