Seven days is enough to answer one question: is this worth building properly? It is not enough to build the thing. Confusing those two goals is why most prototypes waste a month.
Here's the week, day by day.
Day 1 — Write the failure case, not the spec
Before any code, I write two paragraphs: what this does when it works, and what it costs when it's wrong.
The second paragraph determines everything. An AI that drafts internal notes and an AI that sends client emails are architecturally different products even if the model call is identical.
I also write the single question the prototype must answer. Not "does this work" — something falsifiable. Can the model extract line items from a scanned invoice accurately enough that a human reviews rather than retypes?
Day 2 — Build the evaluation set before the product
Twenty to fifty real examples with known correct answers. Real ones — messy, badly scanned, edge-case-ridden. Not the clean samples someone picked for the demo.
This is the day teams skip, and skipping it is why prototypes produce opinions instead of evidence. Without an evaluation set, "it seems pretty good" is your only output, and you'll ship on vibes.
Day 3 — Crudest possible version
An API call and a script. No interface, no database, no auth. Run it against the evaluation set and get a number.
That number is usually either surprisingly good or clearly hopeless. Both are useful. The genuinely ambiguous middle is rarer than people expect.
Day 4 — Attack the failure modes
Sort the failures and look for patterns. Most cluster into two or three categories, and each has a cheap fix worth trying before anything expensive:
- Missing context → retrieval
- Inconsistent formatting → structured output, schema enforcement
- Task too large → decompose into steps
- Genuinely ambiguous input → this is where human-in-the-loop belongs permanently
If prompting and retrieval can't get you to your quality bar by day 4, a stronger model or fine-tuning probably won't close a gap that large either.
Day 5 — The thinnest real interface
Now build the smallest interface a real user can touch. Not the designed product — the crudest thing that lets someone do the actual task without you narrating.
The moment you watch someone use it, you learn things the evaluation set can't tell you: which errors they notice, which they don't, and where they lose trust.
Day 6 — Test with three real users
Three is enough. Sit with them and shut up.
Watch specifically for: do they check the output? Do they know when to check it? What do they do when it's wrong? Do they trust it more or less after twenty minutes?
That last one is the whole prototype. A tool people trust more with use gets adopted. One they trust less gets abandoned, whatever the accuracy number says.
Day 7 — Write the decision
One page: what you learned, the measured accuracy, the failure modes you couldn't fix, what it would cost to build properly, and a recommendation.
Then actually make the call. Build, kill, or run a second week on a specific unknown.
Why hands-on matters here
I can do this in a week because I still write code. Not because writing code is the hard part — because the loop between "I wonder if" and "here's the answer" stays inside my head instead of crossing a handoff.
The speed advantage isn't typing. It's not having to explain the idea before testing it.
The rule
A prototype that produces a confident decision in seven days is worth more than a polished demo that produces enthusiasm in thirty.
Demos generate momentum toward whatever was demoed. Prototypes generate information. Only one of those is useful when the answer might be no.
FAQ
How fast can you build an AI prototype? A week is enough to determine whether an idea is worth building properly, if the goal is a decision rather than a finished product.
What's the most commonly skipped step in AI prototyping? Building an evaluation set of real examples before writing product code. Without it, you get opinions instead of measurements.
How many users do you need to test an AI prototype? Three is usually enough to reveal whether people trust the output and whether they can tell when it's wrong.
What signals that an AI prototype should be killed? Users trusting the output less the more they use it, or failure modes that prompting and retrieval can't reduce within a few days.
I'm Ravi Jadav, Chief Product Officer and Co-Founder at Sunbots Innovations. If you've got an AI idea and want to know whether it's real, get in touch.