How FDEs Turn a Messy Customer Problem into a Shipped Prototype in a Week

Day 0: The Messy Inbound

The Slack message lands on Tuesday at 4:47 PM.

“Hey — Acme Corp says our API is ‘too slow’ for their inventory reconciliation. They’re running a cron job that pulls 2M SKUs nightly and it times out. They’re threatening to churn. Can we fix this by Friday?”

This is the raw material of Forward Deployed Engineering. Not a Jira ticket with acceptance criteria. Not a PRD. A panic-tinged signal from a customer that something is broken, and the implicit demand: make it work, fast.

Most engineers hear “fix the API” and reach for profiling tools. An FDE hears the customer’s actual workflow and asks: what are you really trying to accomplish?

You get on a call. You discover Acme doesn’t actually need all 2M SKUs every night. They need deltas — items whose stock levels changed in the last 24 hours. Your API doesn’t support delta queries. Their workaround is pulling everything and diffing locally. The timeout is a symptom; the root cause is a missing feature masked as a performance complaint.

This is the pivot point. A backend engineer might spend two sprints building a robust delta endpoint. An FDE has until Friday. The job is to ship a prototype that solves the business problem — not to productionize a feature. That distinction defines the entire week.

The 90-Minute Scoping Gauntlet

Before writing a line of code, you run a structured triage. This isn’t requirements gathering — it’s constraint mapping. You’re answering three questions:

1. What is the smallest slice of value we can deliver? Acme needs stock-level changes since midnight UTC. Not historical deltas, not bi-directional sync — just a nightly snapshot of what moved.
2. What is the acceptable failure mode? If the prototype misses a few records, does the warehouse burn down? In this case, no — they have a manual reconciliation fallback. That means eventual consistency is acceptable.
3. What does “done” look like to the customer? Not “endpoint deployed.” Done is “their cron job finishes without timeout and returns correct-enough data.”

The output is a one-pager you send to the customer and your internal AE:

Prototype scope: New endpoint GET /v0/inventory/deltas?since={ISO8601} returning JSON array of {sku, warehouse_id, quantity, updated_at}. Limited to 10K records per call, paginated. No SLA on latency; target <30s for their largest warehouse. Read-only, no write-back.

Out of scope: Historical deltas beyond 7 days. Real-time streaming. Multi-region consistency. Auth changes.

This document is your shield. When the customer asks “can it also handle supplier inventory?” on Thursday, you point to it. Scope creep kills week-long prototypes faster than any technical challenge.

Architecture for Speed: The Prototype Stack

You need a stack that maximizes speed-to-working-software while keeping the door open for productionization. The constraints:

• Must query the existing production database (read-only replica)
• Must not degrade performance for other tenants
• Must be deployable independently
• Should be throwaway-able without leaving scars

Here’s the decision matrix most FDEs internalize:

The flow:

Key decision: no new database, no ETL pipeline, no message queue. The prototype lives entirely within the existing infrastructure’s read path. If it breaks, it breaks alone.

Day 1-3: Building the Happy Path

Day 1: Skeleton and First Light

You scaffold a Cloudflare Worker (or Lambda function URL — pick your poison) and get a single query returning results. Not paginated, not parameterized, just:

SELECT sku, warehouse_id, quantity, updated_at
FROM inventory_snapshots
WHERE updated_at > '2025-01-14T00:00:00Z'
LIMIT 100;

You hardcode the timestamp. You hit it with curl. You get JSON back. This is the morale event — the moment you know the technical thesis holds. You send a Slack message to the customer: “First query working against a snapshot. Seeing 100 rows in 1.2s. On track.”

This message matters. It’s not a status update; it’s trust building. For more on this dynamic, see Building Trust with Non-Technical Stakeholders as a Forward Deployed Engineer.

Day 2: Pagination and Parameterization

You wire the since parameter from the query string, add cursor-based pagination using (updated_at, sku) as the cursor tuple, and cap page size at 10K rows. The code is maybe 80 lines:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const since = url.searchParams.get('since') || new Date(Date.now() - 86400000).toISOString();
    const cursor = url.searchParams.get('cursor');

    let query = `SELECT sku, warehouse_id, quantity, updated_at
                 FROM inventory_snapshots
                 WHERE updated_at > $1`;
    const params = [since];

    if (cursor) {
      const [cursorTs, cursorSku] = cursor.split('|');
      query += ` AND (updated_at, sku) > ($2, $3)`;
      params.push(cursorTs, cursorSku);
    }

    query += ` ORDER BY updated_at, sku LIMIT 10000`;

    const result = await env.DB.prepare(query).bind(...params).all();
    const rows = result.results;
    const nextCursor = rows.length === 10000
      ? `${rows[rows.length - 1].updated_at}|${rows[rows.length - 1].sku}`
      : null;

    return Response.json({ data: rows, next_cursor: nextCursor });
  }
}

You test with their largest warehouse (800K SKUs, ~15K deltas per night). It returns in 8 seconds. You’re under the 30-second target with room to spare.

Day 3: Customer Validation

You ship the Worker to a staging URL and give Acme’s engineer the endpoint. They point their cron job at it. It works on the first try — because you scoped the problem to their actual workflow, not the one they described in the initial complaint.

This is the FDE superpower: What a Forward Deployed Engineer Actually Does in a Week isn’t writing code. It’s collapsing the distance between problem articulation and working software.

Day 4: The Hardening Shift

Day 4 is where prototypes usually die. The happy path works, so the temptation is to declare victory. But the customer runs this at 3 AM. You need to survive reality.

Your hardening checklist:

1. Timeout handling. The Worker has a 30-second CPU limit. If the query runs long, you return a partial result with next_cursor set, plus an HTTP 206 Partial Content. The cron job retries from the cursor.
2. Connection pooling. You configure the Hyperdrive binding (or equivalent) to avoid saturating the read replica’s connection limit.
3. Error alerting. On any unhandled exception, you POST to a Slack webhook. No fancy alerting pipeline — just enough to know if it breaks at 3 AM.
4. Minimal auth. You generate a random 256-bit token, store it as a secret in the Worker, and require it in an X-API-Key header. It’s not OAuth, but it prevents drive-by abuse.
5. Log the right things. Request duration, row count, cursor presence, error stack. Skip PII. You’ll need these logs when the customer asks “did it run last night?”

You deploy to production at 4 PM. You tell the customer to switch their cron job to the prod URL. You stay online until 9 PM their timezone to watch the first run. It completes in 11 seconds. No errors.

Day 5: The Handoff (Not a Demo)

Friday morning. The prototype is running. The customer’s cron job succeeded. The churn threat is neutralized.

Most engineers would schedule a demo and move on. An FDE knows the prototype is technical debt unless it has an owner. The Friday handoff has three artifacts:

1. A one-pager for the product team. What was built, what the customer’s actual need is, why the workaround existed, and what a production-grade version would require. This is the seed of a PRD.
2. A runbook for the on-call team. Where the code lives, what the alert means, how to roll back (delete the Worker), and the customer’s contact info.
3. A technical memo for the platform team. The query pattern, index recommendations, and the observation that a materialized view could make this a 50ms operation instead of 8 seconds.

These documents are the difference between a prototype that becomes a feature and a prototype that becomes a ghost — running in production, maintained by no one, waiting to break. For a deep dive on writing documents that actually get read, see Writing Customer-Facing Technical Docs That Actually Get Read and Used.

Comp and Career Context

Why does this skillset command the compensation it does? FDE roles at companies like Palantir, Scale AI, and Stripe typically range from $150K–$250K base with significant equity, pushing total compensation into the $200K–$400K+ band for senior ICs. The premium exists because FDEs operate at a leverage point few engineers reach: they translate ambiguous customer pain into shipped solutions without the intermediation of product managers, engineering managers, or multi-sprint planning cycles.

The prototype shipped this week didn’t just save a customer. It generated a signal — delta queries are a real need — that product teams might have taken two quarters to discover through roadmap planning. That signal is worth multiples of the engineer’s salary.

For engineers coming from backend or frontend backgrounds looking to develop this skillset, the transition isn’t about learning new technologies. It’s about rewiring your instinct from “how do I build this right?” to “what is the smallest thing I can ship that proves value?” The full transition playbook is at How to Break Into FDE Roles from a Backend or Frontend Background.

FAQ

What are the five stages of a prototype development process?

In the FDE context, the five stages compress into a single week: (1) Problem triage — separating symptoms from root causes through direct customer conversation. (2) Scope definition — writing the one-pager that declares what’s in and what’s out. (3) Happy-path build — getting the core flow working end-to-end with hardcoded values if necessary. (4) Hardening — adding pagination, error handling, auth, and alerting without over-engineering. (5) Handoff — documenting for product, on-call, and platform teams so the prototype has a path to production or a clean death.

What are the steps involved in the prototyping process?

The steps are scoping (90 minutes), skeleton build (Day 1), parameterization and pagination (Day 2), customer validation (Day 3), hardening (Day 4), and documented handoff (Day 5). The key principle: each step produces a working artifact, not a design document. The customer sees progress daily.

How to go from prototype to production?

The handoff artifacts on Day 5 are the bridge. The technical memo should flag the gaps: index additions, connection pooling for multi-tenant safety, proper auth (OAuth or API gateway), monitoring dashboards, and SLA definitions. The product one-pager should frame the feature in terms of the customer’s actual workflow so the PM can prioritize it against the roadmap. The runbook ensures the prototype doesn’t become orphaned operational debt. The most common failure mode is skipping the handoff — the prototype works, everyone celebrates, and six months later it breaks during a database migration because nobody knew it existed.

---

The FDE skillset — rapid scoping, prototype architecture, stakeholder management — is learnable. If you’re an engineer who wants to operate at this intersection of code and customer, FDE Coach builds the muscle memory through real-world scenarios and feedback loops.