---
# === IDENTITY ===
id: consulting/recipes/mvp-pipeline-build/2026
canonical_question: "How do you build a Signal Stack MVP pipeline in 4 weeks with LLM classification?"
aliases:
  - "Signal Stack MVP pipeline technical build guide"
  - "Automated dossier generation pipeline setup"
  - "How to build a minimal signal-to-dossier pipeline in 4 weeks"
entity_type: execution_recipe
domain: consulting > recipes > MVP Pipeline Build
region: global
jurisdiction: global
temporal_scope: 2026-2027

# === VERIFICATION ===
last_verified: 2026-03-29
confidence: 0.85
version: 1.0
first_published: 2026-03-29

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "Initial release — MVP pipeline build methodology v1.0"
  next_review: 2026-09-25
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "No UI required for MVP — email delivery + PDF dossiers only. UI is scope creep."
  - "Target: functional pipeline in weeks 1-4. If build exceeds 6 weeks, scope is too large."
  - "Human-in-the-loop validation for first 100 dossiers — no fully automated delivery before calibration"
  - "LLM classification must use the validated taxonomy from the workshop — do not improvise classification rules"
  - "Success metric: >2x conversion rate vs cold outreach. Measure from day 1 of delivery."

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs full Signal Stack lifecycle, not just the build"
    use_instead: "consulting/recipes/signal-stack-engagement-playbook/2026"
  - condition: "User needs signal source identification first"
    use_instead: "consulting/recipes/signal-source-audit/2026"
  - condition: "User needs taxonomy design before building"
    use_instead: "consulting/recipes/signal-taxonomy-workshop/2026"
  - condition: "User already has pipeline and needs to run a pilot"
    use_instead: "consulting/recipes/pilot-execution-playbook/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: taxonomy_status
    question: "Is the signal taxonomy validated and ready?"
    type: choice
    options: ["yes — JSON schema available", "partially — draft taxonomy", "no — not started"]
  - key: technical_resource
    question: "Who will build and maintain the pipeline?"
    type: choice
    options: ["internal developer", "consulting team builds it", "freelance developer", "founder (technical)"]
  - key: enrichment_budget
    question: "Monthly budget for enrichment APIs?"
    type: choice
    options: ["$0 (manual only)", "$100-$300/month", "$300-$500/month", "$500+/month"]
  - key: delivery_volume
    question: "Target dossiers per week?"
    type: choice
    options: ["5-10 (proof of concept)", "10-20 (standard pilot)", "20-50 (high volume)", "50+ (scale)"]

# === EXECUTION METADATA ===
execution:
  required_inputs:
    - name: "Validated Signal Taxonomy"
      source: "consulting/recipes/signal-taxonomy-workshop"
      format: "JSON schema"
    - name: "Top data source API credentials"
      source: "client/data-team"
      format: "API keys"
    - name: "Enrichment API credentials"
      source: "client/sales-ops"
      format: "API keys"

  outputs:
    - name: "Deployed Pipeline"
      format: "Python scripts + cron configuration"
      description: "Automated data pull, classification, enrichment, and dossier delivery"
    - name: "Dossier Template"
      format: "PDF template"
      description: "Standardized dossier format with signal evidence, company profile, and recommended action"
    - name: "Monitoring Dashboard"
      format: "spreadsheet or simple dashboard"
      description: "Pipeline health metrics: run success rate, classification counts, delivery stats"

  tools_required:
    - name: "Python 3.10+"
      purpose: "Pipeline orchestration, data processing, API integration"
      tier: "free"
      cost: "$0"
      alternatives: ["Node.js", "Go"]
    - name: "LLM API (Claude or GPT-4)"
      purpose: "Signal classification and dossier narrative generation"
      tier: "paid"
      cost: "$200-$500/month"
      alternatives: ["Claude API", "GPT-4 API", "Local Llama (reduced quality)"]
    - name: "Clearbit or Apollo"
      purpose: "Company and contact enrichment"
      tier: "paid"
      cost: "$99-$499/month"
      alternatives: ["Hunter.io", "ZoomInfo", "LinkedIn Sales Navigator (manual)"]
    - name: "Email service (SendGrid/Resend)"
      purpose: "Dossier delivery with open/click tracking"
      tier: "freemium"
      cost: "$0-$20/month"
      alternatives: ["AWS SES", "Postmark", "manual email"]
    - name: "Cron scheduler"
      purpose: "Automated daily pipeline execution"
      tier: "free"
      cost: "$0"
      alternatives: ["GitHub Actions", "Railway cron", "crontab", "AWS EventBridge"]

  credentials_needed:
    - service: "LLM API"
      type: "API key"
      where_to_get: "https://console.anthropic.com or https://platform.openai.com"
      free_tier_limits: "Budget $200-$500/month for classification + generation"
    - service: "Enrichment API"
      type: "API key"
      where_to_get: "https://clearbit.com or https://apollo.io"
      free_tier_limits: "50-100 lookups/month on free tier"
    - service: "Email service"
      type: "API key"
      where_to_get: "https://sendgrid.com or https://resend.com"
      free_tier_limits: "100 emails/day on free tier"

  estimated_duration: "2-4 weeks"
  estimated_cost: "$5K-$12K (consulting) + $300-$1K/month (APIs)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/consulting/recipes/mvp-pipeline-build/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-29)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "consulting/recipes/signal-taxonomy-workshop/2026"
      label: "Taxonomy required as classifier input"
    - id: "consulting/recipes/signal-source-audit/2026"
      label: "Source audit identifies which APIs to integrate"
  feeds_into:
    - id: "consulting/recipes/pilot-execution-playbook/2026"
      label: "Pipeline feeds into pilot execution"
  related_to:
    - id: "consulting/recipes/signal-stack-engagement-playbook/2026"
      label: "Master playbook — this is Phase 3"

# === SOURCES ===
sources:
  - id: src1
    title: "The Lean Startup"
    author: Ries, E.
    url: https://theleanstartup.com/
    type: industry_report
    published: 2011-09-13
    reliability: authoritative
  - id: src2
    title: "Designing Data-Intensive Applications"
    author: Kleppmann, M.
    url: https://dataintensive.net/
    type: technical_blog
    published: 2017-03-16
    reliability: authoritative
  - id: src3
    title: "Building Microservices"
    author: Newman, S.
    url: https://www.oreilly.com/library/view/building-microservices-2nd/9781492034018/
    type: technical_blog
    published: 2021-08-01
    reliability: high
  - id: src4
    title: "Predictable Revenue"
    author: Ross, A. & Tyler, M.
    url: https://predictablerevenue.com/book
    type: industry_report
    published: 2011-08-01
    reliability: high
  - id: src5
    title: "Site Reliability Engineering — Monitoring"
    author: Beyer, B. et al.
    url: https://sre.google/sre-book/monitoring-distributed-systems/
    type: technical_blog
    published: 2016-03-23
    reliability: authoritative
---

# MVP Pipeline Build

## Purpose

This recipe builds the minimum viable signal intelligence pipeline: a cron-scheduled system that pulls public data from identified sources, classifies signals using the validated taxonomy via LLM, enriches qualifying companies with contact and firmographic data, generates formatted dossiers as PDFs, and delivers them via email with open/click tracking. No UI required. The goal is a functional pipeline in 2-4 weeks that demonstrates >2x conversion improvement over cold outreach. [src1, src4]

## Prerequisites
<!-- Agents: verify ALL prerequisites before executing. Missing prerequisites = failed execution. -->

- [ ] **Validated signal taxonomy** available as JSON schema — classification rules, scoring weights, false positive threshold
- [ ] **API credentials** for top 3-5 data sources identified in the signal audit
- [ ] **Enrichment API** credentials (Clearbit, Apollo, or equivalent) with sufficient monthly quota
- [ ] **Email delivery** service configured (SendGrid, Resend, or equivalent) with domain verification
- [ ] **Technical resource** available for 2-4 weeks of development (Python proficiency required)
- [ ] **Cron hosting** environment ready (VPS, Railway, GitHub Actions, or equivalent)

## Constraints
<!-- Hard rules. Agents: enforce throughout execution. Violating these = broken output or legal risk. -->

- No UI for the MVP. Email delivery + PDF dossiers only. Building a dashboard or web interface is scope creep that delays validation. [src1]
- Target: functional pipeline in weeks 1-4. If the build exceeds 6 weeks, the scope is too large — cut features.
- Human-in-the-loop for first 100 dossiers. No fully automated delivery until classification accuracy is confirmed.
- LLM classification must use the validated taxonomy JSON — do not improvise or modify classification rules without revalidating. [src2]
- Success metric from day 1: track conversion rate of dossier recipients vs cold outreach baseline. [src4]

## Tool Selection Decision

```
Which stack?
├── Python + Claude API (recommended)
│   └── PATH A: Best classification accuracy, strong structured output
├── Python + GPT-4 API
│   └── PATH B: Good accuracy, wider ecosystem
├── Python + local LLM (Llama/Mixtral)
│   └── PATH C: No API costs, lower accuracy, requires GPU
└── Node.js + any LLM API
    └── PATH D: Alternative runtime, same API integration pattern
```

| Path | Stack | Monthly Cost | Classification Quality | Setup Complexity |
|------|-------|-------------|----------------------|-----------------|
| A: Python + Claude | Python, Claude API, Clearbit | $300-$800 | Excellent | Low |
| B: Python + GPT-4 | Python, GPT-4 API, Clearbit | $300-$800 | Good | Low |
| C: Python + Local LLM | Python, Llama/Mixtral, Clearbit | $100-$500 | Adequate | High |
| D: Node.js + any | Node.js, any LLM API, Clearbit | $300-$800 | Varies | Low |

## Execution Flow

### Step 1: Data Ingestion Layer (Week 1)

**Duration**: 3-5 days
**Tool**: Python + requests/httpx + cron

Build the data ingestion module:
- Create API integration scripts for each data source (typically 3-5 sources)
- Implement rate limiting and retry logic per source API constraints
- Store raw data in structured format (JSON files or SQLite for MVP — no database server needed)
- Schedule cron job for daily execution (or appropriate frequency per source refresh rate)
- Add basic logging: timestamp, source, records pulled, errors

Each source integration follows the same pattern: authenticate, query with date filter (only new records since last pull), transform to common schema, store, log. [src2]

**Verify**: Each source integration pulls data successfully for 3 consecutive runs. Error handling catches and logs failures without crashing the pipeline.
**If failed**: If specific API returns errors, check authentication, rate limits, and data format. Common issue: API documentation is outdated — test with curl first.

### Step 2: LLM Classification Module (Week 1-2)

**Duration**: 3-5 days
**Tool**: Python + LLM API (Claude/GPT-4) + taxonomy JSON

Build the classification module:
- Load taxonomy JSON schema (signal hierarchy, scoring weights, threshold)
- For each raw record, construct classification prompt with: record data, taxonomy rules, scoring criteria
- Parse LLM response into structured classification: signal_type, confidence_score, qualifying_signals, disqualifying_signals
- Apply composite scoring formula from taxonomy workshop
- Filter: only records above threshold proceed to enrichment
- Log all classifications for later analysis (true positives, false positives)

Prompt engineering is critical. Structure the prompt to:
1. Present the taxonomy rules as system context
2. Provide the raw record as user input
3. Request structured JSON output with specific fields
4. Include 2-3 few-shot examples from the taxonomy validation dataset [src2]

**Verify**: Classification module processes 100 test records with >70% accuracy vs human judgment. Structured output parsing succeeds on >95% of responses.
**If failed**: If accuracy < 70%, check prompt structure and few-shot examples. Common issue: prompt too vague about what constitutes a qualifying signal.

### Step 3: Enrichment Layer (Week 2)

**Duration**: 2-3 days
**Tool**: Python + Clearbit/Apollo API

Build the enrichment module:
- For each company that passes classification threshold, query enrichment API
- Pull: company name, domain, employee count, industry, location, funding, technology stack
- Pull: contact information for relevant decision-makers (title matching)
- Handle enrichment failures gracefully — partial data is acceptable, missing data is not blocking
- Cache enrichment results to avoid duplicate API calls (LRU cache or simple file-based cache)
- Track enrichment coverage: percentage of classified companies successfully enriched [src3]

**Verify**: Enrichment returns data for >60% of classified companies. Contact information available for >50%.
**If failed**: If coverage < 50%, add secondary enrichment source or fall back to manual LinkedIn lookup for high-priority companies.

### Step 4: Dossier Generation (Week 2-3)

**Duration**: 2-3 days
**Tool**: Python + LLM API + PDF generation (WeasyPrint/ReportLab)

Build the dossier generation module:
- Design PDF template: company header, signal evidence section, enrichment data, recommended action, confidence score
- Use LLM to generate narrative summary: why this company is flagged, what signals triggered, suggested outreach angle
- Populate template with structured data + generated narrative
- Generate PDF file per company
- Include signal evidence with links to source data (so sales team can verify) [src4]

Keep dossiers to 1-2 pages maximum. Sales teams do not read longer documents. Structure for scanability: bold headers, bullet points, clear recommended action at the top.

**Verify**: Sample dossier reviewed by sales team lead. Format is readable, signal evidence is clear, recommended action is actionable.
**If failed**: If feedback is negative, iterate on template with sales team input. Common issue: too much data, not enough actionable insight.

### Step 5: Delivery and Tracking (Week 3)

**Duration**: 2-3 days
**Tool**: Python + SendGrid/Resend API

Build the delivery module:
- Configure email templates (plain text + HTML) with dossier PDF attachment
- Implement delivery scheduling: batch delivery at optimal time (typically 7-9 AM recipient timezone)
- Add open tracking (pixel) and click tracking (wrapped links)
- Implement delivery logging: who received what, when, opens, clicks
- Add unsubscribe mechanism (required for compliance) [src4]

**Verify**: Test emails delivered successfully to 5 test recipients. Open/click tracking functional. PDF attachments render correctly.
**If failed**: If emails land in spam, check domain authentication (SPF, DKIM, DMARC). Common issue: new sending domain lacks reputation.

### Step 6: Pipeline Orchestration and Monitoring (Week 3-4)

**Duration**: 2-3 days
**Tool**: Cron + logging + alerting

Wire all modules together and add monitoring:
- Create master orchestration script: ingest → classify → enrich → generate → deliver
- Schedule via cron (daily or per source refresh rate)
- Add pipeline health monitoring: success/failure counts per module, processing time, error rates
- Set up alerting: email notification if any module fails or if classification count drops below expected range
- Create simple tracking spreadsheet: delivered dossiers, opens, clicks, conversions (manual entry initially) [src5]

**Verify**: Full pipeline runs end-to-end for 3 consecutive days without intervention. Monitoring alerts fire on simulated failures.
**If failed**: If intermittent failures, add retry logic and increase timeout values. If systematic failures, isolate which module is failing and debug in isolation.

## Output Schema

```json
{
  "output_type": "mvp_pipeline",
  "format": "deployed code + documentation",
  "sections": [
    {"name": "ingestion_module", "type": "object", "description": "Data source integrations with cron schedule", "required": true},
    {"name": "classification_module", "type": "object", "description": "LLM-based signal classification with taxonomy", "required": true},
    {"name": "enrichment_module", "type": "object", "description": "Company and contact data enrichment", "required": true},
    {"name": "dossier_generator", "type": "object", "description": "PDF generation with narrative and evidence", "required": true},
    {"name": "delivery_module", "type": "object", "description": "Email delivery with tracking", "required": true},
    {"name": "monitoring", "type": "object", "description": "Pipeline health metrics and alerting", "required": true}
  ],
  "expected_sections": "6",
  "sort_order": "pipeline execution order"
}
```

## Quality Benchmarks

| Quality Metric | Minimum Acceptable | Good | Excellent |
|---------------|-------------------|------|-----------|
| Pipeline uptime (daily runs) | > 90% | > 95% | > 99% |
| Classification accuracy | > 70% | > 80% | > 90% |
| Enrichment coverage | > 60% | > 75% | > 90% |
| Dossier delivery rate | > 95% | > 98% | > 99% |
| Conversion rate vs cold outreach | > 1.5x | > 2x | > 3x |

**If below minimum**: Identify bottleneck module, increase logging detail, and fix before scaling delivery volume.

## Error Handling

| Error | Likely Cause | Recovery Action |
|-------|-------------|----------------|
| Data source API returns 429 | Rate limit exceeded | Implement exponential backoff; reduce query frequency |
| LLM classification returns unparseable output | Prompt format issue or model change | Add output validation; retry with stricter format instructions |
| Enrichment coverage < 50% | Companies too small/private for data providers | Add secondary enrichment source; manual lookup for top prospects |
| Emails landing in spam | Domain reputation or authentication issues | Verify SPF/DKIM/DMARC; warm up sending domain gradually |
| Pipeline fails silently | Insufficient error handling | Add try/catch per module with alerting on any exception |

## Cost Breakdown

| Component | Lean ($5K-$8K) | Standard ($8K-$12K) | Full ($12K-$18K) |
|-----------|----------------|---------------------|-----------------|
| Data ingestion (3-5 sources) | $1.5K-$2.5K | $2.5K-$4K | $4K-$6K |
| LLM classification module | $1K-$1.5K | $1.5K-$2.5K | $2.5K-$4K |
| Enrichment integration | $500-$1K | $1K-$1.5K | $1.5K-$2.5K |
| Dossier generation | $800-$1.2K | $1.2K-$2K | $2K-$3K |
| Delivery + tracking | $500-$800 | $800-$1.2K | $1.2K-$2K |
| Monitoring + orchestration | $500-$800 | $800-$1.2K | $1.2K-$1.5K |
| **Total build** | **$5K-$8K** | **$8K-$12K** | **$12K-$18K** |
| **Monthly running cost** | **$300-$500** | **$500-$1K** | **$1K-$2K** |

## Anti-Patterns

### Wrong: Building a UI before validating the pipeline
Spending 2-4 weeks building a web dashboard before confirming the pipeline produces valuable dossiers. Result: pretty interface delivering worthless content, doubled timeline with no validation. [src1]

### Correct: Email + PDF for MVP, UI only after validation
Deliver dossiers via email attachment. Sales teams already live in email. Add UI only after confirming >2x conversion improvement.

### Wrong: Custom classification rules instead of taxonomy
Skipping the taxonomy workshop and writing ad hoc classification logic. Result: classifier reflects developer assumptions, not domain expertise, producing high false positive rate. [src2]

### Correct: Implement the validated taxonomy exactly
Load the JSON schema from the taxonomy workshop. Use it as-is for LLM classification prompts. Modifications only after revalidation with domain expert.

### Wrong: Overengineering data storage for MVP
Setting up PostgreSQL, Redis, message queues, and microservices for a pipeline that processes 50 records/day. Result: 3x build time, operational complexity that delays validation. [src3]

### Correct: JSON files + SQLite for MVP
Store data in flat files or SQLite. Migrate to proper database only after pipeline is validated and volume justifies the complexity.

## When This Matters

Use when an agent needs to build the technical pipeline that converts identified signals into delivered sales dossiers. This is Phase 3 of the Signal Stack engagement — it implements the taxonomy from the workshop into a functional, automated system. Requires validated taxonomy and data source API access as prerequisites.

## Related Units

- [Signal Stack Engagement Playbook](/consulting/recipes/signal-stack-engagement-playbook/2026)
- [Signal Taxonomy Workshop](/consulting/recipes/signal-taxonomy-workshop/2026)
- [Signal Source Audit](/consulting/recipes/signal-source-audit/2026)
- [Pilot Execution Playbook](/consulting/recipes/pilot-execution-playbook/2026)