Not all prototypes serve the same purpose. Matching the prototype class to the question you are asking prevents over-investment in disposable artifacts and under-investment in critical explorations.
The Purpose-Directed Prototype
Prototypes exist to answer questions, not to produce artifacts. Before building any prototype, clarify the question you are answering. Different questions require different prototype classes and fidelity levels. Building the wrong fidelity for the question wastes resources or produces misleading answers.
Before building any prototype, ask yourself several essential questions. What question does this prototype answer? What would change if the answer is yes? What would change if the answer is no? Is there a cheaper way to answer this question? These questions ensure you build the right prototype for the right reason.
Prototype Classes
Class 1: Feasibility Prototypes
Feasibility prototypes answer: "Can we do this at all?" They explore technical boundaries and identify unknown unknowns. They require minimum fidelity: enough to determine whether a technical approach is viable.
Characteristics of feasibility prototypes include minimal or absent user interface, core algorithm implementation only without peripheral features, edge cases left unexplored, and the understanding that the prototype can be discarded after use. Investment level remains low at days rather than weeks.
Investment level: Low. Days, not weeks.
QuickShip needed to determine whether they could automatically extract delivery exception reasons from customer emails. They built a minimal feasibility prototype in two days: a Python script that ingested sample emails and outputted extracted reasons using GPT-4. No UI, no error handling, no persistence.
Result: Confirmed that 85% accuracy was achievable with current models. This justified investing in a production system.
Class 2: Desirability Prototypes
Desirability prototypes answer: "Will users want this?" They explore user experience and value proposition. They require moderate fidelity: enough for users to evaluate the core experience.
Characteristics of desirability prototypes include a functional core experience that users can evaluate, mock data being acceptable for testing purposes, secondary flows remaining incomplete, and performance not yet optimized for production. Investment level sits at medium, typically requiring one to two weeks of effort.
Class 3: Viability Prototypes
Viability prototypes answer: "Can we build a business around this?" They explore economic and operational viability. They require higher fidelity: enough to model unit economics and operational requirements.
Characteristics of viability prototypes include complete core flows that demonstrate the full user journey, realistic data volumes that enable economic modeling, basic error handling that prevents obvious failures, and integration points stubbed but not fully connected. Investment level is medium-high, typically requiring two to four weeks.
Class 4: Implementation Prototypes
Implementation prototypes answer: "How should we build this?" They explore architecture and implementation approaches. They produce artifacts that may graduate to production.
Characteristics of implementation prototypes include production-quality core functionality that can ship with minimal changes, secondary flows stubbed or minimal, performance at acceptable levels for production use, and security and observability partially implemented but not complete. Investment level is high, typically requiring four to eight weeks of focused development.
Fidelity Dimensions
Prototype fidelity varies across multiple dimensions. Understanding these dimensions helps you invest appropriately for the prototype class:
Prototype fidelity varies across five key dimensions. In visual design, low fidelity means wireframes and sketches while high fidelity means polished UI with brand elements. In data, low fidelity uses mock data and static responses whereas high fidelity uses realistic data and live connections. In interactions, low fidelity provides clickable mockups with limited flows while high fidelity offers full interactions with edge cases handled. In performance, low fidelity accepts slow response times without optimization, but high fidelity requires production-like performance. In integration, low fidelity uses stubbed and simulated connections while high fidelity uses real integrations.
For each prototype, identify the minimum fidelity that would produce a definitive answer to your question. Invest in fidelity only on the dimensions that affect the answer. Everything else can be low fidelity.
A feasibility prototype testing an algorithm does not need visual polish. A desirability prototype testing user experience needs functional interactions but can use mock data.
Vibe Coding Across Prototype Classes
Vibe coding is most effective for Class 1 and Class 2 prototypes. It can contribute to Class 3 and 4 but requires more careful management to avoid the failure modes discussed earlier.
Vibe coding appropriateness varies by prototype class. Feasibility prototypes show very high appropriateness because they are low risk by definition since they are throwaway artifacts. Desirability prototypes show high appropriateness but require a caution: verify that user reaction is to the concept rather than just the novelty of the AI-generated interface. Viability prototypes show medium appropriateness and require monitoring for architectural drift with planning for refactoring. Implementation prototypes also show medium appropriateness and require architectural guidance; do not rely on vibe alone for production-quality output.
Prototype Graduation
Sometimes a prototype should graduate from one class to another. A feasibility prototype that proves technical viability may deserve investment to become a desirability prototype. Understanding graduation criteria prevents under- and over-investment.
Feasibility to Desirability: Technical approach works; user value proposition is compelling enough to warrant user testing
Desirability to Viability: Users respond positively; economic model is plausible; operational requirements are understood
Viability to Implementation: Unit economics validated; operational processes defined; team ready for production development
The QuickShip Graduation Story
QuickShip's exception handling feature demonstrates prototype graduation:
Week 1 (Feasibility): Python script demonstrated that GPT-4 could extract exception reasons from emails at 85% accuracy. Two days of vibe coding, throwaway code.
Weeks 2-3 (Desirability): Interactive prototype with mock UI showed operations team how the feature would work. Team excitement was high, but this was not real user testing.
Weeks 4-6 (Viability): Working prototype with real email integration and simulated responses. Modeling showed potential for 40% reduction in handling time. Operations team validated the workflow.
Weeks 7-10 (Implementation): Production-quality build with proper error handling, monitoring, and integration with existing systems. This phase required more directive coding and architectural oversight than earlier phases.
Key Takeaways
Prototypes exist to answer questions, so you must match the prototype class and fidelity to the specific question being asked. The four classes are Feasibility, Desirability, Viability, and Implementation, each requiring different investment levels and producing different outputs. Fidelity varies across dimensions including visual design, data, interactions, performance, and integration, so you should apply minimum viable fidelity to each dimension and avoid over-investment. Vibe coding is most effective for Class 1 and 2 prototypes but requires careful management for Class 3 and 4 to avoid the failure modes discussed earlier. Establish clear graduation criteria to determine when prototypes should move between classes and receive appropriate investment levels.
Evaluate a prototype you are currently building or considering by working through several diagnostic steps. First, determine what question this prototype answers, ensuring it has a clear purpose. Second, identify what class it belongs to based on whether it tests feasibility, desirability, viability, or implementation readiness. Third, consider what minimum fidelity would actually answer the question, avoiding over-investment in unnecessary detail. Fourth, assess what fidelity you are currently investing and whether it matches the appropriate level for the class. Fifth, determine what graduation to the next class would require, establishing clear criteria for when and how to escalate investment.
What's Next
In Chapter 11, we explore the AI-Native Prototyping Workflow, examining how to structure the full lifecycle from concept to runnable prototype using vibe coding effectively.