neotoma 0.3.0 → 0.3.2

package/docs/releases/archived/aspirational/v1.0.0/marketing_automation_plan.md

@@ -1,291 +0,0 @@
-## Release v1.0.0 — Marketing Automation Plan
-### Purpose
-This document defines the marketing automation system for v1.0.0 that automatically creates content from release data, posts to social media platforms, and measures performance.
-**Related Documents:**
-- `marketing_plan.md` — Marketing overview and coordination
-- `pre_launch_marketing_plan.md` — Pre-launch marketing activities
-- `post_launch_marketing_plan.md` — Post-launch marketing activities
-- `marketing_metrics_plan.md` — Metrics and tracking
-### 1. Automation Overview
-- **Status**: Not implemented (planned for MVP automation via agents)
-- **Strategy**: Agent-based automation for content generation, scheduling, and publishing using AI agents via MCP or direct API integration
-- **Integration**: Agents access Neotoma's marketing data via MCP, generate content, schedule posts, and publish to social platforms
-- **Meta-Use Case**: Using Neotoma's own MCP integration to automate Neotoma's marketing workflow
-### 2. Components
-#### 2.1 Agent-Based Content Generation
-**Purpose**: Use AI agents (via MCP or direct API) to automatically generate marketing content from release data and marketing plans.
-**Agent Architecture**:
-1. **Content Generation Agent** (Claude/ChatGPT via MCP or direct API)
-   - Reads marketing schedule from `pre_launch_marketing_plan.md` and `post_launch_marketing_plan.md`
-   - Reads release data from `release_report.md`, `manifest.yaml`, `status.md`
-   - Generates content drafts based on templates and schedule
-   - Outputs platform-specific formats
-2. **Content Review Agent** (Optional human-in-the-loop)
-   - Reviews generated content for quality and compliance
-   - Approves or requests revisions
-   - Ensures brand voice consistency
-3. **Scheduling Agent**
-   - Reads marketing schedule and timing requirements
-   - Schedules posts for optimal times per platform
-   - Manages timezone-aware scheduling
-**Inputs**:
-- `release_report.md` — Batch completion, feature units, metrics
-- `manifest.yaml` — Release metadata, feature units, dependencies
-- `status.md` — Release status, checkpoints, decision log
-- `marketing_plan.md` — Platform priorities, messaging, timelines
-- `pre_launch_marketing_plan.md` — Weekly content schedule, thread topics
-- `post_launch_marketing_plan.md` — Launch sequence, post-launch schedule
-**Outputs**:
-- Twitter threads (platform-specific format, 5-7 tweets)
-- LinkedIn posts (professional format, 300-500 words)
-- Blog posts (long-form content, 1500-2500 words)
-- Product Hunt descriptions (launch format)
-- Hacker News "Show HN" posts (technical format)
-- Indie Hackers build-in-public posts
-**Agent Instructions**:
-- Follow brand voice guidelines (technical, authentic, privacy-first)
-- Lead with defensible differentiators (privacy-first, deterministic, cross-platform)
-- Use templates from `marketing_plan.md` Section 2.6
-- Maintain consistency across platforms
-- Include relevant CTAs (waitlist links, signup links)
-- Add UTM parameters for tracking
-**Content Templates**:
-- Launch announcement template
-- Feature highlight template
-- Metrics showcase template
-- Technical deep-dive template
-- Build-in-public update template
-- Problem/solution thread template
-**Service Location**: `src/services/marketing_automation.ts` (agent orchestration) + MCP integration
-#### 2.2 Social Media Posting Clients
-**Purpose**: Post generated content to target social media platforms.
-**Platforms**:
-1. **Twitter/X**
-   - API: Twitter API v2
-   - Client: Extend `src/integrations/providers/x.ts` with write capabilities
-   - OAuth: Required (read-only currently, need write permissions)
-   - Format: Threads, single posts, media attachments
-2. **LinkedIn**
-   - API: LinkedIn API
-   - Client: `src/integrations/providers/linkedin.ts` (new)
-   - OAuth: Required
-   - Format: Professional posts, articles
-3. **Product Hunt**
-   - API: Product Hunt API
-   - Client: `src/integrations/providers/product_hunt.ts` (new)
-   - OAuth: Required
-   - Format: Launch submissions, updates
-4. **Hacker News**
-   - API: Hacker News API
-   - Client: `src/integrations/providers/hacker_news.ts` (new)
-   - OAuth: Not required (public API)
-   - Format: "Show HN" posts
-5. **Indie Hackers**
-   - API: Indie Hackers API (if available) or manual posting
-   - Client: Manual or API wrapper
-   - Format: Build-in-public posts
-**OAuth Token Management**:
-- Secure credential storage
-- Token refresh handling
-- Multi-account support (if needed)
-#### 2.3 Agent-Based Marketing Automation Workflow
-**Purpose**: Use agents to orchestrate content generation, scheduling, and posting based on marketing schedule and release lifecycle events.
-**Agent Workflow**:
-1. **Schedule Reading Agent**
-   - Reads `pre_launch_marketing_plan.md` weekly schedule
-   - Identifies upcoming content needs (Twitter threads, blog posts, LinkedIn posts)
-   - Creates content generation tasks for each scheduled item
-2. **Content Generation Agent** (Claude/ChatGPT via MCP)
-   - Receives content task (e.g., "Week -4 Monday: Launch waitlist announcement thread")
-   - Reads relevant release data and marketing context
-   - Generates content draft following templates and brand guidelines
-   - Outputs formatted content (Twitter thread, blog post, etc.)
-3. **Content Review Agent** (Optional)
-   - Reviews generated content
-   - Checks for brand voice consistency
-   - Validates CTAs and links
-   - Approves or requests revisions
-4. **Scheduling Agent**
-   - Reads optimal posting times from marketing plan
-   - Schedules approved content for specific times
-   - Manages timezone-aware scheduling (PST)
-   - Queues content for publishing
-5. **Publishing Agent**
-   - Publishes scheduled content to target platforms
-   - Handles platform-specific formatting
-   - Manages OAuth tokens and API calls
-   - Tracks publishing success/failures
-**Integration Points**:
-- Release orchestrator completion hooks
-- Release status transition triggers
-- Marketing schedule from `pre_launch_marketing_plan.md` and `post_launch_marketing_plan.md`
-- Weekly/daily cron triggers for scheduled content
-**Automated Triggers**:
-**Pre-Launch** (Week -4 to Week 0):
-- **Weekly**: Agent reads schedule, generates content for upcoming week
-- **Week -4 Monday**: Generate waitlist announcement thread → Schedule for Monday 8am PST
-- **Week -4 Wednesday**: Generate technical thread → Schedule for Wednesday 8am PST
-- **Week -4 Friday**: Generate build-in-public update → Schedule for Friday 8am PST
-- **Week -3**: Generate blog post drafts → Schedule for review and publishing
-- **Week -2**: Generate beta launch content → Schedule for beta launch day
-- **Week 0**: Generate launch prep content → Schedule for launch week
-**Post-Launch**:
-- **Day 0**: Agent generates launch announcement content → Schedules per launch sequence
-- **Day 1-7**: Agent generates waitlist conversion content → Schedules email sends
-- **Weekly**: Agent generates organic growth content → Schedules weekly posts
-**Scheduling**:
-- Launch day sequence per `post_launch_marketing_plan.md` timeline
-- Timezone-aware scheduling (PST)
-- Platform-specific optimal posting times:
-  - Twitter/X: 8am PST (Monday, Wednesday, Friday)
-  - LinkedIn: 9am PST (Monday, Thursday)
-  - Blog posts: 12pm PST (publish day)
-  - Indie Hackers: Monday 8am PST
-#### 2.4 Performance Measurement
-**Purpose**: Track engagement metrics and link to signup analytics.
-**Metrics Tracked**:
-- Engagement rate (likes, retweets, shares, comments)
-- Click-through rate (CTR)
-- Signup conversion rate (via UTM tracking)
-- Platform-specific metrics (Product Hunt upvotes, HN points)
-**UTM Parameters**:
-- Source: Platform name (twitter, product_hunt, hacker_news, etc.)
-- Medium: organic, social, referral
-- Campaign: launch_announcement, waitlist_building, organic_growth
-**Reporting**:
-- Real-time metrics dashboard
-- Marketing performance reports (`marketing_performance_report.md`)
-- Comparison: Pre vs post-launch metrics
-- Channel performance analysis
-**Integration**:
-- Signup analytics (link UTM parameters to signups)
-- Usage analytics (link signups to activation)
-- Marketing metrics plan alignment
-### 3. Implementation Plan
-#### Phase 1: Agent-Based Content Generation (MVP)
-**Timeline**: Week -4 to Week 0 (Pre-launch)
-**Tasks**:
-1. **Set up Agent Access**
-   - Configure Claude/ChatGPT access via MCP or direct API
-   - Create agent instructions for content generation
-   - Set up content templates and brand guidelines
-2. **Create Marketing Data Access**
-   - Expose marketing schedule via MCP tools or structured data
-   - Create `marketing_schedule.json` from `pre_launch_marketing_plan.md`
-   - Expose release data (`release_report.md`, `manifest.yaml`) via MCP
-3. **Agent Content Generation**
-   - Use agent to generate content drafts based on schedule
-   - Follow templates and brand guidelines
-   - Output platform-specific formats
-4. **Content Review Workflow**
-   - Human review of generated content (optional but recommended)
-   - Approval/revision workflow
-   - Store approved content for scheduling
-**Dependencies**:
-- Marketing schedule (`pre_launch_marketing_plan.md`)
-- Release data (already exists)
-- Agent access (Claude/ChatGPT access (MCP or API)
-- Content templates and brand guidelines
-**MVP Approach**: Manual agent interaction (use Claude/ChatGPT directly to generate content based on schedule)
-#### Phase 2: Automated Scheduling and Publishing (Post-MVP)
-**Timeline**: Post-MVP (v1.1+)
-**Tasks**:
-1. Create `src/services/marketing_automation.ts`
-2. Implement automated scheduling agent
-3. Implement publishing agent with platform APIs
-4. Test end-to-end automation workflow
-**Dependencies**:
-- Phase 1 complete
-- Platform API credentials
-- OAuth token management
-#### Phase 2: Social Media Posting Clients (Post-MVP)
-**Timeline**: Post-MVP (v1.1+)
-**Tasks**:
-1. Extend `src/integrations/providers/x.ts` with write capabilities
-2. Create LinkedIn provider client
-3. Create Product Hunt provider client
-4. Create Hacker News provider client
-5. Implement OAuth token management
-6. Test posting workflows
-**Dependencies**:
-- Platform API credentials
-- OAuth app setup for each platform
-- Token storage infrastructure
-#### Phase 3: Performance Measurement Integration (Post-MVP)
-**Timeline**: Post-MVP (v1.1+)
-**Tasks**:
-1. Implement engagement metrics collection
-2. Integrate UTM tracking with signup analytics
-3. Create marketing performance reports
-4. Build metrics dashboard
-**Dependencies**:
-- Analytics infrastructure
-- UTM parameter handling
-- Reporting templates
-#### Phase 4: Release Orchestrator Integration (Post-MVP)
-**Timeline**: Post-MVP (v1.1+)
-**Tasks**:
-1. Add marketing automation hooks to release orchestrator
-2. Implement trigger system for release lifecycle events
-3. Integrate scheduled posting
-4. Test end-to-end automation workflow
-**Dependencies**:
-- Phases 1-3 complete
-- Release orchestrator hooks
-- Scheduling infrastructure
-### 4. Technical Requirements
-#### 4.1 Infrastructure
-- **LLM API**: For content generation (OpenAI, Anthropic, etc.)
-- **OAuth Storage**: Secure credential storage (environment variables, secrets manager)
-- **Scheduling**: Cron jobs or task queue for scheduled posting
-- **Analytics**: Integration with signup and usage analytics
-#### 4.2 API Credentials
-**Required**:
-- Twitter API v2 credentials (read + write)
-- LinkedIn API credentials
-- Product Hunt API credentials (if available)
-- Hacker News API (public, no credentials needed)
-**Setup**:
-- OAuth app creation per platform
-- Token refresh handling
-- Multi-environment support (dev, staging, production)
-#### 4.3 Error Handling
-- Failed posting retry logic
-- Content generation fallbacks
-- Rate limiting handling
-- Platform API error recovery
-### 5. Success Criteria
-**Automation Success**:
-- Content generated automatically from release data
-- Posts scheduled and published per timeline
-- Performance metrics collected automatically
-- UTM tracking links signups to marketing channels
-**Quality Criteria**:
-- Content quality matches manual creation
-- Posting success rate ≥95%
-- Metrics accuracy ≥98%
-- Zero manual intervention required for standard workflow
-### 6. Limitations and Manual Overrides
-**Automation Limitations**:
-- Complex messaging may require manual review
-- Platform policy compliance (manual review recommended)
-- Crisis communication (manual override required)
-**Manual Override Points**:
-- Content approval before posting (optional)
-- Emergency stop mechanism
-- Manual posting fallback
-### 7. Related Documents
-- `marketing_plan.md` — Marketing overview and coordination
-- `pre_launch_marketing_plan.md` — Pre-launch marketing activities
-- `post_launch_marketing_plan.md` — Post-launch marketing activities
-- `marketing_metrics_plan.md` — Metrics and tracking
-- `marketing_plan.md` — Marketing overview and coordination
-### 8. Status
-- **Current Status**: Not implemented (planned for post-MVP)
-- **Owner**: Mark Hendrickson
-- **Implementation Guide**: See `marketing_automation_implementation.md` for concrete implementation steps
-- **Next Steps**:
-  1. Complete MVP release (v1.0.0)
-  2. Evaluate manual marketing performance
-  3. Prioritize automation implementation (v1.1+)
-  4. Begin Phase 1 implementation (see implementation guide)

package/docs/releases/archived/aspirational/v1.0.0/marketing_dogfooding_analysis.md

@@ -1,295 +0,0 @@
-# Pre-Launch Marketing for Dogfooding-First Approach: Analysis
-
-**Date**: 2026-01-15  
-**Purpose**: Assess whether pre-launch marketing activities make sense for dogfooding-first approach
-
-## Executive Summary
-
-**Short Answer**: **No, traditional pre-launch marketing doesn't make sense for dogfooding-first approach.**
-
-**However**: **Build-in-public content** (without waitlist/beta) can be valuable for:
-- Authentic storytelling
-- Technical credibility
-- Community engagement
-- Future marketing foundation
-**Additional Constraint**: Developer preview will ship during dogfooding, and discovery is deferred unless preview validation is insufficient.
-
----
-
-## 1. Pre-Launch Marketing Activities (Discovery-First Context)
-
-### Traditional Pre-Launch Marketing (Week -4 to Week 0):
-1. **Waitlist Building** (Week -4 to Week 0)
-   - Goal: ≥100 waitlist signups
-   - Channels: Twitter, LinkedIn, blog, Indie Hackers, Hacker News
-   - CTA: "Join waitlist for early access"
-
-2. **Early Access Beta** (Week -2)
-   - Goal: ≥25 beta participants, ≥70% activation rate
-   - Invite: Discovery participants + top 20 waitlist
-   - Expectation: Working product ready for external users
-
-3. **Content Teasers** (Week -4 to Week 0)
-   - Blog posts, demo videos, Twitter threads
-   - Purpose: Build anticipation, generate awareness
-   - CTA: Join waitlist
-
-4. **Competitor Follower Outreach** (Week -4 to Week 0)
-   - Value-first engagement with competitor users
-   - Goal: Generate waitlist signups
-
-5. **MCP Directory Listings** (Week -3 to Week 0)
-   - Submit to 8+ MCP directories
-   - Goal: Visibility, referral traffic, waitlist signups
-
-**Time Investment**: ~35 hours  
-**Assumption**: Product is ready for external users (or will be by launch)
-
----
-
-## 2. Why Pre-Launch Marketing Doesn't Fit Dogfooding-First
-
-### 2.1 Timing Mismatch
-
-**Pre-Launch Marketing Assumes:**
-- Product is being built for external users
-- External validation has occurred (discovery)
-- Product will be ready for external users by launch
-- Waitlist/beta creates anticipation for known launch date
-
-**Dogfooding-First Reality:**
-- Product is being built for personal use (ateles integration)
-- No external validation yet
-- Product may not be ready for external users until after dogfooding
-- Launch date is uncertain (depends on dogfooding validation)
-
-**Problem**: Building waitlist before you know if product works for yourself creates premature expectations.
-
-### 2.2 Premature Expectations
-
-**Risks of Pre-Launch Marketing in Dogfooding-First:**
-- ❌ **Waitlist signups expect product**: If dogfooding reveals major issues, you can't deliver
-- ❌ **Beta participants expect working product**: If product isn't ready, beta fails
-- ❌ **Public commitment**: Waitlist/beta creates public commitment to launch timeline
-- ❌ **Reputation risk**: If product doesn't work for you, external users will be disappointed
-
-**Example Scenario:**
-- Week -4: Launch waitlist, get 100 signups
-- Week 0-12: Build MVP for ateles integration
-- Week 12: Dogfooding reveals major issues, product doesn't work well
-- **Result**: 100 waitlist signups expecting product, but you can't deliver
-
-### 2.3 Resource Allocation
-
-**Pre-Launch Marketing Time Investment:**
-- Waitlist building: ~10 hours
-- Content creation: ~15 hours (blog posts, Twitter threads, demo video)
-- Beta management: ~5 hours
-- Competitor outreach: ~3 hours
-- MCP directory listings: ~2 hours
-- **Total**: ~35 hours
-
-**Dogfooding-First Priority:**
-- Focus all time on building
-- No time for marketing activities
-- Marketing deferred until after dogfooding validation
-
-**Problem**: Pre-launch marketing diverts time from building.
-
-### 2.4 Authenticity Gap
-
-**Pre-Launch Marketing Message:**
-- "Join the waitlist for Neotoma - a privacy-first truth layer for AI memory"
-- Implies: Product is being built for you (external users)
-- Expectation: Product will be ready for external users
-
-**Dogfooding-First Reality:**
-- "I'm building Neotoma for my own use (ateles integration)"
-- Implies: Product is being built for personal use first
-- Expectation: Product may or may not be ready for external users
-
-**Problem**: Pre-launch marketing message doesn't match dogfooding-first approach.
-
----
-
-## 3. What Makes Sense: Build-in-Public Content
-
-### 3.1 Build-in-Public vs. Pre-Launch Marketing
-
-**Build-in-Public Content** (No Waitlist/Beta):
-- ✅ Share progress, learnings, technical deep-dives
-- ✅ Authentic storytelling: "I'm building this for myself"
-- ✅ No commitment to external launch
-- ✅ No waitlist/beta expectations
-- ✅ Focus on technical content, not marketing
-
-**Pre-Launch Marketing** (With Waitlist/Beta):
-- ❌ Build anticipation for external launch
-- ❌ Create waitlist/beta expectations
-- ❌ Commit to launch timeline
-- ❌ Focus on marketing, not just building
-
-### 3.2 Build-in-Public Activities That Make Sense
-
-**1. Technical Threads (Twitter/X)**
-- "Building Neotoma for my ateles integration - here's what I'm learning about deterministic extraction"
-- "Replacing parquet MCP with Neotoma - MCP integration patterns I'm discovering"
-- "Why I'm building a truth layer instead of using semantic search"
-- **No CTA**: Just sharing learnings, not asking for waitlist signups
-
-**2. Blog Posts (Personal Website)**
-- "Why I'm Building Neotoma: Solving My Own Problem with AI Memory"
-- "Deterministic Extraction: Technical Deep-Dive from Building Neotoma"
-- "MCP Integration Patterns: Lessons from Replacing Parquet MCP"
-- **No CTA**: Just technical content, not marketing
-
-**3. Indie Hackers Build-in-Public Posts**
-- Weekly progress updates
-- Challenges faced, learnings
-- Screenshots, demos
-- **No CTA**: Just sharing journey, not asking for signups
-
-**4. Hacker News "Show HN" (Developer Preview)**
-- Post once developer preview is ready during dogfooding
-- "Show HN: Neotoma - Privacy-first truth layer I built for my ateles integration"
-- **Timing**: During dogfooding with precision disclaimers
-
-**Time Investment**: ~10-15 hours (vs. 35 hours for pre-launch marketing)  
-**Focus**: Technical content, not marketing
-
----
-
-## 4. Marketing Timeline for Dogfooding-First
-
-### 4.1 Recommended Timeline
-
-**Phase 1: Build + Dogfooding (Week 0-12)**
-- Build MVP for ateles integration
-- Dogfooding: Real usage, real validation
-- **Build-in-Public Content**: Share progress, learnings (optional, low time investment)
-- **Developer Preview**: Release during dogfooding once core invariants are stable
-- **No Pre-Launch Marketing**: No waitlist, no beta promises, no formal marketing
-
-**Phase 2: Preview Validation Checkpoint (Week 8-12)**
-- Assess: Does product work for ateles integration?
-- Evaluate: Dependence signal and external feedback quality
-- Decision: Stabilize and expand, or schedule discovery if signals are weak
-
-**Phase 3: Conditional Discovery (If Needed)**
-- Conduct discovery only if preview validation is insufficient
-- Validate market fit, pricing, competitive positioning with working product
-- **Advantage**: Can show working product in interviews
-
-**Phase 4: Post-Preview Marketing (If Proceeding)**
-- Launch waitlist after preview stabilization
-- Launch announcement with developer preview framing
-
-**Total Timeline**: Variable based on preview validation signals
-
-### 4.2 Build-in-Public Content During Dogfooding
-
-**Optional Activities (Low Time Investment):**
-- **Twitter threads**: Share technical learnings (1-2 hours/week)
-- **Blog posts**: Technical deep-dives (2-3 hours/month)
-- **Indie Hackers**: Weekly progress updates (1 hour/week)
-- **No waitlist/beta**: Just sharing, not marketing
-- **Developer preview release**: Announce during dogfooding with precision disclaimers
-
-**Benefits:**
-- ✅ Authentic storytelling
-- ✅ Technical credibility
-- ✅ Community engagement
-- ✅ Foundation for future marketing
-- ✅ Low time investment (~5-10 hours/month)
-
-**Risks:**
-- ❌ May generate interest you can't fulfill yet
-- ❌ People may ask for access before product is ready
-
-**Mitigation:**
-- Be clear: "Building for my own use, not ready for external users yet"
-- No waitlist/beta CTAs
-- Focus on technical content, not product marketing
-
----
-
-## 5. Comparison: Pre-Launch Marketing vs. Build-in-Public
-
-| Aspect | Pre-Launch Marketing | Build-in-Public |
-|--------|---------------------|-----------------|
-| **Timeline** | Week -4 to Week 0 | Ongoing (during build) |
-| **Goal** | Build waitlist, generate anticipation | Share progress, build credibility |
-| **CTA** | "Join waitlist", "Sign up for beta" | None (just sharing) |
-| **Expectation** | Product ready for external users | Product for personal use |
-| **Time Investment** | ~35 hours | ~5-10 hours/month |
-| **Commitment** | High (public launch promise) | Low (just sharing) |
-| **Risk** | High (can't deliver on expectations) | Low (no expectations) |
-| **Authenticity** | Medium (marketing-focused) | High (authentic storytelling) |
-
----
-
-## 6. Recommendation
-
-### For Dogfooding-First Approach:
-
-**❌ Don't Do:**
-- Waitlist building (premature expectations)
-- Early access beta (product not ready for external users)
-- Formal pre-launch marketing (timing mismatch)
-- MCP directory listings (product not ready)
-- Competitor follower outreach with waitlist CTAs
-
-**✅ Do Instead:**
-- **Build-in-Public Content** (optional, low time investment):
-  - Technical threads on Twitter (share learnings)
-  - Blog posts (technical deep-dives)
-  - Indie Hackers progress updates
-  - **No waitlist/beta CTAs**: just sharing
-- **Developer Preview During Dogfooding**:
-  - Release once core invariants are stable
-  - Use precision disclaimers and explicit mutation guarantees
-- **Post-Preview Marketing** (after stabilization):
-  - Launch waitlist after preview validation
-  - Launch announcement with developer preview framing
-
-### Build-in-Public Content Strategy:
-
-**Week 0-12 (During Build):**
-- Share technical learnings (determinism, MCP integration, entity resolution)
-- Share progress updates (screenshots, demos)
-- Share challenges faced, solutions found
-- **Message**: "Building for my own use (ateles integration), here's what I'm learning"
-- **No CTA**: Just sharing, not marketing
-
-**After Preview Validation:**
-- If signals are strong: Stabilize and proceed to post-preview marketing
-- If signals are weak: Schedule discovery and iterate
-
-**Time Investment**: ~5-10 hours/month (vs. 35 hours for pre-launch marketing)
-
----
-
-## 7. Exception: If You're Confident
-
-**If you're highly confident the product will work for external users:**
-- You could do **light pre-launch marketing** (waitlist only, no beta)
-- But this contradicts dogfooding-first approach (uncertainty is the point)
-- **Recommendation**: Stick with build-in-public, defer formal marketing
-
----
-
-## 8. Conclusion
-
-**Pre-Launch Marketing for Dogfooding-First:**
-- ❌ **Doesn't make sense**: Timing mismatch, premature expectations, resource diversion
-- ✅ **Build-in-Public makes sense**: Authentic storytelling, technical credibility, low time investment
-- ✅ **Post-Preview Marketing makes sense**: After preview validation and stabilization
-
-**Recommended Approach:**
-1. **Build + Dogfooding** (Week 0-12): Build-in-public content (optional, low time investment)
-2. **Developer Preview** (during dogfooding): Release once core invariants are stable
-3. **Preview Validation** (Week 8-12): Assess dependence and external feedback quality
-4. **Discovery** (conditional): Only if preview signals are weak or ambiguous
-5. **Post-Preview Marketing**: Launch waitlist and announcement after stabilization
-
-**Key Principle**: Don't create external expectations until you've validated the product works for yourself.