Skip to main content

Founder reviews the morning brief

Persona​

John Moelker, solo founder. Starts each morning with a single markdown digest that replaces the need to check inboxes, dashboards, and scorecards manually. Has 10–15 minutes for operational review. Job: triage what's broken, what needs approval, what agents handled overnight. Trusts summarization but demands evidence — every claim has a clickable drill link. Silent failures are the worst outcome.

Entry points​

  1. Email digest — Vercel cron fires POST /api/cron/morning-brief-compose at 6:55am. Inserts row into morning_briefs table (one per date, idempotent). Email sent via Resend at 7:00am. Subject: "Morning Brief — [Day] [Date]."
  2. Dashboard page — https://churchwiseai.com/founder/[token]/morning-brief — today's digest with view history toggle.

Click-through flow​

Steps​

  1. Receives and opens the morning brief — Email formatted as markdown. Header: one-line portfolio summary (e.g., "All systems operational · MRR $X · 3 action items"). Traffic-light indicators (green/yellow/red) for each property (CWA, PewSearch, ITW, SermonWise, Pro Website). Compose step aggregates from: latest readiness scorecards, ops_errors table (unresolved P0/P1 from past 24h), founder_action_items (open items ≤ P1), moderation_violations (high-severity past 7d), premium_churches with is_real_customer filter, Stripe MCP for live MRR.

  2. Scans portfolio summary — Sections in order: What's Live (per-property status snapshot with scorecard link and last-run timestamp), Money (Stripe customers, MRR, failed webhooks; outreach counts), What Broke Overnight (regressions with before/after scorecard diff links). If a scorecard was not generated (build failed), section shows ⚠ unverified: [reason] — never omitted.

  3. Drills into a flagged issue — Drill links open source artifacts: /founder/[token]/readiness/cwa/latest for a scorecard, GitHub diff for a regression, Stripe event for a failed webhook. All drill links are generated fresh by the compose step (never hardcoded). Founder reviews, decides next action, returns to brief.

  4. Reviews action items flagged for the founder — Section "Actions For You (N items, ~X min)" listing P0/P1 items only: refund requests pending approval, provisioning failures needing manual area code selection, moderation escalations. Each item has a concrete action link ("Approve refund in Stripe," "Provide Telnyx area code"). Most take 1–3 minutes per item.

  5. Closes the brief — Founder exits with a clear portfolio state. Actions taken are logged in the brief's JSON metadata. A follow-up "Actions Taken For You" section (updated by an evening agent) logs what cron agents handled overnight.

Acceptance spec​

No external acceptance spec — internal operational routine. Governed by:

  • Process spec: knowledge/processes/morning-brief.md
  • Database: morning_briefs table (date, markdown_body, json_meta, composed_at, email_sent_at, founder_completed_at); related: ops_errors, founder_action_items, moderation_violations, premium_churches
  • Code files: churchwiseai-web/src/app/api/cron/morning-brief-compose/route.ts, churchwiseai-web/src/app/founder/[token]/morning-brief/page.tsx

Success criteria​

  1. Brief arrives by 7:05am on business days, readable in under 2 minutes.
  2. Any P0 issue is at the top with evidence link.
  3. All links point to live data.
  4. Action items are concrete: "Approve refund for $50," not "Something may need reviewing."
  5. Regressions are flagged with before/after links, not buried.
  6. If an input fails (Stripe API down, scorecard not generated), brief says so rather than showing stale data.

Known failure modes​

  • Stale scorecards. Brief shows ⚠ unverified with link to latest available scorecard if current one was not generated. Silence is worse than incomplete signal.

  • Metrics lag. Brief shows data freshness timestamp ("As of 7:02am, 5m ago"). Never show MRR or customer count without a timestamp.

  • Email delivery failure. If Resend bounces, founder misses the brief. Dashboard page is always the fallback. Monitor for delivery failures.

  • Accumulating action items. P2 alert fires if founder_action_items has >10 open items older than 1 day. Founder's target: queue under 5 items at any given time.