Split View: FDE 플레이북: 버리는 프로토타입으로 이기기

The FDE Playbook: Winning With Throwaway Prototypes

• Introduction — Not Slides, Something That Runs
• Why a Throwaway Prototype
• The Spike: De-Risk First
• Deliberate Tech Debt: Borrow, but Record
• When to Hardcode
• The Shortest Path to the Aha Moment
• Managing Expectations: Say the Demo Is a Demo
• From Prototype to Production
• Anti-Patterns: When to Stop
• Wrapping Up
• References

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.

• Does this technology actually work for this problem?
• Is the customer's data as clean as we assumed, or is it hell?
• Is what the customer truly wants the thing we imagined?
• Is this direction worth investing six months in?

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.

• Time-box it: "We reach a conclusion in two days." A spike must not drag on forever.
• Frame a clear question: Pose a yes/no question — "does this work or not?"
• The output is knowledge: Success buys confidence; failure buys a pivot. Both are wins.

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:

• Record that it's debt: Leave a marker wherever you took a shortcut. When you present the prototype, honestly say "this part is a demo-only stopgap."
• Separate core logic from stopgaps: Put real care into the part that proves the actual value (say, the extraction logic), and cut corners boldly on the periphery (auth, storage, UI).
• Keep it reversible: Leave it clear where to touch when it's time to rip the shortcut out later.

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.

• Auth / permissions: In a demo, the login flow is usually not the value. Just wire in a token.
• Config values: Customer name, thresholds, category lists — bake them into the code for now. Extract to config later.
• Surrounding integrations: Fake the responses of external systems you haven't wired up yet.

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:

• Demo on the customer's data: No matter how well it runs on your sample data, the customer hears it as someone else's story. The moment their own data moves, it becomes their problem.
• Finish exactly one impressive flow: Rather than showing ten features half-baked, polish a single "wow" flow to a smooth finish. A demo is depth, not breadth.
• Win in the first 30 seconds: Attention is short. Don't burn time on login, setup, and onboarding — show the core value the moment it opens.
• Show real results: Not a mockup screen, but genuinely computed output. Customers can smell the difference between real and fake.

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.

• Be clear it's a demo: Say up front, "this is a prototype to show value, and there are a lot of stopgaps behind it."
• Show what's left to production: Present the list of real work the demo hides — error handling, scaling, security, integrations.
• Use the "iceberg" metaphor: The demo is the tip of the iceberg above the water; production is the vast body beneath.

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.

• Keep the core logic, swap the shell: What the prototype genuinely validated is the core value logic (extraction, matching, calculation). Polish and keep that; properly rebuild the auth, storage, UI, and integrations you had hardcoded.
• Pay down the deliberate debt one by one: Using the debt markers you left as a map, replace each stopgap with a real implementation.
• Use the prototype as a spec: The prototype itself is the most accurate spec of "what the customer wants." Even if you rewrite, treat this living spec as the reference.
• Redraw the boundary: Decide here what is bespoke to this one customer and what belongs as a general feature in the product. (The next post digs deep into this topic.)

Anti-Patterns: When to Stop

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

• The demo drags on for weeks: A prototype that should take days but takes weeks is no longer a prototype — it's directionless production.
• You grow attached to throwaway code: If you catch yourself thinking "this is nicely written, shame to toss it," that's a warning. A prototype is only free if you can throw it away.
• It only runs well on fake data: If it collapses on the customer's real data, you haven't validated the risk yet.
• Nobody feels the aha: If the customer shrugs at the demo, the problem or the value hypothesis itself may be wrong.

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

• Spike (Extreme Programming): http://www.extremeprogramming.org/rules/spike.html
• Martin Fowler, "Technical Debt": https://martinfowler.com/bliki/TechnicalDebt.html
• Steve Blank, "Get Out of the Building": https://steveblank.com/
• Palantir, "A Day in the Life of a Forward Deployed Software Engineer": https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
• Paul Graham, "Do Things That Don't Scale": https://paulgraham.com/ds.html