The best project I ever shipped is a dispatch system that saves a regional freight company something like eleven person-hours a day. I can describe it to you in exactly those terms, because the NDA says I can't say much else. No name, no logo, no screenshots of the real thing.

Welcome to the FDE portfolio problem: your best FDE portfolio examples are confidential and often legally unshowable, while every portfolio guide on the internet assumes you can post a case study with the client's logo splashed across the hero image.

You can still win clients. You just need different artifacts. Here's how, with FDE portfolio examples drawn from what actually works in this niche.

The direct answer: an FDE portfolio wins clients by showing judgment, not logos. The three formats that work are the anonymized narrative case study, the sanitized demo with real screens and fake data, and the public rebuild of a generic workflow. Two or three strong pieces beat ten thin ones. Every piece should answer the question prospects are actually asking: how does this person think?

Why FDE Portfolios Are Weird

Most engineering portfolios run on artifacts: repos, deployed apps, named employers. FDE work runs on trust, and the trust is contractual. The client paid for a custom system and, often, for your silence about the details. Their margin might be inside that workflow.

The standard advice, "just show your work," bounces off. Your work is a logistics dashboard you can't screenshot, a document pipeline for a law firm you can't name, and a forecasting tool whose very existence is competitively sensitive. Great. Build a portfolio out of that.

What prospects actually want to see isn't the logo. It's evidence that you've sat inside a messy operation, made good calls under constraint, and shipped something that stuck. All of that survives anonymization.

The Anatomy of a Case Study That Sells

The format that works has four beats: situation, constraint, decision, outcome. Situation: "a 40-person regional distributor drowning in spreadsheet order entry." Constraint: "no budget for an ERP migration, skeptical staff, data in nine places." Decision: the two or three calls that made the project, meaning what you built first, what you refused to build, and why. Outcome: numbers with the serial numbers filed off, like "order entry dropped from 90 minutes a day to about 10."

That structure works anonymized because the specifics that sell aren't names. They're the constraints and the reasoning. "A regional distributor" isn't a cop-out; it's a genre, and every ops leader reading it is mentally substituting their own company. That's the point.

One more rule: get permission anyway, in writing, for the anonymized version. Most clients say yes to "I'll describe the problem and results without identifying you." Some will even give you a quotable line. A quote from "Operations Director, distribution industry" still beats no quote.

FDE Portfolio Examples That Actually Win Work

Three formats, in order of effort:

The Public Rebuild Trick

The public rebuild deserves emphasis because it compounds. It demonstrates current skill (your dispatch project was three years ago; this is now), it gives you something linkable in every cold outreach, and it pre-answers the skeptical prospect's first question. It's also honest in a way spec work isn't: you're not pretending it's a client project, you're showing how you'd approach a common one.

Pick workflows adjacent to your best client stories. If your anonymized case study is a dispatch tool, your public rebuild might be a route-planning demo on open data. The two artifacts sell each other.

Show How You Think, Not Just What You Built

The artifact that separates FDE portfolios from developer portfolios is the decision log. Write up the option you rejected and why: "we could have built a full scheduling engine; we built a drag-and-drop board instead, because the dispatcher's judgment was the algorithm and the software's job was to keep up." That paragraph teaches a prospect more than any screenshot.

This is also where the money context lives. Prospects comparing you to a hire or an agency are doing quiet math, and it helps if your portfolio meets that math head-on, the same way buyers benefit from understanding what forward deployed engineers actually earn and why rates look the way they do. Judgment plus transparency is a hard combination to compete with.

And show the boring parts. A paragraph about how you ran the first 30 days of an engagement, the shadowing, the workflow mapping, the moment you discovered the real process wasn't the documented one, builds more trust than three feature lists. Clients have been burned by people who started coding on day one.

The Artifacts That Close Deals

Package each engagement as one page: three screenshots (sanitized), four numbers, one quote. That's it. Put the pages on a simple site, fast and readable, no clever scroll animations. Honestly, a well-made PDF works fine for the first year. The bar is "a prospect can forward this to their business partner and it sells while you sleep."

Resist the urge to pad. Two great case studies plus one public rebuild beats eight paragraphs of mush. Each piece has to show a decision, a constraint, and a result. If it's just a tech stack and some adjectives, it's not a portfolio piece, it's a resume line. Which is fine, since technical depth has its place, and that place is usually the second conversation, not the first.

Common Portfolio Mistakes

Quick-fire, because I've made most of them:

The meta-lesson: your portfolio is itself a work sample. A clear, honest, well-structured portfolio is evidence you run engagements the same way. A messy one is evidence too, and prospects are reading it both ways.

Start with one anonymized case study this week. Pick your best story, strip the name, write the four beats. The clients you're losing to "we'll think about it" are waiting for exactly that page.