From Bespoke AI to Product

The general FDE lesson — bespoke is the right start, but the ones who last productize it — is covered in the foundational series. Here it takes an AI-specific form, because AI deployments have a particular structure: they share a lot underneath (the grounded-AI architecture of post 4, the eval discipline of post 5) even when the surface is entirely custom. That shared substrate is exactly what makes productization possible, and powerful. This post closes the series by turning the engagement loop of post 1 into a compounding system.

Why bespoke is the right start for AI

It’s tempting to try to build the general AI product first and deploy it everywhere. For AI this is usually a mistake, and bespoke-first is the wiser path: - You don’t yet know what generalizes. Until you’ve deployed to several real customers, you can’t tell which parts are common and which are truly customer-specific. Building a “general” AI product before that is guessing, and AI’s customer-specific parts (their data, their definition of correct, their workflow) are exactly the parts that matter. Premature generalization builds the wrong abstractions. - AI value is inherently contextual. The whole thesis of this series is that AI value comes from the customer’s data and workflow (post 1). A too-general product loses the grounding and fit that create the value. Bespoke deployments capture it, and teach you what a product would need to preserve. - Real deployments are the only real requirements. Each bespoke engagement surfaces what actually matters — which failure modes recur, which integrations are always needed, which parts of the eval discipline are universal. That’s requirements gathering money can’t otherwise buy.

So the AI FDE starts bespoke deliberately, treating each deployment as both a delivery and a probe into what the product should become.

The pattern: what repeats becomes platform

The art is recognizing what recurs across deployments and extracting it, without prematurely generalizing what’s genuinely custom. A useful discipline is a rule of repetition: the first time you build something, build it bespoke; the second time you see the same need, note it; the third time, productize it. Waiting for the pattern to prove itself avoids building the wrong abstraction, while acting on it avoids rebuilding the same thing forever.

For AI deployments, what typically graduates from bespoke to reusable platform is remarkably consistent — it’s the substrate the whole series described: - The grounding pipeline (post 4) — ingestion, chunking, embedding, permissioned retrieval. Every deployment needs it; only the connectors and data differ. This becomes core platform. - The evaluation harness (post 5) — the machinery to build eval sets, score, and gate on quality. The content of the eval set is customer-specific; the harness is universal and hugely valuable to reuse. - The gateway and observability (post 7) — provider routing, caching, cost control, logging, quality monitoring. Pure infrastructure, identical across customers. - Guardrails and UX patterns (posts 5, 6) — abstention, citations, human-in-the-loop review flows. The same patterns recur; only the specifics change.

What stays bespoke: the customer’s data connectors, their eval-set contents and definition of correct, their specific workflow integration, and their trust-building. The platform handles the common substrate so each new deployment is mostly configuration and customer-specific glue rather than rebuilding the foundation. That’s the leverage: the platform makes the FDE dramatically faster, and speed on the next deployment is the whole payoff of productizing the last one.

The flywheel

Put together, bespoke AI work becomes a compounding flywheel:

   bespoke deployments  ──▶  patterns extracted  ──▶  platform + components
          ▲                                                    │
          │                                                    ▼
   field learnings   ◀──  faster, better next   ◀──  each deployment reuses
   shape the product      deployment                 the platform

Each deployment feeds the platform; the platform accelerates the next deployment; the accelerated deployments generate more learnings; the learnings improve the platform and the product. The AI FDE org that runs this flywheel gets faster and better with every customer, while one that treats each deployment as a fresh custom build stays linear forever. This is how forward-deployed AI work scales from heroic one-offs into a business.

Crucially, the flywheel also connects the field to the product team. The AI FDE is the org’s richest source of ground truth about what real customers need — which use cases recur, where deployments stall, what would have made the last five engagements faster. Channeling that back (not as anecdotes but as patterns) is how the core product gets built on reality instead of speculation. The FDE who does this becomes disproportionately valuable, because they turn field experience into product direction.

Designing deployments for graduation

Knowing the flywheel exists changes how you build each bespoke deployment. Instead of pure one-offs, you build with graduation in mind: - Separate the common from the custom. Structure each deployment so the reusable substrate (grounding, eval harness, gateway) is cleanly divided from the customer-specific glue. This makes extraction into the platform easy when the pattern proves out. - Use the platform as it grows. Each deployment should build on the accumulating platform, not beside it — so the platform is continuously exercised and improved by real use. - Capture learnings deliberately. Note what was custom and why, what failure modes appeared, what was slow. This is the raw material for both platform improvements and product direction.

You’re not choosing between “bespoke” and “product” — you’re running a pipeline that continuously converts the former into the latter, and designing each engagement to feed it.

The AI FDE career arc

This series has described a role that sits at an unusual and valuable intersection: deep enough technically to build grounded, evaluated, production AI systems; fluent enough with customers to discover real problems and earn trust; and product-minded enough to turn one-offs into platform. That combination — the comb-shaped breadth of the general FDE (the foundational series) plus AI depth — is rare and increasingly sought, because it’s exactly what converts the AI capability explosion into realized value.

The arc typically runs: from doing deployments, to leading them, to shaping the platform and product that make all deployments better, to building and running the FDE function itself. Each step trades some hands-on building for more leverage, but the core identity persists — the person who makes AI actually work for real customers, and turns that into something that compounds. In an era where the models are astonishing and the deployments are hard, that person is one of the most valuable engineers a company can have.

The takeaway: every AI FDE builds bespoke one-offs, and should — for AI, bespoke-first is wise because you don’t yet know what generalizes and the value is inherently contextual. The ones who create lasting value turn one-offs into product via a rule of repetition (bespoke, note, productize), extracting the recurring substrate (grounding pipeline, eval harness, gateway/observability, guardrail/UX patterns) into a platform while keeping the genuinely custom parts custom. That builds a flywheel — deployments feed the platform, the platform accelerates deployments, field learnings shape the product — that scales forward-deployed AI from heroic one-offs into a compounding business. And the engineer who runs it, combining FDE breadth with AI depth, is one of the most valuable people in the AI era.

Key takeaways

• Bespoke-first is right for AI: you don’t yet know what generalizes, AI value is inherently contextual (the customer’s data/workflow), and real deployments are the only real requirements — premature generalization builds the wrong abstractions.
• Apply a rule of repetition (build bespoke → note the second time → productize the third): extract what recurs — the grounding pipeline, the evaluation harness, the gateway + observability, and guardrail/UX patterns — into a platform, while keeping the custom parts (data connectors, eval-set contents, workflow integration, trust) custom.
• The payoff is leverage: the platform makes each new deployment mostly configuration and customer-specific glue, so the FDE gets faster with every customer instead of rebuilding the foundation each time.
• This creates a flywheel — deployments feed the platform, the platform accelerates deployments, and field learnings flow back to the product team (the FDE is the org’s richest source of real customer ground truth) — scaling forward-deployed AI from one-offs into a business.
• Design each deployment for graduation (separate common from custom, build on the growing platform, capture learnings), and recognize the career arc: FDE breadth + AI depth is a rare, high-leverage combination that converts the AI capability explosion into realized value.

Further reading

• Solution architecture — designing systems that fit a specific context
• Forward Deployed Engineering — the foundational series (bespoke-to-product, the toolkit, the career)