# Pushcast — Launch & Warmup Emails ## Launch email **Subject A (benefit):** Pushcast is live — point it at a repo **Subject B (curiosity):** the marketing tool that reads your code, not your landing page _Testing: concrete product-is-live vs. the contrarian curiosity hook._ Hey — Pushcast is live. Connect a repo and it reads your code — in memory, secrets skipped, raw code discarded — to build a Product Brain: your features, your ICP, why you're different, every claim citing the file it came from. From that it writes your positioning and a full launch kit, and turns every push into drafted posts waiting in a ten-minute weekly review. You approve everything. Nothing goes out on its own. If you've shipped something good and watched it sink, this is the tool I wish I'd had. See what it reads → [link] — [Founder] P.S. It's dogfooding itself — Pushcast's own launch was generated by Pushcast. Reply and I'll send you its self-Brain. --- ## Warmup 1 — the story / why **Subject A:** why I built a marketing tool I didn't want to build **Subject B:** the blank tweet box problem _Testing: personal-stakes vs. the specific shared pain._ Hey — Quick story about why Pushcast exists. I can ship software. What I can't do is sit at the blank tweet box and explain why anyone should care. And every marketing tool I tried made it worse — they all started by asking for a landing-page URL or a paragraph about my product. That's marketing copied from marketing. The real answer was sitting in my repo the whole time. So I built the thing that reads the repo. Over the next few emails I'll show you exactly how it works — starting tomorrow with the part that makes developers nervous: what happens to your code. — [Founder] --- ## Warmup 2 — a real feature deep-dive **Subject A:** your code is read, not stored (here's how) **Subject B:** the part where I prove I'm not keeping your code _Testing: the claim vs. the proof framing._ Hey — The scariest thing about a tool that connects to your repo is the obvious question: what happens to my code? Pushcast's answer is in the architecture, not a policy page. When it scans, files are read into memory, a gitleaks-style denylist skips anything secret-shaped (`.env`, keys, credentials), structured facts + file paths are extracted, and the raw file contents are discarded. Nothing code-shaped is stored or sent to a model. We log what was skipped so you can check. That's why the Brain can cite the exact file behind every feature — and why an auditor rejects any claim it can't point at. Receipts, by design. Tomorrow: launch day, and the recursive bit — Pushcast marketing Pushcast. — [Founder] --- ## Warmup 3 — launch imminent / early access **Subject A:** we open tomorrow — bring a repo **Subject B:** want to watch a tool read your code? _Testing: straight timing nudge vs. the demo-curiosity hook._ Hey — Pushcast opens tomorrow and you're on the early list. Here's the 90 seconds I want you to try first: connect a repo and watch the scan — files mapped, integrations found, the Brain assembling — then the reveal of what it understood about your product. That's the moment this whole thing is built around. You'll get the link first thing tomorrow. Have a repo in mind. — [Founder] P.S. Reply if you want me to run it on your repo with you on a call — happy to.