Rapid Prototype Synthesizer

Overview

Build working prototypes and demo scripts that let stakeholders experience an AI capability before committing to production. The goal is a 2-day artifact that answers "Can we touch this and see if we want it?"

Core principle: A prototype is not a small production system. It's a demo that proves the concept works. Hardcode aggressively, simulate freely, optimize for "wow" not robustness.

When to Use

•AI capability has passed feasibility evaluation
•Stakeholders want to "see it working" before approving production build
•You have 1-3 days to deliver something tangible
•Decision-makers are non-technical (need demo, not code review)

The Prototype Deliverables

Every prototype produces these 4 artifacts:

dot

digraph deliverables {
    rankdir=TB;
    node [shape=box];

    proto [label="1. Working Code\n(Single file if possible)"];
    demo [label="2. Demo Flow Script\n(Commands + Talking Points)"];
    limits [label="3. Limitations Brief\n(Demo-scoped, not exhaustive)"];
    next [label="4. Next Steps Doc\n(To Pilot, To Production)"];

    proto -> demo [label="enables"];
    demo -> limits [label="references"];
    limits -> next [label="leads to"];
}

Output Format

yaml

prototype_spec:
  name: "[capability-name]-demo"
  purpose: "[One sentence: what this proves]"
  runtime: "[python 3.10+ / node 18+ / etc]"
  dependencies: ["[list actual packages]"]
  setup_time: "[realistic: 5 minutes / 15 minutes]"

code:
  primary_file: "[filename.py]"
  supporting_files: ["[if any]"]
  total_lines: "[estimate]"
  description: "[What the code does in one sentence]"

demo_flow:
  setup_verification:
    - step: "[Verify prerequisite]"
      command: "[command to run]"
      expected: "[what success looks like]"
      if_fails: "[troubleshooting]"

  walkthrough:
    - step: "[Step name]"
      action: "[What to do: run command / show file / open URL]"
      command: "[if applicable]"
      expected_output: |
        [Exact or approximate output stakeholders will see]
      talking_point: "[What to SAY while this runs - for non-technical audience]"
      duration: "[how long this step takes]"

not_needed_for_demo:
  - "[Thing you might think you need but don't]"
  - "[Another scope reduction]"

limitations:
  demo_scope:
    - "[What's hardcoded that would be dynamic in production]"
    - "[What's simulated that would be live]"
  known_failures:
    - "[Input type that breaks it]"
  explicitly_excluded:
    - "[Feature stakeholders might ask about]"

next_steps:
  to_pilot:
    items:
      - "[Specific thing needed]"
      - "[Another specific thing]"
    estimated_effort: "[2-4 weeks]"
  to_production:
    items:
      - "[Production requirement]"
      - "[Another requirement]"
    estimated_effort: "[X-Y weeks]"
  decision_point: "[What stakeholders should decide after seeing demo]"

Prototype Minimalism Principles

DO Hardcode

•API keys (use environment variable, but document clearly)
•Configuration values that would be in a database
•Category lists, templates, reference data
•User/account information for demo scenarios

DO Simulate

•LLM responses (for consistent demo behavior)
•External API calls (mock the response)
•Database operations (use in-memory or file)
•Authentication (bypass for demo)

DO Simplify

•Single file when possible (< 300 lines ideal)
•No frameworks unless essential (Flask? Maybe. Django? No.)
•No database (use dictionaries, JSON files)
•No authentication layer
•No error handling beyond basic try/catch

DON'T Build

•Microservices architecture
•Database schemas
•Comprehensive test suites
•CI/CD pipelines
•Monitoring/logging infrastructure
•Multi-environment configuration

Demo Flow Design

Good Demo Flow Structure

code

1. SETUP (2 min) - Verify environment works
2. CONTEXT (1 min) - Show the input (complaint, document, etc.)
3. MAGIC (30 sec) - Run the AI, show the output
4. VARIATIONS (3 min) - 2-3 different inputs showing capability range
5. BEHIND THE SCENES (2 min, optional) - Show prompt, explain approach
6. NEXT STEPS (1 min) - What would production look like

Each Step Must Include

•Command: Exact thing to type/click
•Expected output: What stakeholders will see
•Talking point: What to SAY (assume non-technical audience)
•Duration: How long this takes
•If fails: What to do if it doesn't work

Common Mistakes

Mistake	Why It's Wrong	Do This Instead
Building Flask app	Overkill for demo	Single Python script with CLI
Database schema	Won't use data anyway	Hardcoded dictionaries
Comprehensive error handling	Demo path is controlled	Basic try/catch, fail gracefully
Test suite	Demo IS the test	Manual verification steps
Multiple config files	Adds complexity	Constants at top of script
Production-like architecture	Confuses scope	One file does one thing
Async/concurrent processing	Demo is sequential	Simple synchronous code

Scope Negotiation

When stakeholders ask "Can you add X?", use this framework:

Request Type	Response
"Add authentication"	"Not for demo - we'll show as if you're already logged in"
"Support multiple languages"	"Not for demo - we'll use English examples. Spanish in pilot."
"Handle edge cases"	"Demo shows happy path. We'll document edge cases in limitations."
"Make it faster"	"Demo shows functionality, not performance. Production will optimize."
"Add logging"	"Not for demo - we'll add observability in pilot phase."

Red Flags in Your Output

If your prototype has these, you're over-engineering:

•Multiple directories / package structure
•requirements.txt with >3 packages
•Database connection code
•Environment-specific configuration
•Abstract base classes
•Dependency injection
•More than one entry point
•README longer than the code

Example: Minimal vs Over-Engineered

Over-Engineered (DON'T)

code

complaint-analyzer/
├── src/
│   ├── __init__.py
│   ├── analyzer/
│   │   ├── __init__.py
│   │   ├── classifier.py
│   │   ├── models.py
│   │   └── prompts.py
│   ├── api/
│   │   ├── __init__.py
│   │   ├── routes.py
│   │   └── schemas.py
│   └── database/
│       ├── __init__.py
│       └── models.py
├── tests/
├── config/
├── requirements.txt
├── Dockerfile
└── docker-compose.yml

Minimal (DO)

code

complaint-demo/
├── demo.py          # Everything in one file
├── README.md        # How to run the demo
└── LIMITATIONS.md   # What this doesn't do

Prototype Quality Checklist

Before delivering prototype:

• Runs with single command (python demo.py)
• No external services required (or clearly simulated)
• Demo flow script has exact commands to run
• Each demo step has talking point for non-technical audience
• Limitations explicitly list what's hardcoded/simulated
• Next steps are specific actions, not vague "add more features"
• Setup verification catches common problems before demo starts
• Total prototype can be understood in 15 minutes of reading