Wyse Campaign Setup

What was proposed, what actually landed on the Wyse VM, and what is still missing.

Source thread: T3 Code Campaign Setup (originally Email campaign platforms), 23 Jul–4 Aug 2026. Project: macbook-pro-wyse.

Original goal

Lifecycle campaigns such as:

• funded, traded once, then went quiet
• won on market X, might want market Y
• viewed a market, never traded

Later channels: WhatsApp, SMS, push, and possibly trading via WhatsApp. Constraints: stay near $100/month, keep CLI/MCP for workflow creation, reuse the existing Wyse stack.

What was proposed (and how it changed)

1. First architecture: Customer.io

Dove → PostHog → Customer.io
          ↑
     Falcon/Hatchet

Falcon would be source of truth for trades/funding; PostHog would keep browsing events; Customer.io would own audiences and sends.

Rejected: Essentials ~$190/month at 15k users. Builder is cheaper but drops journeys, dynamic segments, and real automation.

2. Sender.net (and Sender + Zernio)

Sender was cheap for email automations, but had no official CLI/MCP, no WhatsApp/push, and no API to create workflows. Sender + Zernio split email and WhatsApp with no shared workflow state, preferences, or in-app/push.

3. Chosen path: PostHog + Novu + Maileroo, code in Raven

Novu was chosen for MCP/CLI, multi-step workflows, and future WhatsApp/push/in-app. The first sketch put a Novu adapter in Falcon. That was changed: almost all new code should live in Raven.

Marketing / campaign API
        ↓
      Raven
   ├── audience / eligibility
   ├── campaign_id, run_id, delivery_id
   ├── consent + suppression
   └── trigger Novu
        ↓
   Novu workflow (delay, branch, template)
        ↓  email webhook
      Raven Maileroo provider
        ↓
     Maileroo

Maileroo webhooks → Raven → PostHog
Trades            → Falcon (attribution) → PostHog

Novu orchestrates. Raven owns IDs, delivery, tags, webhooks, unsubscribe, and reporting. PostHog owns funnels and conversion.

What was actually implemented (4 Aug, Wyse VM)

This is the from-scratch VM work.

VM

• Existing 4 vCPU / ~8 GB box (no resize)
• 8 GB swap added
• Docker cleanup: free disk 34 GB → ~65 GB
• TLS via Caddy + sslip.io (same as Raven/Magpie). No custom DNS.

Novu

• Self-hosted: API, worker, dashboard, Mongo, Redis
• Dashboard: https://novu.38-242-206-255.sslip.io
• Admin email: marketing@wysemarket.com (password in macOS Keychain as Wyse Novu administrator password)

Raven campaign stack

• Campaign / run / recipient models and migration
• Novu trigger client
• Novu email webhook → Raven → Maileroo
• Signed Maileroo webhooks for delivered / opened / clicked / bounced
• Signed unsubscribe + suppression
• PostHog campaign events (entered, submitted, accepted, delivered, opened, …)
• GET /v1/campaigns/runs/{run_id}/performance
• GET /v1/campaigns/provider-performance (Maileroo 30-day app-wide stats)
• Tests: 69 passed, 1 skipped

Verified send

• Cohort: only izuchukwuuchegbu@gmail.com
• Path: Novu → Raven → Maileroo
• Final run: 1 recipient, 1 delivery, status opened
• PostHog showed entered → accepted → delivered → opened

Live URLs at the time: Raven https://38-242-206-255.sslip.io, Novu https://novu.38-242-206-255.sslip.io.

Earlier in the same thread, Maileroo SMTP was proven independently (plain text + HTML win notification from the verified Wyse sender).

Agreed but not built as originally planned

Gaps

Product / campaign system

The pipeline is a pilot email path, not a marketing system. Not implemented:

• PostHog-driven audiences
• Multi-step Novu journeys (wait, exit-on-trade, WhatsApp fallback)
• Launch campaigns (funded-never-traded, one-trade win-back, viewed-no-trade)
• The five high-signal campaigns (second-trade catalyst, abandoned simulation, claimed-winnings redeploy, funding interruption, high-intent market alerts)
• Variant / A/B reporting in a real send
• Click-to-trade attribution (/r/{signed_token} → Falcon trade → PostHog volume)
• Marketing self-service via Novu MCP in production

Falcon / Dove

• Authoritative Falcon events as campaign triggers
• Falcon attaching campaign IDs to successful trades
• Dove persisting marketing consent
• PostHog identify with email + consent properties

The VM Falcon DB was empty. Campaign ideas used production PostHog only, not production Cloud SQL.

Analytics

• Novu does not see Maileroo opens/clicks
• Maileroo stats API is application-wide, not per campaign
• Opens are noisy; clicks + trades are the real KPIs
• PostHog had staging/UAT contamination and bogus simulation amounts

WhatsApp / SMS / push

Researched, not implemented. End recommendation: Zernio behind a Raven provider, Novu for orchestration, Raven for consent/IDs/inbound. Meta Cloud API is the no-markup alternative. Wasender is test-only.

Ops / security

• Novu on 4 vCPU / 8 GB with Raven + Magpie is pilot-tight
• Maileroo keys were pasted in chat and never rotated
• Unused Maileroo test webhook still pointed at example.com
• No backups for Novu Mongo / Raven Postgres
• Changes were deployed to the VM but left uncommitted at the time of the chat

Current state, short version

Proposed: PostHog finds people → Raven checks eligibility and IDs → Novu runs the journey → Raven/Maileroo delivers → webhooks + PostHog measure trades.

Implemented: Self-hosted Novu on the Wyse VM, Raven campaign/email/webhook/unsubscribe/reporting, one successful email that opened.

Gap: The growth loop — Falcon eligibility, real consent, PostHog audiences, conversion attribution, the five campaigns, WhatsApp, and production hardening.

Highest-leverage next campaign from the thread: second-trade catalyst (128 of 226 production traders never placed a second trade; most who did did it within ~2 hours). That still needs Falcon validation before any send beyond the test address.