✏️ From sketch to prototype
In the previous module, you designed the architecture: channels, agents, services, tools. But a design is a promise, not proof. The a prototype is when the promise becomes something that runs — where someone types a message and the system actually responds. Moving from the design to the prototype is when you discover what the paper didn’t tell you.
🛠️ A design proves an idea; a prototype proves reality
The design answers, "Does this make sense?" The prototype answers, "Does this work?" They're different questions—and only the second pays the bills. That's why the architect doesn't fall in love with the perfect blueprint: they hurry to get the smallest version up and running and see how the system responds to a real case.
The prototyper's cycle
Design
The architecture blueprint: what exists and how it communicates.
Prototype
The smallest version that already delivers the main outcome.
Test
A real case goes through the system; reality comes into view.
Iterate
Adjust based on what you saw, then return to the prototype—in a loop.
🌱 Start Small (MVP)
MVP means Minimum Viable Product: the smallest version of the solution that already solves the main problem end to end. Minimal doesn’t mean poorly made — it means lean. You cut everything that would be "nice to have" and keep only the path that delivers the core result. Your Jarvis MVP does one one thing well, not ten things halfway.
✓ A well-scoped MVP
- ✓Solves ONE problem from end to end.
- ✓Start with one channel (e.g., WhatsApp).
- ✓Is ready in hours or a few days.
- ✓Ready to show someone so they can use it.
✗ Bloated MVP (not an MVP)
- ✗Tries to solve everything at once.
- ✗Three channels and five integrations before the first test.
- ✗Takes weeks and is never “finished.”
- ✗Packed with features nobody asked for.
💡 Practical tip
Cut question: "if I remove this, will the system still solve the main problem?". If the answer is yes, remove it from the MVP. Keep the cut list—it becomes the improvement backlog after the prototype proves its value.
🎯 Test with a real case
Testing with a made-up example is easy—and misleading. The prototype only proves anything when it faces a real case: a message a real customer sent, a document that exists at the company, a request as it arrives in everyday work. A real case brings the mess that a clean example hides: slang, typos, and questions that fall outside the script.
A real case entering the prototype
Illustrative recreation of a test—the real case reveals what the clean example never would.
🔎 What to observe in the test
- Did you get the essentials right? The answer solves what the customer wanted.
- Where did it get stuck? At what point the system got lost or guessed.
- Does the tone work? Sounds like how the company would actually speak.
🔄 Iterate Quickly
To iterate is to repeat the cycle test → adjust → test again, in short cycles. The secret isn’t getting it right the first time — it’s shortening the time between spotting a problem and fixing it. Small, frequent cycles beat the big “I’ll fix everything at once” approach: each adjustment is easy to measure and, if it makes things worse, easy to undo.
One (short) iteration cycle
Run a case
Give it a real case and observe the response.
Find ONE problem
Choose the most glaring flaw, not all of them at once.
Adjust one thing
Change only that one thing—an instruction, a rule, an example.
Test again
Confirms that it improved — and starts another round.
💡 Practical tip
Change one thing at a time. If you adjust five things and the result improves, you don't know which adjustment worked—and if it gets worse, you don't know which one caused it. One change per round keeps the learning clear.
⚠️ Common prototype mistakes
Most prototypes don’t die from a lack of technical capability—they die from predictable pitfalls. Knowing the most common mistakes before you make them saves days. Here are the five that most often sink an AI prototype—and the antidote to each.
Antidote: cut it down until only the path that solves the main problem remains.
Antidote: test rough versions first; invest in polish only for what has proven its value.
Antidote: use real, messy cases from the first round.
Antidote: make one change per round so you know what worked.
Antidote: define in advance what counts as "working" (next topic).
💡 Practical tip
The most costly mistake is premature perfectionism: spending days polishing something no one has used yet. An ugly prototype that runs is worth more than a beautiful one that never left the drawing board.
✅ “Works” criteria
"Works" can't be a feeling. Without a clear criterion, you iterate forever or stop too soon. The criterion for "works" is a objective statement, defined before testing, which says what result proves the prototype is ready for the next stage — measuring and evolving. It’s what completes the MVP cycle.
✓ Clear (measurable) criteria
- ✓"Answers 8 out of 10 real questions correctly."
- ✓"Resolve the issue without needing a human."
- ✓"Delivered in under 30 seconds."
- ✓You can answer yes or no, without debate.
✗ Vague criterion (a feeling)
- ✗"Looks good."
- ✗"It's almost there."
- ✗"I think we can show it."
- ✗Depends on who you ask.
🏁 The criterion completes the cycle
With an objective criterion, you know when to stop iterating and move on to Module 3.5 (measuring results). Without one, the prototype either never gets called "ready" or is declared ready too soon. The criterion is the finish line you draw before you start running.
Self-check (optional): what does it mean to start with the MVP?
🛠️ Module summary
Next module:
3.5 — Measure Results: move from “it seems to work” to the numbers that prove its value.