forgetrail 0.3.0

package/docs/DEV_ESTIMATE.md

@@ -0,0 +1,127 @@
+# Development Estimate
+
+Rough estimate of the cost in man-hours to develop [APP NAME] from scratch, based on a full codebase inventory.
+
+**Last updated:** [DATE]
+
+> 💡 **Lesson learned:** This document serves three purposes:
+> 1. **Credibility** — When potential investors, partners, or acquirers ask "how much would this cost to rebuild?", you have a defensible answer.
+> 2. **Scope awareness** — Forces you to inventory every feature area, revealing complexity you've normalized.
+> 3. **Hiring context** — If you ever need to bring on help, this doc scopes the project accurately.
+>
+> Keep this updated as major features ship. The exercise of estimating is as valuable as the numbers.
+
+## How to measure the inventory (recommended)
+
+Use **reproducible commands** so the estimate does not drift silently when someone eyeballs the repo.
+
+> 🔧 **Guidance:** Prefer **tracked source only** (`git ls-files`) so generated artifacts and `node_modules` do not inflate totals.
+
+1. **Application LOC (TypeScript + Svelte/Vue/React as applicable)** — Sum line counts for tracked files under your primary source tree (e.g. `src/**/*.ts` + `src/**/*.svelte`). Loop over paths or use a LOC tool; document the exact glob in the **Last updated** note or a footnote.
+2. **API surface** — Count **route handler modules** your framework uses (e.g. SvelteKit `+server.ts` files under `src/routes`). That number tends to track authorization and test burden better than “REST resources.”
+3. **Server/library modules** — Count `.ts` files under `src/lib/server/` (or equivalent) as a proxy for backend complexity.
+4. **UI inventory** — Count `.svelte` / `.tsx` files; split **panels**, **modals**, **tab subtrees**, and **charts** when possible so effort tables stay explainable.
+5. **Monolithic hotspots** — Note any **very large** single files (LLM orchestration, marketing shell). They inflate LOC without representing even distribution of work; call them out under **Key complexity drivers**.
+
+> 💡 **Lesson learned:** A naive LOC figure without methodology invites skepticism. One sentence on *how* it was counted beats a false-precision single integer.
+
+## Codebase Inventory
+
+| Metric                         | Value |
+| ------------------------------ | ----- |
+| **Estimated Total LOC**        |       |
+| **UI sources**                 |       |
+| **Panels / major shells**      |       |
+| **Modals / dialogs**           |       |
+| **Tab / nested-tab components**|       |
+| **Charts / dashboards**        |       |
+| **API route modules**          |       |
+| **Server library modules**     |       |
+| **Third-party integrations**   |       |
+| **Major feature areas**        |       |
+
+> 💡 **Lesson learned:** Be specific with component counts.
+> "54 components" means less than "20 panels, 5 modals, 22 tab-area pieces, 4 charts." The breakdown reveals where complexity lives.
+
+## Estimated Development Effort
+
+| Area                                                         | Hours | Notes                                                                 |
+| ------------------------------------------------------------ | ----- | --------------------------------------------------------------------- |
+| AI/LLM integration                                           |       | Prompt chains, parsing, guards, regression risk per surface           |
+| UI layer                                                     |       | Shell pages, panels, responsive behavior, design-system consistency      |
+| [Strategic user workflows — e.g. goals / directions]        |       | Optional: multi-step guided flows that anchor tailoring or discovery     |
+| [Prospecting / discovery automation]                         |       | Optional: search orchestration, quotas, empty-state UX                |
+| [In-app assistant / copilot]                                 |       | Optional: runs, steps, streaming, record binding                      |
+| [Demo / staging / anonymization tooling]                     |       | Optional: admin-only pipelines, PII rules, synthetic content           |
+| Document processing (DOCX / PDF / templates / audits)        |       | Structured formats multiply integration hours                           |
+| Auth + OAuth                                                 |       | Providers, sessions, edge cases                                       |
+| Database + data layer                                        |       | Schema, typed client, migrations, file fields                           |
+| Web scraping or external HTML ingestion                      |       | Per-source variance, bot defenses                                     |
+| Payment/billing                                              |       | Checkout, portal, webhooks, entitlements                              |
+| Template or variant systems                                  |       | Optional: alternate document/product variants                         |
+| Domain-specific intelligence (dossiers, research, scoring)   |       | Optional                                                            |
+| Networking / CRM-lite                                        |       | Optional                                                            |
+| Analytics & reporting                                        |       |                                                                      |
+| Delegation / impersonation                                   |       | Optional                                                            |
+| Promo codes / coupons                                        |       | Optional                                                            |
+| Landing + marketing                                          |       |                                                                      |
+| Security audit + hardening                                   |       | Scale notes with **API route module** count                           |
+| Architecture & config                                        |       | Framework wiring, env, observability                                  |
+| Deployment infra                                             |       |                                                                      |
+| Admin / internal tooling                                     |       | Optional                                                            |
+| Design decisions & UX iteration                              |       | Scales with **major feature area** count                             |
+| Testing, debugging, polish                                   |       | Integration paths, failure states                                     |
+| **Total**                                                    |       |                                                                      |
+
+> 💡 **Lesson learned:** The features that take the most hours aren't always
+> the most complex conceptually. They're the ones where integration between systems
+> is unpredictable (e.g., LLM output → structured document formats). When estimating,
+> add 3–5× for anything that bridges AI output with structured formats.
+
+## Iteration density (traditional vs assisted)
+
+> 💡 **Lesson learned:** Headline **hours** are not the same as **iteration count**. Classic teams burn calendar time on compile/fix loops, branch/review cycles, QA bounce-backs, and cross-functional clarification — especially wherever formats, vendors, or auth boundaries meet. Assistants collapse many micro-edit-verify cycles; stakeholders comparing “rebuild cost” should separate **billable engineer-hours** from **calendar-to-ship under a given process**.
+
+> 🔧 **Guidance:** If this doc is used with investors or acquirers, add one sentence on whether totals assume **dense assisted iteration** (fewer human-paced loops) vs **traditional gate-heavy delivery** (often **many more** loops at the same nominal scope).
+
+## Key Complexity Drivers
+
+> 🔧 **Guidance:** List the 3–6 factors that make this project harder than it looks. Examples:
+> 1. **Breadth** — N major feature areas all wired together
+> 2. **AI depth** — N distinct LLM-powered features, each needing prompt engineering
+> 3. **Format manipulation** — Parsing/generating structured documents (DOCX, PDF, etc.)
+> 4. **Multi-source integration** — Each external source has different APIs, rate limits, failure modes
+> 5. **Security surface** — Auth, authorization, IDOR exposure across N **route modules**
+> 6. **Monolithic hotspots** — Few giant files concentrate review and regression risk
+
+1. **[Driver 1]** —
+2. **[Driver 2]** —
+3. **[Driver 3]** —
+
+## Cost Ranges (US market)
+
+> 🔧 **Guidance:** Costs are **[estimated hours] × [loaded rate]** per scenario. Refresh rates yearly; **2026 US senior contract** full-stack often lands **~$150–$225/hr** for established freelancers; **boutique agencies** often quote **~$175–$275/hr** blended; **offshore** blended **~$60–$100/hr** depending on seniority mix.
+>
+> **Fully loaded FTE** includes salary, payroll taxes (~8%), benefits (~20%), equipment — roughly **1.3–1.4×** base salary. Calendar duration ≠ billable rebuild hours.
+
+Rates below use **[TOTAL HOURS RANGE]** from your effort table — replace with your totals.
+
+| Scenario                                            | Rate basis                                  | Estimated cost |
+| --------------------------------------------------- | ------------------------------------------- | -------------- |
+| Senior freelance full-stack dev (contract)          | $150–200/hr × **[TOTAL HOURS RANGE]**       |                |
+| Boutique agency (senior team, US-based)             | $175–250/hr blended × **[TOTAL HOURS RANGE]** |              |
+| Offshore agency (Eastern Europe / LatAm)             | $60–90/hr blended × **[TOTAL HOURS RANGE]** |               |
+| 2-person in-house team (senior FTE + mid FTE)       | Combined annual comp × calendar fraction    |                |
+| Solo in-house senior engineer (FTE, fully loaded)   | Fully loaded annual × calendar fraction     |                |
+
+**Not included:** Model/vendor API spend during development, hosting, payment processor fees, third-party SaaS seats.
+
+## Practical Timelines
+
+Calendars stretch with coordination overhead; compress with parallel roles (frontend + backend + design).
+
+| Scenario                                     | Timeline |
+| -------------------------------------------- | -------- |
+| Solo senior full-stack dev (knows the stack) |        |
+| 2-person team (frontend + backend)           |        |
+| 3-person team with a designer                |        |

package/docs/FORGETRAIL_RENAME.md

@@ -0,0 +1,193 @@
+# ForgeTrail rename and copy guide
+
+**Status:** Name selected. Domain: [forgetrail.dev](https://forgetrail.dev) (live)  
+**Former name:** ForgeKit  
+**Canonical spelling:** `ForgeTrail` (one word, camel case). Folder and CLI form: `forgetrail`.  
+**Related:** [BRAND_AND_PRODUCT.md](BRAND_AND_PRODUCT.md), [README.md](../README.md)
+
+This document is the source of truth for the rename. Use it when changing identifiers, rewriting copy, or updating a project that still says ForgeKit.
+
+---
+
+## 1. What the name means
+
+ForgeTrail is not a tracking or logging product. It is a **persistent development system for building software with AI agents**.
+
+**Trail** is the right word because it names several things the system does at once:
+
+- the **path** through the development lifecycle
+- the **record** of where the project has been
+- **decisions and gotchas** left behind
+- **breadcrumbs** for resuming work
+- **lessons** that future projects can follow
+- the act of **blazing a better trail** through AI-native development
+
+The distinctive feature is not merely workflow. The work leaves behind **structured knowledge** that improves what comes next. A loop describes a mechanism. A trail describes the **artifact of accumulated experience**.
+
+### Double reading (keep this)
+
+`Forge` works two ways, and both are useful:
+
+| Reading | Sense | Use in copy |
+|---------|--------|-------------|
+| **Noun** | Forge Trail: the path, record, or methodology left by the work | "Keep the trail." "The development trail." |
+| **Verb** | forge a trail: create a new path forward | "Forge the path." Agents and developers forge a trail through a project while preserving the trail behind them. |
+
+Word order matters. **ForgeTrail**, not TrailForge. ForgeTrail reads as the trail associated with the forge, and as the verb phrase *forge a trail*. TrailForge sounds like a tool that manufactures trails.
+
+Someone seeing the name with zero context will not immediately know it is developer infrastructure. That is acceptable. The **descriptor** does that job. Once the concept is explained, the name gets richer. That is a good sign.
+
+---
+
+## 2. Category first, metaphor second
+
+**Caution:** "trail" can sound like project tracking, audit logs, or observability. The first subtitle or sentence must establish the category.
+
+**Do this:** name + category line, then let "trail" deepen.
+
+```
+ForgeTrail
+A persistent development system for building software with AI agents.
+```
+
+**Then** the name earns its meaning: the path forward, the decisions made, the lessons learned, and the durable record left behind.
+
+**Do not** lead with trail-as-log, trail-as-ticket-tracker, or trail-as-observability. Those readings are the failure mode.
+
+---
+
+## 3. Signature lines
+
+Use these. Prefer the first when you need one line that teaches the name.
+
+| Line | When to use |
+|------|-------------|
+| **Forge the path. Keep the trail.** | Default tagline. Gives the name meaning almost instantly. |
+| **A persistent development system for building software with AI agents.** | Category subtitle. Use under the name on first contact (landing, README hero, About). |
+| **A persistent development trail for AI-native software.** | When the reader already knows it is a dev system and you want the metaphor. |
+| **Build. Learn. Leave a better trail.** | Learning-loop emphasis. The work improves what comes next. |
+| **Build with AI. Preserve what you learn.** | Product-oriented, less metaphorical. Good for skeptical or enterprise readers. |
+| **The development trail for AI-native software.** | Short category + metaphor in one line. |
+
+Do not invent a new tagline for a one-off surface if one of these fits.
+
+---
+
+## 4. Copy principles
+
+### What to emphasize
+
+- **Persistence:** phase state, decisions, and gotchas live in the repo, not in a chat.
+- **Resume:** breadcrumbs so the next session continues the same trail.
+- **Compounding:** lessons leave the project and improve the next one.
+- **Path + record:** forward motion and the history behind it, together.
+- **Structured knowledge:** not a diary, not a log dump. Decisions, gotchas, and playbooks others can follow.
+
+### What to de-emphasize or avoid
+
+| Avoid | Why | Prefer |
+|-------|-----|--------|
+| "kit", "toolbox", "starter pack" as the product identity | Old name energy. Undersells the durable record. | system, playbook, trail, methodology |
+| "loop" as the hero metaphor | Loop is the mechanism. Trail is the artifact. | trail, record, path, lessons left behind |
+| "tracking", "logging", "observability", "audit trail" as the first frame | Sounds like a monitoring product. | development system, lifecycle, persistent record |
+| Hedging *can* on shipped capabilities | Weakens a direct product voice. | Direct verbs: keeps, leaves, preserves, strengthens |
+| Explaining the name before the product | Adds friction. | Category line first; the name then clicks |
+
+### Voice for the rename
+
+- Direct. Outcome-oriented. US English.
+- State what the product **does**, not what it can do.
+- No em dashes in user-facing copy.
+- "ForgeTrail" in prose. Backticks for identifiers: `` `.forgetrail/` ``, `` `forgetrail` ``.
+
+### Phrase swaps (old → new)
+
+| Old habit | New habit |
+|-----------|-----------|
+| ForgeTrail keeps phase state | ForgeTrail keeps the trail: phase state, decisions, and gotchas |
+| feed lessons back into the kit | leave lessons on the trail / feed lessons back so the next project starts smarter |
+| remember decisions across sessions | keep the trail of decisions across sessions |
+| compounding loop | compounding trail / leave a better trail |
+| the kit | ForgeTrail, the trail, or the system (pick one; do not say "the kit") |
+| Try ForgeKit | Try ForgeTrail |
+| ForgeKit Lite | ForgeTrail Lite |
+| `_forgekit/` vendored tree | `_forgetrail/` vendored tree |
+| `.forgekit/` workspace | `.forgetrail/` workspace |
+
+---
+
+## 5. Identifier map
+
+Use this table for mechanical renames. Do not leave mixed old/new identifiers in a consumer project.
+
+| Kind | Old | New |
+|------|-----|-----|
+| Product name | ForgeKit | ForgeTrail |
+| Domain | (none owned) | forgetrail.dev |
+| CLI / npm bin | `forgekit` | `forgetrail` |
+| Package | `forgekit`, `forgekit-mcp` | `forgetrail`, `forgetrail-mcp` |
+| MCP server key | `forgekit` | `forgetrail` |
+| Env | `FORGEKIT_ROOT`, `FORGEKIT_TARGET`, `FORGEKIT_TEMPLATE_DEFAULT_MODE` | `FORGETRAIL_ROOT`, `FORGETRAIL_TARGET`, `FORGETRAIL_TEMPLATE_DEFAULT_MODE` |
+| App workspace | `.forgekit/` | `.forgetrail/` |
+| Vendored tree | `_forgekit/` | `_forgetrail/` |
+| Lite file | `FORGEKIT_LITE.md` | `FORGETRAIL_LITE.md` |
+| Progress doc | `FORGEKIT_PROGRESS.md` | `FORGETRAIL_PROGRESS.md` |
+| Skill | `content/skills/forgekit/` | `content/skills/forgetrail/` |
+| Cursor rules | `forgekit-*.mdc` | `forgetrail-*.mdc` |
+| MCP tools | `getForgeKitLite`, `getForgeKitSkill`, … | `getForgeTrailLite`, `getForgeTrailSkill`, … |
+| pnpm scripts | `forgekit:status`, `install:forgekit` | `forgetrail:status`, `install:forgetrail` |
+| GitHub slug | `Catalyst-Forge-LLC/forge-kit` | `Catalyst-Forge-LLC/forgetrail` (old URL redirects) |
+
+**Leave unchanged:**
+
+- Historical dates and quotations that are explicitly about the former name (say "formerly ForgeKit" once, then use ForgeTrail)
+- The archive remote `Catalyst-Forge-LLC/forge-kit-original` if you still keep a private snapshot
+
+When you mention the old name, do it once as provenance, not as a parallel brand.
+
+---
+
+## 6. Surfaces to update (checklist)
+
+Run this list for the methodology repo and for every consumer project.
+
+- [ ] README / landing hero: name, tagline, category line
+- [ ] Try path, Lite file, kickoff and resume prompts
+- [ ] MCP server name, tool names, env vars, `mcp.json`
+- [ ] CLI bin, install scripts, package.json
+- [ ] `.forgetrail/` (rename the directory, not only the strings)
+- [ ] Cursor rules and skill filenames
+- [ ] Spec titles and `specs/README.md` links
+- [ ] Issue templates and GitHub links that embed the old file name
+- [ ] Sibling / dependent repos that copy Lite, rules, or scripts
+- [ ] In-app or site listings that describe this product
+
+After a copy pass, grep for `ForgeKit`, `forgekit`, `FORGEKIT`, `.forgekit`, `_forgekit`, and `forge-kit` (except explicit former-name provenance and the archive remote).
+
+---
+
+## 7. Worked examples
+
+**README open:**
+
+> **ForgeTrail**  
+> Forge the path. Keep the trail.  
+>  
+> A persistent development system for building software with AI agents.  
+> ForgeTrail gives solo developers and small teams a 7-phase playbook so agents plan before they build, keep the trail of decisions across sessions, and leave structured knowledge that improves the next project.
+
+**Why it works:**
+
+> Most AI chats forget. ForgeTrail keeps **phase state**, **decisions**, and **gotchas** in the repo, and leaves a trail of lessons that the next build can follow.
+
+**Site listing:**
+
+> ForgeTrail  
+> A persistent development system for building software with AI agents.  
+> Most AI coding sessions forget everything the moment you close the tab. ForgeTrail keeps the phase you are in, the decisions you made, and the gotchas you hit inside the repo, so the next session picks up the trail.
+
+**Do not write:**
+
+> ForgeTrail is a project-tracking trail for your logs.  
+> ForgeTrail can help agents remember things.  
+> TrailForge keeps an audit trail of development.

package/docs/IDEAS.md

@@ -0,0 +1,19 @@
+# [App Name] - Raw Ideas
+
+_These are raw ideas that need to be processed into a proper TODO entry. Check it off here once accounted for in the TODO._
+
+_For bug reports (things that are broken NOW), use [BUGS.md](BUGS.md) instead. IDEAS.md is for future possibilities; BUGS.md is for current problems._
+
+_Instructions: Dump ideas here as they come up during development. Don't filter or organize, just capture. Periodically (during Phase 6: Strategic Review, or whenever the list gets long), process each idea: evaluate it, create a TODO entry if it's worth building, and check it off here with a note about where it landed._
+
+> � **Guidance:** Format:
+> - [ ] Raw idea as it occurred to you
+> - [x] Processed idea → Added to TODO > [Section] > [Item name]
+> - [x] Evaluated and rejected → [brief reason]
+>
+> 💡 **Lesson learned:** The checkbox + mapping pattern creates accountability and prevents "idea debt" (a growing list of unprocessed ideas that creates anxiety without producing action). When processing, be willing to reject ideas. Not every idea deserves a TODO entry.
+>
+> 💡 **Lesson learned:** Keep ideas and bugs in separate files. IDEAS.md is low-urgency (evaluated in batches during strategic review). BUGS.md is higher-urgency (triaged as discovered). Mixing them causes bugs to get buried under ideas, or ideas to feel like emergencies. If something is broken, it goes in BUGS.md. If something could be better, it goes here.
+
+- [ ] [idea]
+- [ ] [idea]

package/docs/MARKETING_GROWTH.md

@@ -0,0 +1,301 @@
+# [APP NAME] — Growth Plan
+
+_Post-launch growth strategy. This plan activates after initial traction confirms product-market fit._
+
+> 💡 **Lesson learned:** Separate launch marketing from growth marketing.
+> Launch is about getting the first 50-100 users through personal outreach and hustle.
+> Growth is about scalable channels that work without you personally in the loop.
+> Don't spend money on growth channels until organic traction confirms product-market fit.
+
+---
+
+## Prerequisites
+
+This plan activates after launch has established:
+
+- [N]+ paying users with [N]+ testimonials from target persona
+- At least [N] active referral partners/affiliates (if applicable)
+- A proven organic channel generating measurable signups
+- Clear signal on which messaging resonates
+
+Do not spend money on growth channels until organic traction confirms product-market fit.
+
+---
+
+## Competitive intelligence: paid social screenshots (optional)
+
+> 🔧 **Guidance:** Use this when competitors in your category run heavy **paid social** (Meta, LinkedIn, TikTok, etc.) and you need grounded positioning — not guesswork.
+
+**Pattern:**
+
+1. **Archive a dated corpus** — e.g. `screenshots/ads/` with mobile/desktop captures and rough date range in a README or spec header.
+2. **Pair with a project prompt** — instructions for an agent to read each image, extract brand, headline, CTA, **numeric claims**, and assign each ad to a **small taxonomy** (e.g. automation-at-scale vs. coaching vs. agency vs. lead-magnet quiz vs. contrarian teardown).
+3. **Write a landscape spec** — what narratives are saturating the feed, what your product already displaces, what is **honest whitespace** for the roadmap, and a **copy guardrail list** (patterns to avoid echoing in your own marketing — unsourced statistics, guaranteed outcomes, superiority tropes your ICP distrusts).
+4. **Feed outputs into** `BRAND_AND_PRODUCT.md`, FAQ, and in-app tips — without treating competitor hype as fact.
+5. **Optional: stakeholder-facing mirror in `docs/`** — If the full analysis lives under `specs/` (long tables, screenshot inventory), add a **`docs/COMPETITIVE_LANDSCAPE.md`** (or similar) that stays **synced** from the spec via a tiny script + `pnpm` script. Rewrite relative links when the output file sits in a different folder. Instruct your competitive-review prompt (and humans) to **update the spec and re-run sync** so founders and marketing read `docs/` without forking content by hand.
+
+**Why:** Scroll-feed creative shows what buyers are being trained to expect. You differentiate more clearly when you name those narratives and consciously **don't** recycle their weakest tactics.
+
+> 💡 **Lesson learned:** Re-run the review when you add a batch of new screenshots; append to the spec or version the summary so positioning stays current as ad land shifts.
+
+---
+
+## In-product education (contextual tips)
+
+> 🔧 **Guidance:** Competitive and positioning research often yields **high-signal, low-hype** lessons (e.g. precision over volume, when to use automation vs judgment). Those belong in **`BRAND_AND_PRODUCT.md`** and landing copy — and can also ship **inside the product** so active users benefit.
+
+**Pattern:**
+
+- **Contextual tips:** Short messages when a surface is empty, first-time, or after a key action; **dismiss** with optional per-tip expiry stored server-side or in `localStorage` so power users aren’t nagged.
+- **Cadence surface:** A weekly digest or in-app summary can rotate tips plus **next suggested actions** without turning the product into a course.
+- **Tone:** Factual and calm; never import competitor **fear or unverifiable stats** from ad creative. Cross-check new tip copy against your **“fluff to avoid”** list from the competitive spec.
+
+**Why:** Educated users get more value from the same features; in-app education is how positioning survives after signup.
+
+---
+
+## Personal Beta Outreach (Pre-Launch / Launch)
+
+> 💡 **Lesson learned:** Personal network outreach is the highest-converting launch channel, but a single generic message wastes goodwill. The fix is **relationship-warmth buckets** (not job titles) that control tone, length, and offer. Six primary buckets cover most networks: Inner circle (A), Strong professional (B), Warm acquaintance (C), Light/casual (D), **Alumni / former org (E)** when shared employer, program, or cohort **anchors** the message, and Connector (F). Classify on **how the message would land today**, not historical closeness or the person's prestige.
+
+**Key patterns:**
+
+- **Shared skeleton, varied execution:** Every message follows the same 5-part spine (opener, product sentence, beta ask, optional promo, easy out), but the weight of each part shifts by bucket. A is shortest; C is often longest; **E** flexes with how warm the tie is.
+- **Product one-liner variants:** Write 4 phrasings of your product in one sentence (full value stack, short/text-friendly, latent-user angle, positioning angle). Use different ones across messages so recipients who compare notes don't see the same rehearsed pitch.
+- **AI-tell checklist:** Before sending, scan for sincerity adverbs ("genuinely"), filler openings ("I wanted to reach out"), repeated flattery formulas, identical value-stack lists across messages, three-part feedback requests, brand-doc copy leaking into personal messages, and structural parallelism across buckets. These are consistent tells that recipients recognize as template-generated.
+- **Promo code per bucket:** One distinct code per bucket (or per bucket x month) for attribution. Most generous trial extension for A, most conservative for D. Tighten caps/expiry for buckets where codes might spread.
+- **Connector bucket (F):** De-emphasize personal trial ("more about your network than about you personally"). Offer a brief walkthrough. Make forwarding frictionless.
+- **Forwardable blurb:** Provide a stripped-down, no-personal-framing version suitable for anyone to forward to a stranger. Include product pitch, audience line, trial link, and code.
+
+**Prompt:** See `prompts/personal-beta-outreach.md` for a full playbook generator.
+
+---
+
+## Growth Audiences
+
+### Primary: [Your Core Buyer — Scaling Acquisition]
+
+Same audience as launch, now reached through scalable channels instead of personal outreach.
+
+### Secondary: [Channel Partners / Affiliates — Scaling the Pipeline]
+
+> 💡 **Lesson learned:** For B2C products targeting professionals,
+> career coaches, outplacement firms, and industry consultants can be powerful
+> distribution partners. The key is giving them a dashboard so they can see ROI.
+> Identify the professional who already serves your buyer and make them a partner.
+
+- Expand from initial partners to [N]+ active affiliates
+- Build a partner dashboard (partners need to see ROI)
+- Target industry conferences, professional associations, certification programs
+
+### Tertiary: [Adjacent Audience]
+
+- **Who:** [Describe the audience that's one step away from your core buyer]
+- **Acquisition channels:** [Where they hang out]
+- **Note:** [Why they matter — often they grow into the primary segment]
+
+### Opportunity: [B2B / Enterprise Angle] (if applicable)
+
+> 💡 **Lesson learned:** B2B opportunities often emerge from B2C products.
+> A company buying 50 seats at $89/seat/month is $53K ARR from a single sales conversation.
+> But wait until Month 6+ when you have individual user testimonials and case studies.
+
+- **Who:** [Business buyers who would purchase for their team/employees]
+- **Pain:** [What they currently pay for and why your product is better]
+- **Conversion trigger:** [Free pilot, case study, ROI calculator]
+- **Timing:** Month 6+, once individual user proof exists
+
+---
+
+## Growth Channels
+
+### 1. Content Marketing & SEO (Month 3+)
+
+**Goal:** Rank for queries your target buyer actually types.
+
+**Target keywords:**
+
+> 💡 **Lesson learned:** Research keywords at each stage of the buyer journey:
+> - Problem-aware: "how to [solve problem]" (highest volume, broadest)
+> - Solution-aware: "[specific solution] for [audience]" (medium volume, higher intent)
+> - Comparison: "[your category] vs [alternative]" (lower volume, highest intent)
+> - Emotional: "[frustration/pain point]" (surprisingly high volume, low competition)
+
+- "[Problem-aware keyword]" (~volume/mo)
+- "[Solution-aware keyword]" (~volume/mo)
+- "[Comparison keyword]" (~volume/mo)
+- "[Emotional/pain keyword]" (~volume/mo)
+
+**Content cadence:** Start biweekly, scale to weekly by Month 4.
+
+#### Content Topic Expansion (brainstorm then bucket)
+
+_Run this before building your editorial calendar. The goal is to surface content topics you would not have generated from your pillars alone._
+
+**Step 1: Generate a domain keyword vocabulary.** Produce 100-150 keywords, phrases, and questions related to your product's domain. Include all stages of the buyer journey:
+
+- Problem-aware queries ("how to manage a senior job search")
+- Solution-aware queries ("executive resume tailoring tool")
+- Comparison queries ("[your product] vs [alternative]")
+- Emotional queries ("job search burnout at senior level")
+- Tactical queries ("how to follow up after executive interview")
+- Aspirational queries ("career transition at 50")
+
+> 📝 **Example prompt:** "Generate 150 keywords, phrases, and questions that [your target audience] might type into Google, ask on LinkedIn, or discuss in professional communities about [your domain]. Cover the full range: practical how-to, emotional/frustration, comparison/evaluation, aspirational, tactical, and strategic."
+
+**Step 2: Bucket against content pillars.** Define 4-6 content pillars that map to your value propositions (e.g. Preparation Strategy, Tailoring & Documents, Networking Execution, Interview Mastery, Search Management, Emotional Resilience). Score each keyword/phrase against the pillars. A keyword may land in multiple pillars.
+
+**Step 3: Review for editorial signals.**
+
+- **Cross-pillar keywords** (3+ pillars) — strong candidates for pillar pages or cornerstone content that links to multiple articles
+- **Pillar-starved topics** — pillars with few keywords need either a narrower scope or a follow-up keyword generation pass
+- **Emotional keywords** — often overlooked in B2B content but high-value for SEO (low competition, high resonance)
+- **Keywords that don't fit any pillar** — potential new content category or a signal that a pillar is missing
+
+**Step 4: Feed into editorial calendar.** Map topics to buyer journey stages and assign to the publication cadence. Prioritize cross-pillar keywords (they earn backlinks from multiple internal pages) and emotional keywords (they earn social shares and low-competition rankings).
+
+### 2. Product Hunt & Hacker News (Month 3–4)
+
+> 💡 **Lesson learned:** These are one-shot channels. Preparation matters more than timing.
+> Product Hunt: Need 20+ users willing to upvote/comment on launch day, 3 demo GIFs, active founder in comments.
+> Hacker News: Lead with the personal story + technical angle. HN respects both.
+
+**Product Hunt:**
+
+- Timing: Tuesday–Thursday, early AM Pacific
+- [N]+ users willing to comment and upvote on launch day
+- 3 demo GIFs showing the core value proposition
+- Active founder presence in comments throughout launch day
+
+**Hacker News "Show HN":**
+
+- Angle: [Personal story + technical story combined]
+- Lead with the core value proposition in one sentence
+
+### 3. Podcast Guest Appearances (Month 3+)
+
+**Target podcasts:**
+
+- [Industry-specific podcasts for your target buyer]
+- [Adjacent-topic podcasts with overlapping audiences]
+- [Indie hacker / bootstrapper podcasts for the founder story]
+
+**Cadence:** 2–3 per month once the pipeline is warm.
+
+### 4. Community Participation (Ongoing)
+
+> 💡 **Lesson learned:** Reddit and niche communities are credibility channels,
+> not acquisition channels. Worth maintaining a presence, not worth significant time.
+> Never post promotionally. Share expertise, and users will find the product through
+> your profile history if the content is good enough.
+
+**Target communities:**
+
+- [Subreddits, forums, Slack/Discord communities]
+
+**Tactics:**
+
+- Answer questions with real depth — share your framework without plugging the tool
+- No promotional posts. Let the product speak through your expertise.
+
+### 5. Paid Advertising (Month 4+ — First Experiment)
+
+> 💡 **Lesson learned:** Only run paid after:
+> 1. Organic content has proven which messages get highest engagement
+> 2. Landing page conversion rate is measurable
+> 3. At least 5 testimonials are on the landing page
+> Start with $500 test budget and measure CPA before scaling.
+
+**Budget:** $500 initial test, measure CPA before scaling.
+
+**Platform:** [Best platform for your audience's targeting options]
+
+**Creative:** Lead with the core value proposition.
+
+**Only run paid after:**
+
+- Organic content has proven which messages resonate
+- Landing page conversion rate is measurable
+- At least 5 testimonials are on the landing page
+
+### 6. Conferences & Events (Month 6+ — if applicable)
+
+- Attend [relevant industry conferences]
+- Free pilot offers for enterprise prospects
+- Case study content from early adopters
+
+### 7. Product-Led Growth Loops (When Built)
+
+> 💡 **Lesson learned:** Identify the natural "share moment" in your product.
+> For Exec Foundry, it was a shareable stats card showing anonymized search progress.
+> For other products, it might be an invite flow, a public profile, or an embed widget.
+> The best virality loops make sharing a natural part of the user's workflow, not a separate ask.
+
+- [Browser extension / integration that surfaces the product in context]
+- [Shareable artifact that creates organic social proof]
+- [Referral program with clear incentive structure]
+
+---
+
+## Key Differentiators vs. Competition
+
+> 💡 **Lesson learned:** A feature comparison matrix makes your positioning
+> concrete. List the 8-12 features that matter most to your buyer and show where
+> competitors fall short. This informs both marketing copy and product roadmap.
+
+| Feature         | [Your App] | [Competitor 1] | [Competitor 2] | [Competitor 3] |
+| --------------- | ---------- | -------------- | -------------- | -------------- |
+| [Key feature 1] |            |                |                |                |
+| [Key feature 2] |            |                |                |                |
+| [Key feature 3] |            |                |                |                |
+
+---
+
+## Launch Sequence
+
+### Phase 2 — Growth Push (Months 3–6)
+
+- [ ] Product Hunt launch
+- [ ] Hacker News "Show HN" post
+- [ ] Scale content to weekly cadence
+- [ ] First podcast guest appearances
+- [ ] First paid experiment ($500 test budget)
+- [ ] Collect and publish case studies
+- [ ] Expand partner network
+
+### Phase 3 — Scale (Months 6–12)
+
+- [ ] Launch B2B outreach (if applicable)
+- [ ] Product-led growth features live
+- [ ] Expand partner network to [N]+
+- [ ] Evaluate paid search for high-intent keywords
+- [ ] Explore podcast sponsorships
+
+---
+
+## Metrics & Goals
+
+| Metric          | Month 3 | Month 6 | Month 12 |
+| --------------- | ------- | ------- | -------- |
+| Signups         |         |         |          |
+| Paying users    |         |         |          |
+| MRR             |         |         |          |
+| Blended ARPU    |         |         |          |
+| Partners active |         |         |          |
+| Organic traffic |         |         |          |
+| NPS             |         |         |          |
+
+---
+
+## Budget Allocation (Monthly)
+
+| Channel           | Months 3–6 | Months 6–12 |
+| ----------------- | ---------- | ----------- |
+| Content writing   |            |             |
+| Email platform    |            |             |
+| Paid ads          |            |             |
+| Conference travel |            |             |
+| Tools / misc      |            |             |
+| **Total**         |            |             |
+
+No paid ads without a proven CAC benchmark from organic.