Can an Individual Do FDE Alone?

Knowing the technical work of a craft is not the same as knowing how to run a business that profits from it. — Michael Gerber, The E-Myth Revisited

"FDE work — go independent and you have no one to vouch for you; stay employed and it's grinding."

One independent practitioner left that as his own summary on a forum. He calls himself an OPC — One Person Company. With no backing, the only path he can see is to stay humble and first accumulate enough experience, solution patterns, and infrastructure; the post ends with him looking for partners: to explore client sources, methodology, and infrastructure together.¹

That sentence is exactly this chapter's question: can one person actually take on enterprise customers as an FDE? Which engagements can you accept, and which ones become traps the moment you do?

I. Splitting One Question into Two

The question "can an individual do FDE" is actually two completely different questions bundled together.

Question one: can one person complete a narrowly scoped prototype or evaluation? Yes — and AI has significantly amplified that ability. A skilled person using off-the-shelf models, tools, and frameworks can produce an evaluable prototype for a single customer within a few weeks; that is entirely feasible today (Chapter 24, on how the pieces assemble).

Question two: can one person sustainably carry production-grade delivery for multiple customers? Extremely hard. Production delivery isn't one skill — it's parallel accountability: business discovery, system integration, security and compliance, engineering delivery, customer communication, training and adoption, live support, product feedback — eight responsibilities hung on a single person, and if any one of them breaks inside a customer's production system, someone has to stand behind it. Live support means being there when the customer's system alerts; running multiple customers in parallel means being there when three customers alert at the same time. A 7×24 responsibility structure is something one person mathematically cannot carry — delivery goes far beyond writing code; see the three exit conditions: business integration, knowledge governance, and system integration,² every one of them a continuous responsibility.

Seen from another angle, it's clearer still: these eight responsibilities were never designed for one person in the first place. The complete form of FDE is a built team (Chapter 26's trio is one way to staff it) — and the root reason the OPC doesn't work is precisely that it compresses a team into a single person.

So the answer isn't "yes" or "no." It's this: an OPC is not logically impossible, but as a business proposition it cannot be run as the mainstream organizational form. Whether it can be made to work depends on the model and conditions you choose — which is exactly what the two tables below are for.

II. The Father of the FDE Model, With a Warning: "Don't Try This at Home"

Asked what people thinking about trying this playbook should do, McGrew's advice is one line — don't try this at home: "it's probably bad for you — you're probably going to end up doing services. Only if you really try hard not to, and fail — then maybe it actually is a moat for you, if it's the only thing that can possibly work in your market."³

As a warning, this lands even harder on the individual than on the company: the default outcome of doing FDE alone is becoming a one-person services shop — selling yourself by the day, carrying unlimited liability, with no product leverage and no reusable assets.

But note the structure of the sentence: it doesn't say "impossible." It says "the default outcome is bad — unless specific conditions are met."

What are the conditions? Exactly what we're about to cover.

III. Four Models: The Conditions Table

Model	Preconditions for it to work	What it must not be confused with
Fractional FDE / consultant (fixed-cadence commitment, e.g., two days a week)	The customer has a clear decision-maker, the system boundary is limited, the customer side has an assigned maintenance owner, and the goals are quantifiable	Round-the-clock backstopping of results
Fixed-scope evaluation / go-live readiness audit	Deliverables, data access, and the boundary of responsibility spelled out in the contract	A full delivery project
Vertical FDE studio	Reusable assets (connectors / evals / templates) accreting out of deliveries for a handful of customers	Day-rate, on-site outsourcing
FDE-led product startup	Validate the workflow first with a small set of design partners, then extract the repeating parts into a product	An endless pile of infinitely customized projects

The four models are ordered from lightest to heaviest responsibility. The first two carry no production responsibility — the deliverable is a report or a prototype, and the engagement ends at handover. The last two carry partial production responsibility, but hedge the single-person limit with assets (a reuse library) or organization (partners).

The most valuable column in every row is the right-hand one — the thing it must not be confused with is precisely the standard way an individual engagement goes off the rails: you negotiate a model-one price and end up doing backstop work; you sign an evaluation contract, and a few weeks in the customer says "while you're at it, why not run the go-live too." The model's boundary has to be spelled out in the first email — not discovered to have dissolved in month three.

Read the practitioner from the opening back through the conditions table: three years of engagements, a self-built case library, reusable modules — the asset column already has the embryo of model three (the vertical studio), which is exactly what he means by "accumulating infrastructure." The blockers are just as clear: backing (why would a customer trust one person) and channel (where does the work come from) — hence staying humble, looking for partners, posting in the community.¹ The path he's instinctively chosen lines up exactly with the conditions table: one person can't carry all the responsibility, so use asset reuse plus a partner network to split the responsibility out. One community sample isn't a conclusion, but it genuinely exists: the model table isn't theory — it's a map of a road someone is walking right now.

Ventus AI is a ten-person, Series A company, and co-founder Vincent Lu is himself an FDE. The early shape he describes is almost a hybrid of model three (the vertical studio) and model four (the product startup): the FDE follows the work from presales through post-sale and carries commercial targets directly — "save the customer two million, or help them earn two million more." That is this chapter's "eight responsibilities hung on one person" argument with a name attached. What's even more worth recording is his on-site strategy: Ventus's FDEs mostly don't embed on-site, and the reason is that they are "very clear about what they're providing the customer and how much they can charge for it." He distinguishes two motives for embedding: the good motive is giving a large customer a sense of security, with a clear delivery goal; the bad motive is "I don't know what I'd have you do, but you're a big customer — let's grab the seat first." The second kind he judges outright unhealthy — it produces no value.⁴ The community practitioner from this chapter's opening proves that someone really is walking the path the conditions table describes; Ventus AI proves what the path looks like once it works — a control group that can quote specific numbers, specific customer relationships, and a specific business model.

IV. Which Customers Are Yours: Market Segmentation

Choosing customers starts with customer size.⁵ Large enterprises (several hundred employees and up, revenue in the hundreds of millions) are the territory of the big platform vendors' multi-million deals; a small team can at most pick up the accompanying training. Micro-businesses have budget for one round of training or consulting at best. The best entry point for an individual is the mid-sized enterprise — a few dozen to a few hundred people, revenue starting in the tens of millions: the decision chain is short (the boss can sign off), and a single problem carries high value (his own reported numbers: a problem worth ten million easily justifies a fee of one million). The selection framework is a quadrant: high or low value × fast or slow decisions — take the "high value × fast decision" cell; of the other three, either they can't sustain you or they'll drag you down (see Figure 27-1).⁵

Figure 27-1: The individual's priority entry point is the high-value, fast-decision customer — not the most famous one.

V. The Audit: An Individual's First Sellable Product

If the quadrant has picked your customer, what do you sell first? One practitioner gave an answer specific down to the motion: the process audit. The method: get yourself seated next to the person in the customer's company with the most repetitive job, and watch for an hour; then, following Chapter 6's approach (record and probe → filter → quantify), produce an audit report — the real workflow of one link in this company, which steps are suited to handing to AI, and what the economic value is.⁶

The audit is the service enterprises genuinely pay for; it is the first phase before any project gets built, and the biggest bottleneck; and the report is itself your showcase — when applying for an FDE job or pitching a business, it proves you have seen real workflows.⁶ Check it against the conditions table: the audit is the standard product form of model two (fixed-scope evaluation) — no production responsibility, and it naturally sidesteps the responsibilities among the eight that a single person can't carry. The complete entry path for an individual thus takes shape: audit (see the real workflow) → narrow prototype (model two, deepened) → join a partner network (Section VIII) or settle into a studio (model three).

VI. A Stop List Before Taking the Work

Turn it around: which engagements should you not take. Six warning signals; hit two or more, and either decline or restructure (fix a fixed scope, bring in a partner to share the responsibility):

First, the customer has no clear decision-maker. Three months in and still "let's align internally" — neither the ability to pay nor the ability to decide exists.

Second, the system sits on a critical production path and demands uninterrupted operation. A 7×24 responsibility collides head-on with the single-person reality (Section I).

Third, you're asked to sign off on security and compliance alone. Signing is an organizational act; an individual's signature means individual backstopping — unlimited liability.

Fourth, the customer has no internal maintenance owner. No point of contact for post-launch maintenance means that person defaults to you — free of charge, forever.

Fifth, "let's just start and see" — requirements with no boundary. Where no scope exists, price is meaningless (Chapter 20).

Sixth, an on-site invitation with no articulable goal. A good embedding happens when the customer has already worked out what is to be delivered and wants to give a large customer a sense of security; the bad kind is "I don't know what I'd have you do, but you're a big customer — let's grab a seat first."⁴ If you can't tell which one it is, ask before you accept.

VII. Part-Time: Does It Count, and Which Kind Are You Selling

One more thing to settle while we're here: part-time. Part-time prototyping and evaluation is workable — models one and two are bounded in scope and duration anyway. Part-time production delivery is not being responsible to the customer — this isn't conservatism, it's an inference from the responsibility structure: live support and part-time are incompatible in time, and when a customer buys production delivery, part of what they buy is "you'll be there when something breaks." Decide which kind you're selling before the price conversation, not after.

VIII. Three Ways Out for Those Who Don't Go It Alone

Last, the structured options for people who don't want to go it alone.

First, join a partner network. The system run by the practitioner quoted in Chapter 26 is a living sample: a core team owns client acquisition and acceptance, and outside consultants collaborate project by project.⁵ For an individual, this solves the two most fatal gaps of going alone — backing (the network's brand vouches for you) and channel (the work comes from the network); the price is giving up part of your pricing power.

Second, join an established organization. The giants are building delivery organizations in the thousands (Chapter 26's Accenture × Microsoft shape) — for an individual, joining one gives more leverage than going alone: the same capability, standing on someone else's platform, brand, and feedback channel.⁷

Third, make the studio vertical. Anchor to one industry, use three to five customers to cut all the way through the workflow (Chapter 21), and let the product compound.

Going alone, joining an organization, or working through a network — walk this road five, ten years, and where does it lead? The final chapter: the endgame.

---

Footnotes

1. "Doing FDE Work in Wuhan, Looking for a Partner" (linux.do thread) ↩ ↩²

2. Crossroads × Rolling AI, "A Conversation on FDE" (podcast) ↩

3. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩

4. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩ ↩²

5. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩ ↩² ↩³

6. "FDE Engineer 101: Bridging the Gap Between AI and Business" (Chinese-language compilation video) ↩ ↩²

7. Accenture Newsroom, "Accenture Launches Microsoft Forward Deployed Engineering Practice to Help Organizations Scale AI Across the Enterprise" ↩