From Messy Customer Problem to Shipped Prototype in One Week: An FDE Case Study

The Monday Morning Ambush

It’s 9:04 AM. You haven’t finished your coffee. A Strategic Account Executive (AE) you vaguely recognize is standing at your desk with a look that combines panic and hope. The pitch: “Acme Logistics is about to churn. They say our dashboard is useless for their dispatchers. We need a custom route-optimization view that ingests their legacy on-premise data. Can you fly out Thursday?”

This isn’t a feature request. It’s a rescue mission. The contract is $400K ARR. The customer doesn’t want a roadmap promise; they want to see their own data solving their specific pain point this week. This is the job of a Forward Deployed Engineer (FDE). Not to build the perfect scalable system, but to collapse the time between “impossible ask” and “tangible proof.”

Triaging the Real Problem (Not the Stated One)

You jump on a 30-minute call with the customer’s head dispatcher, Maria. You ignore the AE’s summary. You ask one question: “Walk me through the last time a truck was late and what you did.”

The stated problem was “we need a better dashboard.” The real problem: Maria’s team manually cross-references a CSV export from a legacy AS/400 terminal with a Google Sheet of driver phone numbers, then texts them one-by-one to reroute. The latency is 45 minutes. The cost is spoiled refrigerated cargo.

The FDE heuristic: The customer’s requested solution is almost always a guess. Your job is to diagnose the operational loop that hurts. Here, the loop was: Export CSV → VLOOKUP in Sheets → Manual SMS. The prototype doesn’t need to replace the AS/400. It just needs to automate the VLOOKUP and SMS steps. That’s a one-week scope.

The Architecture Decision: Why a Monolith Won

You have five days. You ignore the internal platform team’s Kubernetes template. You ignore the microservices boilerplate. You need a single Python script, a cron job, and a dead-simple frontend that won’t crash if Maria refreshes it.

Why this stack?

• SQLite: No network calls, no Docker dependency. The prototype runs on a dusty Windows box in the dispatch office if needed.
• Flask + SSE (Server-Sent Events): No WebSocket complexity. Just a unidirectional stream of data to the browser.
• Twilio: No building an SMS gateway from scratch.

The key architectural decision was not integrating with the AS/400 API. Maria’s IT team quoted a 6-week lead time for API access. Instead, you configure the AS/400 to auto-export a CSV to an SFTP folder every 60 seconds. It’s brittle, but it ships.

For more on building pragmatic data pipelines under constraints, the Build an Invoice Extractor That Turns PDF Receipts into Structured JSON case study demonstrates similar file-based ingestion patterns without waiting for perfect APIs.

Day 2-3: Building the Data Spine

The core logic is a 200-line Python script. The heavy lifting is data normalization. The CSV has 47 columns. You only need 4: truck_id, current_lat, current_lng, driver_phone.

import pandas as pd
import sqlite3

def normalize_and_push(csv_path, db_path):
    df = pd.read_csv(csv_path)
    # The customer’s CSV uses "TRUCK_NUM" but sometimes "TruckID"
    col_map = {
        'truck_id': next((c for c in df.columns if 'truck' in c.lower()), None),
        'lat': next((c for c in df.columns if 'lat' in c.lower()), None),
        'lng': next((c for c in df.columns if 'lng' in c.lower()), None),
        'phone': next((c for c in df.columns if 'phone' in c.lower()), None)
    }
    df = df.rename(columns={v: k for k, v in col_map.items() if v})
    
    conn = sqlite3.connect(db_path)
    df[['truck_id','lat','lng','phone']].to_sql('fleet', conn, if_exists='replace', index=False)
    conn.close()

The FDE trap: You could spend 3 days building a robust schema with Alembic migrations. Don’t. The schema will be thrown away if the pilot converts. Write defensive code that handles missing columns, but don’t build for scale. Build for the demo.

Day 4: The Ugly UI That Closed the Deal

You have 8 hours to build the frontend. You use vanilla HTML, a single app.js file, and a CSS framework you know cold (Tailwind via CDN). The UI is a map view with truck pins and a single “Reroute” button per truck.

The critical feature isn’t the map (OpenStreetMap tiles via Leaflet.js). It’s the latency indicator. You add a small timestamp under each truck: “Last seen: 3s ago.” Why? Because Maria’s current process has a 45-minute lag. Showing her 3-second latency is the “aha” moment. It’s not a feature; it’s a narrative.

// Simple SSE listener for real-time updates
const evtSource = new EventSource("/stream");
evSource.onmessage = (event) => {
    const truck = JSON.parse(event.data);
    updateMarker(truck.id, truck.lat, truck.lng, truck.last_seen);
};

This pattern of using lightweight, real-time data push to create immediate user value is explored further in our deep-dive on Context Engineering for Claude 5: How to Structure Prompts When the Model Actually Reads the Docs, where we examine how streaming context transforms user perception of capability.

Day 5: The Silent Demo and the Hard Truth

You fly out. You set up the prototype on a laptop in the dispatch room. You don’t present slides. You ask Maria to sit down and use it. You stand behind her, silent, taking notes.

She clicks “Reroute” on Truck 14. The driver receives an SMS in 1.2 seconds. Maria turns to her boss and says, “This replaces three hours of my afternoon.”

The prototype crashes once during the demo because the AS/400 CSV was empty for a cycle. Your script logged the error and skipped the batch. You point to the log file. Maria’s IT guy nods. It’s not a bug; it’s proof you handled failure gracefully.

The hard truth: You did not ship a product. You shipped a conviction. The customer signed the renewal and a $60K services SOW for you to “productize” the prototype. Your job as an FDE was to convert abstract risk (“we might leave”) into concrete confidence (“this solves my problem”).

For a broader view of how this week fits into the FDE career trajectory, including compensation implications for delivering these outcomes, read FDE Compensation Bands and How to Negotiate: Equity, Base, and Sign-On.

Key Takeaways: The FDE Tempo

1. Diagnose the loop, not the request. Customers describe solutions in the vocabulary they know (dashboards, reports). You must map the actual operational loop and find the highest-leverage 10% to automate.
2. Boring technology wins. SQLite, Flask, and vanilla JS are not impressive on a resume. They are impressive to a customer who sees their problem solved in 5 days without waiting for cloud provisioning.
3. The demo is the discovery. You don’t gather all requirements upfront. You ship a thin slice that touches real data, then sit silently while the user reveals the next problem. The prototype is a question, not an answer.
4. Revenue cures all engineering snobbery. That 200-line Python script directly influenced $460K in revenue. Senior engineers might critique the lack of tests. The CFO and the customer didn’t care.

If you’re coming from a backend background and want to build this muscle for pragmatic, high-speed customer problem solving, our How to Break Into FDE Roles from a Backend or Frontend Background guide provides a structured path to develop these exact skills.

FAQ

What exactly does a Forward Deployed Engineer do differently from a Solutions Architect? Solutions Architects typically design systems and hand off to implementation teams. FDEs write the code, sit with the customer, and ship the initial working integration themselves. The FDE owns the outcome until the customer sees value, not just the diagram.

How do you handle scope creep during a one-week prototype? Ruthlessly. Every request is met with: “I can do that, but it means we drop X. Is that trade-off worth it for Thursday?” The time constraint is not a weakness; it’s a negotiation tool that forces the customer to prioritize their actual pain.

What happens after the prototype ships? If the customer converts, you either hand off to a core engineering team with a detailed write-up of the real-world edge cases you discovered, or you stay on for a paid services engagement to harden the prototype. The prototype code is usually thrown away and rewritten with proper infrastructure, but the data model and operational learnings are the real deliverable.

Do FDEs always work alone? Not always, but the default posture is extreme ownership. You pull in specialists (security, data engineering) for specific unblocking, but you remain the single point of contact and the person who integrates everything. This is why the role requires T-shaped skills: depth in one area, breadth across the stack and the business.