LabHub

Blog

The FDE Playbook: Winning With Throwaway Prototypes

2026-06-30 · 8 min read · #engineering#prototyping#fde

한국어English日本語中文

Introduction — Not Slides, Something That Runs

In the world of the forward deployed engineer (FDE), the most powerful weapon is not a polished deck. It's a prototype that actually runs on the customer's real data. Three minutes of a customer watching their own data move on screen is more persuasive than a hundred-page proposal.

And this prototype has one defining trait: it's built to be thrown away. Not lovingly polished like production code, but assembled fast for the sole purpose of proving value — and once the proof lands, discarded without regret. This post is the playbook for winning with that throwaway prototype.

Why a Throwaway Prototype

To traditional engineering instincts, this approach looks wasteful. Why build something you're going to throw away? The answer is clear: the goal of a prototype is not to leave behind code, but to leave behind learning and conviction.

Think about the questions a few days of prototyping can answer.

No amount of reading documents answers these. Only actually building it does. And once you have the answers, the crude code itself has already done its job.

The Spike: De-Risk First

The agile world has a concept called the spike — a time-boxed, exploratory piece of work that pokes at the area of greatest uncertainty first. An FDE's prototype is, in essence, one giant spike.

The core idea is to validate the riskiest assumption first. If the project is going to fail, where would it fail? Attack that point first.

Take a project like "extract a specific clause from 100,000 of the customer's PDF contracts." The biggest risk isn't the UI or authentication. It's whether the model can correctly pull the clause out of those messy real PDFs. So the UI comes later; first, within days, you run the model over a few hundred real PDFs and check the accuracy. If that doesn't work, nothing else matters.

The rules of a spike are simple.

Deliberate Tech Debt: Borrow, but Record

In a throwaway prototype, technical debt is not a sin but a strategy — as long as it's deliberate.

"Bad debt" is debt you pile up without noticing. "Good debt" is debt you take on with eyes open: "speed matters now, so I'm taking a shortcut here; later, in production, I'll do it properly like this."

The principles for handling deliberate tech debt:

When to Hardcode

In a prototype, hardcoding isn't shameful — it's a powerful technique. The question is where you hardcode.

The principle: everything outside the value you're trying to prove is a candidate for hardcoding.

Conversely, there's one thing you must never hardcode: the heart of the demo, the very value you're proving. If you pre-fill the extraction results by hand in a clause-extraction demo, that's not a demo — it's a con. It has to genuinely work when the customer throws their own document at it on the spot. That moment is the aha moment.

Here's an example expressing this instinct in code. The real value (extraction) actually runs; everything else is shamelessly hardcoded.

# demo_extractor.py — demo prototype (throwaway code)

# [HARDCODE OK] things that are not the value of the demo
DEMO_CUSTOMER = "acme-corp"
FAKE_AUTH_TOKEN = "demo-token-do-not-ship"
TARGET_CLAUSE_TYPES = ["indemnification", "termination", "liability"]

def get_current_user():
    # [DELIBERATE DEBT] the demo only fakes auth. Replace with real OAuth in production.
    return {"org": DEMO_CUSTOMER, "token": FAKE_AUTH_TOKEN}

def extract_clauses(pdf_text: str) -> list[dict]:
    # [REAL VALUE] this part must actually work. Never hardcode.
    # Working on a document the customer throws in live is the heart of the demo.
    prompt = build_extraction_prompt(pdf_text, TARGET_CLAUSE_TYPES)
    response = call_llm(prompt)
    return parse_clauses(response)

def save_results(results: list[dict]) -> None:
    # [DELIBERATE DEBT] demo just writes local JSON. Replace with a DB in production.
    import json, pathlib
    pathlib.Path("demo_output.json").write_text(json.dumps(results, indent=2))

The Shortest Path to the Aha Moment

The goal of FDE prototyping converges on one thing: get the customer to the aha moment as fast as possible. The aha moment is when the customer understands — with their eyes, not their head — "oh, this is how it solves our problem."

A few principles for shortening that distance:

Managing Expectations: Say the Demo Is a Demo

The biggest risk of a throwaway prototype isn't technical — it's misunderstanding. If a demo is too smooth, the customer (and sometimes your own sales team) concludes, "this is basically done, you can ship next week, right?" — even though months separate a few-day demo from production.

So expectation management is the essential other half of prototyping.

Do this well and you keep the demo's impact while dodging unrealistic schedule pressure.

From Prototype to Production

When the demo lands and the deal moves forward, the real question arrives: how do you turn this prototype code into production?

Two common mistakes lurk here. One is shoving the prototype straight into production (the stopgaps stay and become bombs); the other is rewriting everything from scratch (throwing away what you learned). The good answer usually sits in between.

Anti-Patterns: When to Stop

The throwaway prototype turns toxic if misused. Reexamine your approach if you see these signals.

Wrapping Up

FDE prototyping is not the skill of "building sloppily" but of "knowing exactly what to build sloppily." Poke the riskiest assumption first with a spike, shamelessly hardcode everything outside the value, get the customer to the aha moment of their own data by the shortest path, honestly call a demo a demo, and promote only the validated core to production.

The paradox of the throwaway prototype is that precisely because you built something to throw away, you keep the most valuable things — conviction, direction, and the customer's trust. The next post is about how something built for one customer grows into a platform for all of them.

References

Read the original: https://www.youngju.dev/blog/2026-06-30-fde-throwaway-prototypes.en

Comments

No comments yet.

Sign in to leave a comment