demo-builder

Demo Builder

Build personalized demo assets for prospects using the founder's product API/MCP/SDK. Send a working prototype that solves the prospect's actual problem — with a comparison report and live demo link.

When to Use

• User provides a prospect company name or URL and wants a demo built for them
• User asks to "build a demo", "create an asset", or "personalize outreach" for a specific company
• User has a product with API access, SDK, MCP server, or CLI and wants to demonstrate it to a prospect
• User has completed a lead generation run and wants to act on the results
• User asks "what do I do with these leads", "how do I reach out", or "help me with outreach"

Prerequisites

• API access, MCP access, SDK, or CLI for the user's product — the agent needs to be able to actually build something
• Access to the product's documentation (API docs URL, SDK readme, or MCP tool list)

Phase 1: Identify the Prospect

This skill supports two input paths:

Path A: User provides a prospect directly (primary path)

If the user provides a company name, website URL, or prospect details:

1. Accept the prospect as-is — no lead data required
2. Proceed directly to Phase 2 (Research the Prospect)

Ask the user:

"I'll build a working demo for [Company]. Before I start, I need to know:

1. What does your product do? (one-liner)
2. What problem does it solve for companies like [Company]?
3. Where are your API docs / SDK / MCP tools?"

If the user has already provided product context (from lead-discovery or prior conversation), skip questions they've already answered.

Path B: User has signal data from prior lead generation runs

If the user has csv outputs from signal skills, help them pick the best prospect:

1. Read the csv outputs and identify top candidates by looking for multi-signal leads, switching signals, build-vs-buy signals, high interaction scores, community pain signals, or company clusters
2. Shortlist 3-5 candidates with signal sources, key signal, and demo feasibility
3. Ask the user to pick one

Either path leads to Phase 2

Only build for ONE prospect initially — this is a trial run to validate the approach before scaling.

Phase 2: Research the Prospect

Step 4: Deep-Dive the Prospect's Business

Research the selected prospect company thoroughly. Use web search, their website, and any data from the signal outputs.

Gather:

1. What the company does — one-liner description, industry, target market
2. Their customers — who do they serve (B2B, B2C, enterprise, SMB)
3. Scale indicators — employee count, funding, customer volume (from website copy like "trusted by X companies" or "X million users")
4. Current tech stack — from job postings, GitHub repos, blog posts, or the signal data itself
5. Pain points relevant to your product — from the signal that surfaced them (the issue they opened, the job they posted, the forum complaint they made, the competitor they're using)
6. Regulatory or compliance needs — especially important for healthcare, fintech, government (e.g., HIPAA, SOC 2, PCI-DSS)
7. Public-facing workflows — how do their customers interact with them today? (website flows, onboarding, support, booking, etc.)

Key sources to check:

• Company website (homepage, about, pricing, customers/case studies pages)
• Job postings (from job-signals data or their careers page) — these reveal priorities and tech stack
• Their GitHub org (if they have one) — reveals what they build and what they use
• The original signal data — the specific issue, post, or job that flagged them
• News/press about the company — recent funding, launches, or initiatives
• LinkedIn company page (for size and industry confirmation)

Present a brief to the user:

"Here's what I found about [Company]. Based on this, here are my ideas for what we could build."

Phase 3: Propose Demo Concepts

Step 5: Generate Demo Ideas

Based on the intersection of (a) what the user's product does and (b) what the prospect needs, propose 2-3 demo concepts.

Framework for generating ideas:

Ask yourself: "If I were a solutions engineer at [user's company] preparing for a meeting with [prospect], what would I build to show them the product solves their specific problem?"

The demo should:

• Solve a real, visible problem the prospect has (not a hypothetical one)
• Use the prospect's actual business context (their company name, their industry terms, their workflows)
• Be functional enough that the prospect can interact with it (not a mockup — a working prototype)
• Be buildable with the user's product API/MCP/SDK in a single session
• Showcase 2-3 key differentiators of the user's product vs. competitors

Common demo patterns by product type:

Present to the user:

DEMO CONCEPT 1: [Name]
  What it does: [2-3 sentences]
  Why it resonates: [connects to the signal that surfaced this prospect]
  Prospect's reaction: [what they'll think when they see this]
  Complexity: [LOW / MEDIUM / HIGH]
  Build time: [rough estimate]

DEMO CONCEPT 2: [Name]
  ...

DEMO CONCEPT 3: [Name]
  ...

Ask:

"Which concept should I build? I'll use your [API/MCP/SDK] to create a working version. Once it's ready, I'll test it and generate a comparison report you can send to [prospect contact name]."

Step 6: User Approves a Concept

Once the user picks a concept, confirm the scope:

"I'll build [concept]. To do this, I need:

1. Access to your API docs at [URL] (or confirm MCP tools are available)
2. Any API keys or credentials I should use
3. Any constraints — features to highlight, competitors to compare against, branding preferences

Anything else I should know before I start building?"

Phase 4: Build the Demo

Step 7: Study the Product's API/SDK/MCP

Before writing any code, thoroughly understand the user's product capabilities.

If the product has API docs:

• Read the API reference — endpoints, authentication, request/response formats
• Identify which endpoints are needed for the demo concept
• Check for rate limits, sandbox/test modes, free tier limits
• Look for quickstart guides or example code

If the product has MCP tools:

• List available MCP tools and their parameters
• Understand which tools chain together for the demo flow
• Check if any tools require specific setup or configuration

If the product has an SDK:

• Read the SDK readme and installation instructions
• Find relevant code examples
• Identify the language and framework to use

Important: Do NOT guess at API behavior. Read the docs. If docs are unclear, ask the user. A broken demo is worse than no demo.

Step 8: Build the Prototype

Build the working demo. The implementation depends entirely on the product type and demo concept.

General principles:

1. Use the prospect's real context — their company name, their industry terms, their specific workflows. "Acme Corp Appointment Scheduler" not "Demo Scheduler."
2. Keep it focused — demonstrate 2-3 capabilities well, not 10 capabilities poorly. The demo should take <5 minutes to understand.
3. Make it interactive — the prospect should be able to try it themselves (a live link, a callable phone number, a shareable dashboard, an API endpoint they can hit).
4. Handle edge cases that matter to the prospect — if they're in healthcare, handle HIPAA-relevant scenarios. If they're in fintech, handle compliance scenarios. Show you understand their world.
5. Include a "wow moment" — one thing in the demo that makes the prospect stop and think "wait, it can do that?" This is what gets the demo forwarded internally.

Save all demo artifacts to .tmp/demos/[prospect-company-name]/

Step 9: Test the Demo

After building, test the demo yourself to verify it works.

Test checklist:

• Does the demo start/load without errors?
• Does it handle the primary use case correctly?
• Does it handle at least 2 edge cases relevant to the prospect's industry?
• Is there anything that could fail or look broken when the prospect tries it?
• Does the interactive element work (link loads, agent responds, dashboard displays)?

If the product supports call/interaction recording:

• Run a test interaction and save the recording
• This becomes part of the deliverable — the prospect can hear/see the demo working before they try it themselves

Document the test results:

TEST RESULTS
  Primary use case: PASS/FAIL — [details]
  Edge case 1 ([describe]): PASS/FAIL — [details]
  Edge case 2 ([describe]): PASS/FAIL — [details]
  Interactive element: WORKING/BROKEN — [details]
  Recording available: YES/NO — [path or link]

Fix any failures before proceeding. If a critical feature is broken and unfixable, discuss with the user before continuing.

Phase 5: Generate the Comparison Report

Step 10: Research Competitors

Content truncated.