Rapid Prototyping
- Scope a prototype to the one moment that must convince, cutting everything else
- Use wizard-of-oz techniques and honest hardcoding without ever deceiving the customer
- Distinguish prototype code from production code and say out loud which is which
- Climb the prototype→production ladder deliberately, knowing what each rung adds
- Build a working demo against a customer brief inside a hard time limit
| Spaced-rep warm-up: due cards incl. Day 164 scope ladder | 10 min |
| ELI5 + tech read; write the cutting checklist from memory | 10 min |
| Guided: scope-cut drill + build the proto_kit skeleton | 35 min |
| Practice: the ladder audit table | 15 min |
| Project: 45-minute timed build + 5-minute honest notes | 50 min |
| Quiz + flashcards | 10 min |
Builds on: Day 164 — Requirements — the v0 scope ladder · Day 110 — Structured outputs — fast extraction backbones · Day 41 — FastAPI — quick services
A movie trailer is two minutes cut from a two-hour film — except it usually isn't: trailers are often assembled before the film is finished, from the best scenes, sometimes with placeholder music and shots that won't survive the final cut. Nobody calls this fraud, because everyone knows what a trailer IS: a promise of the experience, built to answer one question — "do you want to see this movie?" The sin would be a trailer for scenes that could never be filmed.
An FDE prototype is a trailer. Its job is to answer one question — usually "can the machine really read OUR documents?" or "would this fit OUR workflow?" — in days, not months. So you cut like a trailer editor: the login page is a hardcoded user, the database is a JSON file, six claim types become one, and the "integration with ClaimCore" is a screen that SHOWS what would be written, not a write. The one thing you never fake is the thing being tested: if the question is "can it extract from your PDFs," the extraction must be real, on their real documents. Wizard-of-oz (a human behind the curtain) and hardcoding are honorable tools with one iron rule: the customer always knows which parts are movie and which are trailer.
Speed is the FDE's credibility currency: showing a working slice against the customer's own data within days of discovery changes the conversation from "vendor pitching" to "partner building." But uncontrolled speed creates the twin failure modes that kill engagements: the deceptive demo (faked capability discovered later — trust never recovers) and the eternal prototype (the demo hack quietly becomes production and pages you at 3am — Week 23 taught you what production actually requires). FDE interviews test this directly with timed build exercises; Day 168's simulation includes your demo plan, and Day 174 gives you another timed brief under pressure.
Guided practice
The scope-cut drill: from proposal to 45-minute plan
15 minTake the Harbor & Vane v0 scope from Day 164 (extraction + review screen + exclusion flags). You have 45 minutes of build time and one goal: make Dana lean forward.
- Write the one question this prototype must answer. (Strong answer: "can it really pull the eight fields + exclusion flags from OUR kind of claim documents?" — the OCR pilot failed exactly here, so this is where disbelief lives.)
- Apply the cutting checklist to every FR: what is real, hardcoded, wizard-of-oz, or absent? Produce a two-column table: IN (real) / FAKED-OR-CUT (with the honest label you'll say aloud).
- Sanity-check the IN column: it should be roughly — one sample claim PDF (public/synthetic since you have no real ones — say so), schema-constrained extraction (Day 110 code you already own), a one-page review screen showing fields + confidence + a flagged exclusion, and a visible "would write to ClaimCore" panel that writes nothing.
- Time-box the IN column: minutes per piece, summing to ≤40 with 5 spare. If it doesn't fit, cut again — the discipline is that the timer wins, not the feature list.
Build the skeleton you will reuse forever
20 minEvery timed build starts faster from a skeleton. Assemble yours now from code you already own, into proto_kit/:
extract.py— your Day 110 schema-constrained extraction function, trimmed to take (pdf_text, schema) and return validated fields + confidences.app.py— the starter below: a single-file review screen (FastAPI + inline HTML — swap for Streamlit if you prefer) that renders extracted fields, confidence colors, and an honest SIMULATED banner over the fake parts.fake.py— canned lookups: one customer record, one policy record, clearly named FAKE_POLICY.- Run it end-to-end once on any PDF text. Commit. In every future timed exercise (today's project, Day 174), you start from this kit — assembling proven parts IS the 48-hour-prototype method.
On your own
Ladder audit: what would this cost to make real?
15 minTake the prototype plan from guided work and write the rung-by-rung upgrade bill. For each of five components (intake, extraction, policy lookup, review UI, audit trail): what does rung 2 (pilot) demand that rung 1 lacks, and what does rung 3 (production) add on top? Use Week 23's vocabulary — where do evals, monitoring, fallbacks, secrets handling, and the security questionnaire attach?
Constraints: output is a table, ≤1 line per cell; mark the two components whose prototype code you would fully REWRITE rather than harden (and why — hint: anything wizard-of-oz, and anything whose error handling is a banner).
The point: you can now answer the customer question "so how far is this from production?" with a bill instead of a shrug.
The timed build: 45-minute hard stop
Fresh mini-brief, timer on. Brightgate Property Management (fictional) manages 3,000 rental units; maintenance requests arrive as free-text emails; the dispatcher triages them by hand into urgency (emergency/urgent/routine), trade (plumbing/electrical/HVAC/general), and building. Discovery said the one question is: "can it triage OUR messy emails reliably enough to trust?" Build the trailer: paste 8 realistic maintenance emails you write yourself (make three ambiguous), run real schema-constrained classification with confidence, render a dispatcher screen (color-coded urgency, sorted queue), label anything faked. Hard stop at 45 minutes — commit whatever exists, then spend 5 minutes writing honest notes: what worked, what you cut live, what you would say while demoing the rough edges.
Common mistakes & misconceptions
- Faking the one thing being tested. Hardcode the login, the lookup, the styling — never the core capability the customer is there to judge; a canned "extraction" discovered later ends the engagement.
- Hiding the fakes instead of labeling them. Undisclosed simulation is a trust bomb; a cheerful "this panel is simulated, the extraction is live" is a trust builder.
- Polishing the UI while the core is unproven. Customers forgive ugly screens showing real capability; the reverse impresses no one who matters.
- Letting the prototype crawl into production. Rung 1 code has no evals, no monitoring, no security review — Week 23 is the bill; climbing the ladder must be a decision, not an accident.
- Building without a written one-question. A prototype that tries to answer five questions answers none convincingly and blows the timer.
- Demoing without capturing feedback. The prototype is a discovery instrument; the leaning-in moment and the "actually, we'd need it to…" corrections are the deliverable.
Q1. The customer's doubt is "no tool has ever read our scanned adjuster reports." Which prototype corner may NOT be cut?
Q2. Wizard-of-oz prototyping is legitimate when…
Q3. "How far is this demo from production?" The strongest FDE answer is…
Go deeper — curated resources
- The 48-hour prototype as assembly — Fast builders don't type faster — they own more proven parts. Audit your repos: extraction, RAG query, eval harness, review UI, resilient client. That inventory IS your prototyping speed; grow it deliberately.
- proto_kit committed and runnable end-to-end
- Timed build committed at the hard stop with honest notes
- Ladder audit table names the two rewrite-not-harden components
- Quiz ≥ 2/3
← Back: The extraction backbone is Day 110's structured outputs; the v0 scope you cut from is Day 164's ladder; the production bill you quoted is all of Week 23 — which is why you can now quote it honestly.
Forward →: Tomorrow (Day 167) you wrap this prototype in a demo narrative. Day 168's simulation asks for a demo plan built on today's method, and Day 174's full-cycle sim runs another timed build with objections mid-flight.
Unlocks: D167 Demo Craft