skills/tech-launch-channels/SKILL.md
Platform-specific launch playbooks for developer tools and technical products. Covers Hacker News, Product Hunt, Reddit, LinkedIn, Twitter/X, Indie Hackers, Dev.to, and Facebook with exact timing, formatting rules, community norms, and common mistakes for EACH channel. Activate on 'launch', 'Hacker News', 'Product Hunt', 'Show HN', 'Reddit launch', 'developer marketing channels', 'where to post', 'distribution channels', 'launch day', 'go-to-market'. NOT for writing the announcement itself (use product-announcement-craft) or SEO/content strategy (use seo-content-blogging).
npx skillsauth add curiositech/windags-skills tech-launch-channelsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Platform-by-platform playbook for launching developer tools and technical products. Not generic social media advice -- the specific tactics that work on each channel, from someone who has seen hundreds of dev tool launches succeed and fail.
Use for:
Do NOT use for:
Post to channels in this order. Each channel has different peak windows and the order matters because early traction on one feeds momentum on others.
06:00 AM ET - Hacker News (Show HN)
08:00 AM ET - Twitter/X thread
09:00 AM ET - LinkedIn post
10:00 AM ET - Dev.to article
12:00 PM ET - Reddit (r/SideProject, then niche subs)
02:00 PM ET - Indie Hackers
Evening - Facebook groups
Next day - Product Hunt (if using PH, make it its OWN day)
Product Hunt resets daily at 12:01 AM PT. Launch it on a SEPARATE day from your HN push so you can give each platform full attention.
Reach potential: 500K-2M+ impressions if front page Best for: Technical tools, open source, anything builders appreciate Culture: Meritocratic, skeptical, hates marketing speak
Show HN: <Name> - <What it does in plain English>
GOOD: Show HN: Windags - DAG orchestration for multi-agent workflows
GOOD: Show HN: I built a CLI that turns natural language into parallelized agent calls
BAD: Show HN: Introducing Windags - The Future of AI Orchestration (tm)
BAD: Show HN: We're excited to announce our new platform
Rules:
Immediately post a comment on your own submission. This is your one chance to tell the story:
Template:
Hey HN, I'm [name]. I built [thing] because [genuine problem you had].
[1-2 sentences on how it works technically]
[What makes this different from X, Y, Z alternatives]
I'd love feedback on [specific question]. The code is at [repo link].
What works: Honesty about limitations, technical depth, asking for specific feedback What kills you: Marketing speak, ignoring criticism, defensive responses
You get ONE launch. A re-post only works if you have something substantially new (major feature, open-sourced it, pivoted). Wait at least 3-6 months.
Reach potential: 10K-100K visitors on launch day Best for: Polished tools with visual demos, products targeting early adopters Culture: Supportive, upvote-driven, rewards preparation and community engagement
Launches that cross 100 upvotes before 4:00 AM PT have an 82% chance of finishing Top 10. This means your email list and personal network must be activated the moment you launch.
Tagline: [verb] + [what] + [benefit] (under 60 chars)
GOOD: "Build AI workflows with drag-and-drop DAGs"
BAD: "The revolutionary AI platform for the future"
First Comment:
- Who you are and why you built this
- What problem it solves (be specific)
- What's free vs paid
- Ask for specific feedback
Reach potential: Varies wildly by subreddit (1K to 1M+) Best for: Authentic stories, technical deep-dives, "I built this" narratives Culture: Allergic to self-promotion, rewards genuine contribution
For every 1 self-promotional post, you need 9 genuine contributions (comments, helpful answers, sharing others' work). Build 200-300 karma before any product mentions.
| Subreddit | Members | Rules | Best Post Format | |-----------|---------|-------|------------------| | r/SideProject | 200K+ | Self-promo OK | "I built X" with story + demo | | r/webdev | 2M+ | Self-promo threads only | Technical deep-dive, ask for code review | | r/programming | 5M+ | No self-promo | Technical article about HOW you built it | | r/opensource | 100K+ | Projects welcome | Repo link + what problem it solves | | r/selfhosted | 400K+ | Projects welcome | Docker setup + why self-host matters | | r/InternetIsBeautiful | 17M+ | Must be web-based | Just the URL + short description | | r/startups | 1.5M+ | Friday self-promo thread | Business story, not product pitch | | r/entrepreneur | 3M+ | Share your journey | Revenue numbers, lessons learned | | r/buildinpublic | 50K+ | Everything welcome | Progress updates, metrics, failures |
Title: I spent 6 months building [X] - here's what I learned
Body:
- The problem you had (relatable)
- What you tried first (shows effort)
- How you built the solution (technical detail)
- What surprised you (honest reflection)
- Link to project (at the END, not the beginning)
- "Happy to answer questions about [specific technical topic]"
Reach potential: 10K-500K impressions with a good thread Best for: Build-in-public narratives, demo videos, connecting with developer influencers Culture: Rewards visual content, hot takes, and authenticity
Tweet 1 (Hook): Bold claim or surprising result
"I replaced 4 hours of manual agent coordination with a 30-second DAG."
Tweet 2: The problem (relatable pain)
Tweet 3: The solution (what you built, with screenshot or GIF)
Tweet 4: How it works (technical but accessible)
Tweet 5: Demo video or GIF (60 sec max)
Tweet 6: What's next + call to action
Tweet 7: Link to try it
Final tweet: "If this was useful, follow me for more [topic] content"
Reach potential: 5K-200K impressions for good content Best for: Professional narrative, "lessons learned" format, B2B developer tools Culture: Professional but increasingly authentic, rewards storytelling
[Hook line that stops the scroll - personal, surprising, or contrarian]
[Blank line]
[2-3 short paragraphs telling the story]
[Blank line]
[Bullet list of key takeaways or lessons]
[Blank line]
[Call to action - try it, follow for more, link in comments]
GOOD: "I spent 6 months building something nobody asked for. Here's why I don't regret it."
GOOD: "3 things I learned launching a developer tool with zero marketing budget"
BAD: "Excited to announce the launch of our new platform!"
BAD: "We're hiring! Also check out our new product"
Reach potential: 5K-50K views for featured articles Best for: Technical tutorials, architecture deep-dives, "how I built this" posts Culture: Developer-first, educational, supportive of new tools
Reach potential: 1K-20K views, but 23% conversion rate per engaged post Best for: Revenue stories, build-in-public updates, asking for feedback Culture: Founder-friendly, loves transparency, especially revenue numbers
Journey posts with specific numbers outperform everything else:
GOOD: "From $0 to $2.4K MRR in 90 days -- how I launched [X]"
GOOD: "I got 500 signups in a week. Here's the exact playbook."
BAD: "Check out my new developer tool!"
BAD: "Announcing [product name]"
Reach potential: 500-5K per group, but highly targeted Best for: Niche communities, local tech scenes, framework-specific groups Culture: Varies wildly by group -- read the rules first
Mistake: Posting to all channels simultaneously with the same copy-paste message. Fix: Tailor each post to the platform's culture and format. Stagger over 2-3 days.
Mistake: Posting your launch and not checking back for 8 hours. Fix: Block your entire launch day. Respond to every comment within 30 minutes.
Mistake: Sending direct links to friends asking them to upvote on HN or PH. Fix: On HN, tell people to find your post on /newest. On PH, ask people to "check it out." Both platforms detect and penalize vote manipulation.
Mistake: "We're thrilled to announce our revolutionary AI-powered platform." Fix: "I built a CLI that turns prompts into parallel agent workflows. Here's how it works."
Mistake: Defensive replies or ignoring negative feedback. Fix: Thank critics, find something to agree with, explain your thinking. The audience watches how you handle criticism more than the criticism itself.
Mistake: Treating launch as a single event. Fix: Launch day is day 1. Follow up with technical blog posts, case studies, changelog updates, and "3 months later" retrospectives on each channel.
Mistake: Launching a B2B enterprise tool on r/SideProject, or a hobby project on LinkedIn. Fix: Match channel to audience. HN and Reddit for technical builders. LinkedIn for B2B. PH for early adopters. Indie Hackers for solo founders.
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.