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:

| Product Type | Demo Pattern | Example | |---|---|---| | Voice/Communication API | Build an AI agent for the prospect's use case | Appointment scheduler for a healthcare company | | Observability tool | Set up monitoring on a sample app mimicking the prospect's stack | Dashboard showing the metrics they'd care about | | API platform | Build a small integration the prospect would actually need | Connect two tools they use and show data flowing | | Developer tool / SDK | Build a mini-app using the prospect's domain | A prototype feature their customers would use | | Infrastructure / DevOps | Configure a deployment pipeline for their stack | Working CI/CD or infra-as-code for their tech | | Data / Analytics | Build a dashboard or pipeline using their public data | Analysis of their public metrics, app store data, etc. | | Security tool | Run a scan or audit on their public-facing assets | Security report on their website or API | | AI/ML platform | Build a model or agent for their domain | Trained on their public content, solving their problem |

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, the