Pushcast
Pushcast connects to a GitHub repo, builds a structured understanding of the product using Claude, and autonomously drafts and schedules marketing posts — surfacing them for founder approval before publishing.
This is Pushcast's own Brain — built by Pushcast, from Pushcast's own code. It's the exact report you get for your repo: features, ICP, and differentiators, every claim citing the file it came from.
Features
Repo Scanning & Product Brain Generation
Connects to a GitHub repo via OAuth installation, scans the codebase, and uses Claude to produce a structured ProductBrain (features, brand kit, facts with confidence scores) stored as brain_facts rows.
Benefit: The founder never has to write a product brief — the system derives what the product does from the actual code, not marketing copy.
GitHub Integration & Webhook-Driven Marketing Events
Installs a GitHub App on the user's repo; incoming push/release webhooks create marketing_events rows that trigger the draft pipeline. Simulation endpoints allow testing without a live repo.
Benefit: Every commit or release automatically becomes a candidate marketing moment without any manual input from the founder.
AI Draft Post Generation
For each marketing_event, the worker package (using @pushcast/brain and @pushcast/publish) generates draft_posts per channel, drawing on brain_facts and BrandKitSchema to match the product's voice.
Benefit: Founders receive ready-to-approve posts that already sound like their product, not generic AI output.
Morning Digest & Approval Queue
The /app/digest page presents pending draft_posts for review. The /api/draft/action endpoint handles approve, edit, and veto actions, moving posts to scheduled_posts or discarding them.
Benefit: The founder's entire marketing review collapses to a single timed session — keyboard-navigable (j/k/a/e/v) — rather than managing multiple publishing tools.
Channel Settings & Trust Mode / Veto Window
Per-product, per-channel configuration stored in channel_settings controls trust_mode (auto-publish vs. require approval) and veto_window_hours (how long the founder has to block a scheduled post).
Benefit: Founders can dial autonomy per channel — fully automatic for low-stakes channels, human-gated for high-stakes ones — without changing the core workflow.
Scheduled Post Queue
Approved drafts become scheduled_posts rows with a send_after timestamp, channel, status, and external_ref for tracking the published artifact. The worker handles actual publishing via @pushcast/publish.
Benefit: Posts go out at the right time without the founder being online, and the external_ref enables downstream performance tracking.
Signals & Post Performance Tracking
post_metrics rows capture per-post, per-channel metric values (e.g. impressions, clicks) over time. The /app/signals page surfaces these. The @pushcast/signals and @pushcast/watcher packages handle ingestion and monitoring.
Benefit: The brain can learn which content patterns work and adjust future drafts, closing the loop from publish to learning.
A/B Experiment Engine
experiments and variants tables support multi-variant content tests per channel, with variant_metrics tracking outcomes and a winner_variant_id field for resolution. The @pushcast/experiments package contains the logic.
Benefit: The system can systematically test hook styles, formats, or CTAs and feed winning patterns back into the brain without manual analysis.
Inbox & AI Reply Drafting
inbox_items captures inbound social mentions/replies (with priority, money_adjacent flag, kind, and thread_id). reply_drafts are AI-generated responses that reference brain_facts_used, with auto_send_allowed control.
Benefit: High-priority or revenue-adjacent mentions surface for the founder to approve a reply, with the brain already having drafted a contextually accurate response.
Launch Kit / Card Generation
The /api/card route and @pushcast/creative package use Satori to render HTML/React components to SVG (then sharp for rasterization), producing shareable visual cards. /kit and /kit/[slug] pages serve launch kit artifacts.
Benefit: Founders get on-brand visual assets generated from their product brain without a designer or design tool.
Multi-Product & Org Support
orgs, org_members (with roles), and products tables support multiple products per org, each with its own repo_url, scan state, brain_run_ref, and channel settings.
Benefit: A founder with more than one product (or a small team) can manage all products under one account without separate logins.
Magic Link & OAuth Authentication
Auth supports both magic-link email (/api/auth/magic) and OAuth (/api/auth/oauth) flows via Supabase SSR, with a dev-bypass login for local development.
Benefit: No password friction for solo founders; magic link is the primary path, OAuth as an alternative.
Who it's really for
The schema and UX constraints converge on a single-person operator: org_members has a role field but the UX docs describe 'a tired solo founder checking in for ten minutes'; the digest is keyboard-first and designed for mobile review from bed. The money_adjacent flag on inbox_items and the veto_window_hours on channel_settings both reflect someone who cannot afford a PR mistake but also cannot spend hours on marketing. The GitHub-as-source-of-truth architecture means the ICP must be technical enough to have a repo. The brain_facts confidence scoring and evidence audit (PROGRESS.md) suggest the product is being dogfooded by its own founder.
Differentiators
The repo is the source of truth for product understanding, not a manually written brief
Most AI marketing tools require the user to describe their product. Pushcast scans the actual codebase and derives features, brand, and facts from code — meaning the brain stays accurate as the product evolves without any founder input.
Veto-window autonomy model rather than approve-every-post model
channel_settings.trust_mode and veto_window_hours allow the system to auto-publish unless the founder intervenes, inverting the default assumption that humans must approve everything. This is architecturally distinct from a drafting tool.
Closed-loop learning: publish → metrics → brain facts → better drafts
post_metrics, variant_metrics, and brain_facts are all connected by org_id and product_id, enabling the worker to feed performance data back into the brain. Most marketing tools treat publishing and analytics as separate products.
AI-generated on-brand visual cards from the product brain, no designer required
The @pushcast/creative pipeline (Satori → SVG → sharp → PNG) generates visual assets using BrandKitSchema derived from the repo scan, not a user-uploaded brand guide.
Jobs to be done
- When I ship a new feature, I want it to automatically become a draft post, so I can stay focused on building instead of writing marketing copy.
- When I have 10 minutes in the morning, I want to review and approve everything my product generated overnight, so I can maintain a public presence without a daily time commitment.
- When someone replies to my post with a question or buying signal, I want a drafted response ready for my approval, so I don't miss revenue-adjacent conversations.
- When I'm not sure what my product's voice should sound like, I want the system to derive it from my codebase, so I don't have to write a brand guide.
- When I want to know if a hook style is working, I want the system to run the experiment and tell me the winner, so I don't have to manually analyze post performance.
- When I connect a new repo, I want the system to understand what I built without me explaining it, so onboarding doesn't require a product brief.
Open questions
a 5-minute founder review — what code can't reveal
- Which social/publishing channels are currently supported by @pushcast/publish — the schema stores channel as a string but no channel enum or integration is visible in the scan.
- How does the watcher (@pushcast/watcher) ingest post_metrics — is it polling platform APIs, or does it rely on webhooks from publishing platforms?
- What is the pricing model — the schema has no subscription, plan, or billing table visible in the migrations.
- Is the product currently invite-only or publicly accessible — no waitlist or invite table exists in the schema, but SETUP_CHECKLIST.md implies it is not yet live.
- What is the intended GTM motion — the LAUNCH_NOTES.md references Pushcast's own Launch Kit being generated from its self-brain, suggesting a dogfood-first launch, but the sequencing is unclear.
- How are org_members roles (beyond the role field) enforced — RLS policies are referenced in SETUP_CHECKLIST.md but policy definitions are not in the scanned migration files.
- What external publishing platforms are targeted as channel destinations — Twitter/X, LinkedIn, and others are plausible but not confirmed by any integration evidence.