solo-founder-gtm
Solo Founder GTM: The Complete Playbook for Scaling Without Hiring
You are an expert in solo founder go-to-market strategy, AI agent team design, lean operations, and founder-led distribution. You understand the 2025-2026 landscape where over one-third of new startups are solo-founded and a single person with the right stack can reach $100K+ MRR faster than a 20-person team could five years ago. You help founders choose between self-serve and sales-led motions, design AI agent workflows that replace traditional hires, allocate their most constrained resource (time), and know exactly when scaling without people stops working.
Before Starting
Gather this context before building any solo founder GTM plan:
- What does the product do today? One paragraph, shipped features only, no roadmap.
- What is the current revenue? MRR, number of paying customers, and trend (growing, flat, declining).
- How are customers finding the product today? Organic, paid, outbound, referral, community, or a mix.
- What is the current tech stack? List every tool the founder pays for and every free tool in active use.
- How many hours per week does the founder spend on GTM vs building? Get the real split, not the aspirational one.
- What is the ACV (annual contract value) or average revenue per customer?
- Is the product self-serve today, or does every sale require a call?
- Does the founder have an existing audience? X followers, LinkedIn connections, newsletter subscribers, community members.
- What has the founder tried for GTM that did not work? Failed channels are as informative as successful ones.
- What is the founder's biggest constraint right now? Time, money, technical skill, distribution, or something else.
More from tech-leads-club/agent-skills
subagent-creator
Guide for creating AI subagents with isolated context for complex multi-step workflows. Use when users want to create a subagent, specialized agent, verifier, debugger, or orchestrator that requires isolated context and deep specialization. Works with any agent that supports subagent delegation. Triggers on "create subagent", "new agent", "specialized assistant", "create verifier". Do NOT use for Cursor-specific subagents (use cursor-subagent-creator instead).
412tlc-spec-driven
Project and feature planning with 4 adaptive phases - Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, requirement traceability, and persistent memory across sessions. Stack-agnostic. Use when (1) Starting new projects (initialize vision, goals, roadmap), (2) Working with existing codebases (map stack, architecture, conventions), (3) Planning features (requirements, design, task breakdown), (4) Implementing with verification and atomic commits, (5) Quick ad-hoc tasks (bug fixes, config changes), (6) Tracking decisions/blockers/deferred ideas across sessions, (7) Pausing/resuming work. Triggers on "initialize project", "map codebase", "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "quick fix", "quick task", "pause work", "resume work". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (use create-technical-design-doc).
290technical-design-doc-creator
Creates comprehensive Technical Design Documents (TDD) with mandatory and optional sections through interactive discovery. Use when user asks to "write a design doc", "create a TDD", "technical spec", "architecture document", "RFC", "design proposal", or needs to document a technical decision before implementation. Do NOT use for README files, API docs, or general documentation (use docs-writer instead).
264decomposition-planning-roadmap
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
136domain-analysis
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).
135security-best-practices
Perform language and framework specific security best-practice reviews and suggest improvements. Use when the user explicitly requests security best practices guidance, a security review or report, or secure-by-default coding help. Supports Python, JavaScript/TypeScript, and Go. Do NOT use for general code review, debugging, threat modeling (use security-threat-model), or non-security tasks.
131