Why Speed Beats Polish in Week One

A prototype shipped in five days does two things a perfect prototype shipped in five weeks cannot. First, it tests the riskiest assumption early — usually "can the model actually handle this domain's real complexity" — while there's still runway to change direction if the answer is no. Second, it converts abstract stakeholder skepticism into concrete, specific feedback: a working thing in front of a person produces reactions like "this misses our edge case with international addresses" instead of vague worry about AI in general.

The trade-off is real: a week-one build will have hacks, hard-coded pieces, and rough edges. That's the correct trade for this stage. The goal isn't to demonstrate engineering craft — it's to test a thesis and generate specific, actionable feedback before the team has invested weeks in the wrong direction.

What Must Be Real

Some things cannot be faked without destroying the value of the exercise: the model's actual output on the customer's actual data. If the prototype's core claim is "the model can classify these support tickets correctly," the classification has to happen live, on real tickets, in front of the room — or at minimum, on a fixed set of real tickets you show the raw output for. A prototype that fakes the one thing it's supposed to prove teaches you nothing and, if discovered, costs you the trust it was meant to build.

What's Fine to Fake

  • The UI — a Streamlit app, a Slack slash command, or a bare command-line script all work fine for proving a thesis. Save the polished frontend for after the thesis is validated.
  • The integration — reading from a CSV export instead of a live API connection is a reasonable stand-in, as long as the data in the CSV is real and representative.
  • The scale — testing against 50 examples instead of the full production volume is fine; scale testing belongs in a later phase, covered in Article 7 on field evaluations.
  • The edge cases — it's acceptable, and honest, to say "we haven't tested against your multilingual tickets yet — that's next week's work" rather than silently avoiding the question.
Disclose the seams

The single rule that keeps rapid prototyping honest: say out loud what's real and what's staged. "This is reading from a static export of last month's tickets, not the live system" costs nothing to say and prevents a stakeholder from over-trusting the demo. Undisclosed shortcuts, once discovered, cost far more trust than the shortcut itself was worth.

Structuring the Demo Itself

A week-one demo works best in three short movements rather than a single long walkthrough: first, restate the problem in the stakeholder's own words from discovery, so the room knows you listened; second, run the model live against two or three real examples, including at least one that's genuinely hard, not just an easy win; third, stop and ask what's wrong with it — inviting criticism explicitly, rather than defending the output, produces the feedback that shapes the next two weeks.

Resist the urge to over-narrate the architecture. Stakeholders in week one care whether the thing works, not how it's built. Save the technical deep-dive for the technical champion in a separate, smaller conversation.

Turning the Demo Into Momentum

The prototype's job doesn't end when the meeting does. Within 24 hours, send a short written follow-up: what was shown, what worked, what didn't, and — most importantly — the two or three specific next steps with owners and rough dates. This does more for stakeholder confidence than the demo itself, because it proves the engagement has a plan, not just a moment of excitement.

Keep a running list of every piece of feedback from the demo, tagged by whether it changes the core thesis or just the execution. Thesis-changing feedback ("this needs to handle a workflow we didn't mention") goes back into a revised scope discussion. Execution feedback ("the tone is too formal") goes straight into the backlog for the next build cycle.

Common Failure Modes

  • Over-engineering week one — spending the whole week on infrastructure that won't matter if the core thesis fails. Build only what's needed to test the riskiest assumption.
  • Cherry-picking every example — a demo that only ever shows the model's best day teaches the room nothing about where the real risk is, and it comes back to bite you when the first hard case surfaces in production.
  • Skipping the ask for criticism — a quiet room after a demo is not agreement, it's politeness. Ask directly what's missing.
  • Treating the prototype as the final architecture — code written to prove a thesis in five days is rarely the code that should run in production; plan to rebuild the parts that matter once the thesis is validated.

Frequently Asked Questions

Is it dishonest to fake parts of a week-one prototype?
Not if you disclose it. Hard-coding a UI flow or using a hand-picked example is a legitimate way to test a thesis quickly, as long as you tell the room what's real and what's staged. The dishonesty is in staying silent about it, not in the shortcut itself.

What if the week-one prototype fails in front of the customer?
Treat it as data, not a crisis. A prototype that fails on a specific real example tells you exactly where the hard part of the problem lives, which is more useful this early than a prototype that happens to succeed on an easy example. Narrate the failure calmly and describe what you'll change.

How rough is too rough for a first demo?
Too rough is when the room can't evaluate the actual thesis because the packaging gets in the way — broken UI, confusing flow, obvious placeholder text where a real answer should be. The bar isn't polish; it's clarity. A command-line script that clearly demonstrates the core capability beats a half-built UI that obscures it.