The Tools an FDE Ships With: Data Connectors, Integration Wrappers, and Demo Scaffolds

An FDE doesn't ship a product. We ship a wedge.

When you land on a customer site—or more likely, join a Zoom call with a dozen skeptical engineers—you aren't carrying a polished, versioned SDK. You're carrying a grab bag of tactical code designed to prove value in hours, not sprints. The tools an FDE ships with fall into three buckets: data connectors that swallow whatever garbage the customer's legacy system spews out, integration wrappers that make enterprise spaghetti look like a clean REST API, and demo scaffolds that turn a blank screen into a "holy shit" moment before the coffee gets cold.

This isn't theoretical. After years of embedding with customers who run everything from ancient Oracle instances to homegrown Node.js disasters held together by a single overworked staff engineer, I've learned that the code you bring with you is the difference between a pilot that converts and a PoC that gathers dust. Let's walk through the actual tools.

The FDE Toolbox: What 'Shipping' Actually Means

In product engineering, "shipping" means merging to main, passing CI, and waiting for the release train. In FDE land, shipping means the customer sees working software touching their real data on day one. The artifact isn't a PR—it's a working integration that survives their bizarre network topology, their undocumented auth proxy, and the fact that their "JSON API" actually returns XML with a Content-Type: text/plain header.

Your toolbox needs to handle three distinct phases of the engagement:

Each phase has a corresponding tool pattern. Let's break them down.

Data Connectors: Ingesting the Unclean, Unstructured, and Undocumented

The first thing you do on any engagement is get their data into your system. This sounds straightforward until you realize their "data warehouse" is a PostgreSQL instance running on a decommissioned Dell server under someone's desk, and the schema was designed in 2014 by a contractor who left no documentation.

The Universal Connector Pattern

I keep a Python skeleton that handles the 80% case. It assumes nothing about the source except that it exists somewhere on a network. Here's the stripped-down version:

from abc import ABC, abstractmethod
from typing import Iterator, Dict, Any
import logging

class BaseConnector(ABC):
    """
    Minimal connector interface. Implement extract() and transform().
    The framework handles batching, retries, and error recovery.
    """
    def __init__(self, batch_size: int = 500, max_retries: int = 3):
        self.batch_size = batch_size
        self.max_retries = max_retries
        self.logger = logging.getLogger(self.__class__.__name__)

    @abstractmethod
    def extract(self, cursor: Any = None) -> Iterator[Dict[str, Any]]:
        """Yield raw records from the source. Accepts a cursor for pagination."""
        pass

    @abstractmethod
    def transform(self, raw_record: Dict[str, Any]) -> Dict[str, Any]:
        """Map source schema to your canonical schema. Do type coercion here."""
        pass

    def load(self, batch: list) -> None:
        """Override if you need custom insert logic. Default is bulk upsert."""
        # Your destination write logic here
        pass

    def run(self) -> int:
        """Full ETL with retry logic. Returns count of records processed."""
        processed = 0
        batch = []
        for record in self.extract():
            try:
                transformed = self.transform(record)
                batch.append(transformed)
                if len(batch) >= self.batch_size:
                    self.load(batch)
                    processed += len(batch)
                    batch = []
            except Exception as e:
                self.logger.warning(f"Skipping record due to {e}")
                continue
        if batch:
            self.load(batch)
            processed += len(batch)
        return processed

This isn't clever code. It's boring, defensively written, and impossible to break in unexpected ways. That's the point. When you're on a customer call and their DBA is watching you connect to their production read replica, clever code is a liability. You want patterns that fail loudly with clear error messages, not elegant abstractions that silently drop rows.

What's Actually in the Bag

Beyond the base class, I carry concrete implementations for the sources I hit most often:

• Postgres/MySQL direct — Parameterized queries, SSH tunnel support because their DB is never publicly accessible
• REST API paginator — Handles cursor-based, offset-based, and the cursed "link header" pagination that three different teams implemented three different ways
• CSV/Parquet from S3/GCS — With schema inference that doesn't choke on the 2GB file their data team swears is "just a sample"
• Kafka consumer — Minimal, no schema registry dependency because theirs is down half the time

The key insight: never ask the customer to change their data format. Your connector eats whatever they have. If their timestamps are strings in three different formats, your transform() method handles all three. If their enum values are inconsistent ("ACTIVE", "active", 1), you normalize them. The customer shouldn't do work to give you data—that's the fastest way to lose a pilot.

Integration Wrappers: The Art of the Thin Adapter

Once data flows in, you need to make your system talk to theirs. This is where most PoCs die. The customer's API has undocumented rate limits, their auth token expires every 15 minutes, and their webhook delivery is "at-least-once" but actually "at-least-three-times-with-duplicates."

The Wrapper Philosophy: Skinny as Possible

An integration wrapper should do exactly three things:

1. Authenticate — Handle token refresh, API keys, mTLS, whatever
2. Translate — Map your internal calls to their API shape
3. Recover — Retry with backoff, queue when downstream is down

Anything beyond this is scope creep. You're not building an SDK. You're building the thinnest possible membrane between two systems.

// The only integration wrapper pattern you need
interface IntegrationWrapper<TRequest, TResponse> {
  auth(): Promise<AuthContext>;
  translate(req: TRequest): ExternalApiPayload;
  call(payload: ExternalApiPayload, auth: AuthContext): Promise<TResponse>;
  recover(error: Error, attempt: number): Promise<TResponse | null>;
}

async function executeWithRecovery<T>(
  wrapper: IntegrationWrapper<any, T>,
  req: any,
  maxAttempts = 3
): Promise<T> {
  const auth = await wrapper.auth();
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      const payload = wrapper.translate(req);
      return await wrapper.call(payload, auth);
    } catch (e) {
      if (attempt === maxAttempts) throw e;
      const recovered = await wrapper.recover(e as Error, attempt);
      if (recovered) return recovered;
      await sleep(Math.pow(2, attempt) * 1000);
    }
  }
  throw new Error("Unreachable");
}

The Real-World Wrapper Kit

Here's what I actually carry into engagements, battle-tested across dozens of enterprise integrations:

This is also where the FDE role diverges sharply from a Solutions Architect. An SA draws boxes on a whiteboard and hands off to an implementation team. An FDE writes the wrapper, deploys it in the customer's VPC, and owns it until it's stable. As we cover in What a Forward Deployed Engineer Actually Does in a Week, the line between design and execution doesn't exist in this role—you're doing both, often simultaneously.

Demo Scaffolds: From Zero to 'Holy Shit' in 20 Minutes

Data flows in. Systems talk. Now you need to show something that makes the customer forget they're looking at a prototype. This is where demo scaffolds earn their keep.

A demo scaffold is not a frontend. It's a tactical UI shell designed to showcase your core capability on the customer's own data. The moment a VP sees their own customer names, their own transaction volumes, their own edge cases rendered in your interface, the conversation shifts from "interesting technology" to "how do we buy this?"

The Scaffold Architecture

The pattern is always the same: real customer data flows through your actual pipeline, not mock data. The UI is a thin shell—Streamlit for Python shops, a lightweight Next.js app for everything else. I keep templates for both that I can fork and customize in minutes.

What's in the Scaffold Kit

• Streamlit template — For data-heavy demos: file upload, live filtering, export. Ugly but fast.
• Next.js + shadcn/ui template — For product-feeling demos: auth, dark mode, responsive. Looks like a real product.
• Authentication shim — Basic auth or magic link that works for 24 hours. Never ask the customer to set up SSO for a demo.
• Feature flags — Toggle capabilities on/off based on what's actually working with their data. Never show broken features.

The cardinal rule of demo scaffolds: every piece of data on screen comes from the customer's own systems. If you show them a dashboard with fake data, you've lost. If you show them their own messy, real-world data cleaned up and made useful, you've won. This is also a core skill covered in The FDE Portfolio: What to Build to Get Hired in the AI Era—the ability to build something that feels real in under an hour is what gets you hired.

The Sunday Night Kit: Templates, Scripts, and Hard-Won Patterns

Before an engagement starts, I run a script that scaffolds a new project directory with everything I might need. It takes 90 seconds and means I never start from zero on a customer call.

#!/bin/bash
# scaffold-engagement.sh
# Usage: ./scaffold-engagement.sh acme-corp

CUSTOMER=$1
mkdir -p engagements/$CUSTOMER/{connectors,wrappers,demo,config,docs}

# Copy connector templates
cp -r ~/fde-toolkit/connectors/* engagements/$CUSTOMER/connectors/

# Copy wrapper templates
cp -r ~/fde-toolkit/wrappers/* engagements/$CUSTOMER/wrappers/

# Copy demo scaffold (choose based on customer stack)
cp -r ~/fde-toolkit/demo-streamlit/* engagements/$CUSTOMER/demo/

# Initialize git and environment
git init engagements/$CUSTOMER
echo "CUSTOMER=$CUSTOMER" > engagements/$CUSTOMER/config/.env
echo "Engagement $CUSTOMER scaffolded. Go build."

This isn't glamorous. It's the kind of preparation that separates an FDE who ships on day one from one who spends the first week setting up boilerplate. The toolkit itself lives in a private repo, continuously refined after every engagement. Patterns that worked get promoted to templates. Patterns that broke get documented with warnings. Over time, this becomes your competitive advantage—not any single tool, but the accumulated scar tissue of dozens of integrations, compressed into reusable code.

This pattern of building personal leverage tools is exactly what separates senior FDEs from junior ones. As explored in Why LLMs Amplify the Gap Between Senior and Junior Engineering Output, the ability to compound your own tooling over time creates an ever-widening productivity delta. LLMs accelerate this further—they're force multipliers for engineers who already know what to build.

FAQ: FDE Tools, Careers, and the AI Era

What does an FDE actually do?

An FDE embeds with customers to make a product work in their specific environment. This means writing integration code, debugging production issues on systems you didn't build, and shipping prototypes that prove value fast. It's equal parts engineering, consulting, and sales engineering—but you own the code, not just the slides.

What is the salary range for a forward deployed engineer at OpenAI?

Based on public data and levels.fyi, OpenAI FDE roles range from $250K–$450K total compensation, with the upper end including significant equity. Palantir FDEs (where the role originated) typically range from $180K–$300K depending on seniority. AI-native startups are competing aggressively, often offering $200K–$350K with higher equity upside.

What are the key differences between an FDE and a solutions architect?

Solutions Architects design integrations and hand off to implementation teams. They own the architecture, not the code. FDEs write the code, deploy it, and support it in production. An SA says "here's how you should connect these systems." An FDE says "I connected them—here's the working code, the monitoring dashboard, and the runbook." The FDE role is fundamentally an engineering role; the SA role is fundamentally a design and advisory role.

How to become an FDE?

Start by building the toolkit described in this article. Contribute to open-source projects that involve gnarly integrations. Practice taking messy, real-world datasets and making them useful in a UI. The interview loops test for exactly these skills—you'll be asked to debug a broken integration live or design a connector for a deliberately underspecified API. For a complete walkthrough of what to expect, see The FDE Interview Loop: The Complete Preparation Guide for 2026. If you're building your portfolio, focus on projects that demonstrate you can ingest messy data, wrap ugly APIs, and scaffold a demo fast. The FDE Portfolio guide covers specific projects that signal these skills to hiring managers.

How do LLMs change the FDE toolkit?

LLMs accelerate every phase. They generate connector boilerplate for obscure data formats, write wrapper code for poorly documented APIs, and can even scaffold entire demo UIs from a screenshot. But the judgment—knowing which pattern to apply, recognizing when generated code is subtly wrong, understanding the customer's unstated constraints—that's still entirely human. The tools an FDE ships with are increasingly AI-augmented versions of the patterns above, but the core skill remains: shipping working software into messy real-world environments, fast.

---

The tools an FDE ships with aren't products. They're force multipliers. Build them before you need them, refine them after every engagement, and never show up to a customer call empty-handed.