There’s a way of building software that’s unusual in the product engineering tradition and central to FDE work: build, from very early, a running demo of the end-to-end system, and organize every engineering decision around it. Bob McGrew calls it demo-driven development. In early Palantir, the team had one demo, an analyst stopping a terrorist plot, and every feature had to make sense inside that flow.
The pattern looks naive, and it isn’t. A capability-first approach asks what a feature does. A demo-first approach asks what the customer sees, and whether it creates desire. The second question catches a category of design failure the first one reliably misses. For an FDE engagement, the demo is the operating contract, not a marketing artifact: the customer signs off on a flow, the FDE builds against it, validation tests it, and delivery hands it over running on production data.
Start smaller than feels comfortable
The first slice should be the smallest unit of work that makes a complete, end-to-end demonstration. It starts at a customer input and ends at a customer output. It touches every layer the production system will eventually touch, however thinly. It doesn’t have to handle every case; it has to handle one case completely.
Anthropic’s “Building Effective Agents” essay gave the canonical articulation for the agentic era: start with direct API calls and the simplest workflow that works, and reach for an agent only when the path is genuinely unknowable in advance. The reason is failure surface area. A workflow that breaks usually breaks in one identifiable place. An agent that breaks can break anywhere along the path it chose, and in early delivery, identifiable failures are gold.
My own first versions are a literal sequence of API calls in a single file, with no agent framework and no abstractions. The file is ugly, but it’s legible. The customer can read it, the eval set can run against it, and when something goes wrong I can find the line. One contract-review deployment’s entire first slice was three Python files (a sixty-line main, a parsing module, a formatter) plus version-controlled prompts and the eval suite. The customer’s deputy general counsel could read every prompt in fifteen minutes. Within a month, that seed had grown into a fully integrated workflow pulling contracts from the firm’s email and posting memos into its case management system.
Dex Horthy’s 12-Factor Agents captures the disciplines that make a first slice production-ready rather than demo-fragile: own your prompts (version control, read them like code), own your context window (spend it deliberately instead of letting a framework decide), treat tool calls as structured outputs (the testable boundary between the probabilistic and deterministic parts of the system), make state explicit, and design the human-in-the-loop hook from the start. The human can be removed later. The hook has to be designed in from the first commit.
The demo that creates desire
The best slices show the user a familiar problem in a recognizable form, reveal a capability the user didn’t believe was possible, and collapse the time between problem and solution to seconds. That combination is what makes a customer lean forward. In AI engagements the demo has a particular character: real customer data, output in the customer’s own format, the same flow they’d use in production. Realism is expensive. The payoff is that the customer’s objection muscles, trained on years of generic vendor demos, never activate. They’re looking at their own data being processed by software that didn’t exist last week.
Then hand over the keyboard. The customer types the inputs they’d type in their actual work, tries cases you didn’t expect, and breaks things. A customer breaking things in a controlled session is the best outcome available, because it surfaces failure modes while fixing them is cheap, and it convinces the customer the system was built to be honest rather than to be sold. The narrated walkthrough, where the vendor types and the customer watches, produces polite applause and not much else.
When the demo bombs
The first slice fails on customer data more often than anyone admits. The instinct is to apologize, promise a fix, and try to recover the meeting. Resist it. Lean into the failure instead: pull up the prompt, in front of the customer, and ask them what the prompt failed to anticipate about the input. They’ll tell you. The conversation that follows is worth more than a successful demo would have been, because the customer learns the system is built to be debugged in their presence, not pitched at them.
The corollary is a good test of your own posture. If the first demo cannot fail without the engagement falling apart, it isn’t a demo; it’s a sales artifact. Build the demo so it can fail honestly, because that discipline is what produces the system the customer actually wants.
Want the full playbook, with the templates, the interview transcripts, and the week-one checklist? It’s all in my book Forward Deployed AI Engineering: A Working Guide to the Hottest Job in Software, available on Amazon: [Amazon link]