New courseMeasure → Keep → Grow with PostHog

Superpowers for growth engineers.

Hogsend is a TypeScript framework for growth teams that code. Identify and enrich the people on your product, react to their events, message them where they are, and measure what moved.

$ pnpm dlx create-hogsend@latest

Deploy on Railway →View docs →

engine v0.59.0Deployed

CLI

export const winback = defineJourney({
  meta: {
    id: "winback",
    trigger: { event: Buckets.WentDormant },
    exitOn: [{ event: Events.ContactActive }],
  },
  async run(user, ctx) {
    await sendEmail({ to: user.email, template: Templates.WinbackCheckIn });

    await ctx.sleep({ duration: days(7), label: "cool-off" });

    await sendEmail({ to: user.email, template: Templates.WinbackOffer });
  },
});

Event plugins

Stripe
Clerk
Supabase
Segment
Intercom & Fin
Vapi
Twilio
Discord
Telegram
PostHog
Resend
Crisp
Postmark
HubSpot
Attio
HighLevel
Meta CAPI
Slack
Stripe
Clerk
Supabase
Segment
Intercom & Fin
Vapi
Twilio
Discord
Telegram
PostHog
Resend
Crisp
Postmark
HubSpot
Attio
HighLevel
Meta CAPI
Slack

Code-first

Journeys are TypeScript in your repo. Version, review and ship them like the rest of your product.

Full-funnel

Onboarding, activation, retention, monetization — one engine across every stage.

Event-powered

React to any event from PostHog, your product, your warehouse or any webhook source.

Measure impact

Built-in experiments, holdouts and lift measurement on every journey.

Signal → response

Whenlifecyclelivesinyourcodebase,everyleakisfixable.When lifecycle lives in your codebase, every leak is fixable.

Hogsend turns each leak into a response your product can ship. Built for code-first teams that need a best-in-class growth engine.

my-app — hogsend/ written by create-hogsend · web/ is your productclick a file to learn more

hogsend/src/journeys/product/onboarding.tswhat this is

import { days } from "@hogsend/core";
import {
  defineJourney,
  sendConnectorAction,
  sendEmail,
} from "@hogsend/engine/journeys";

// The first week as control flow: welcome now, then branch
// on whether they actually created a project.
export const onboarding = defineJourney({
  meta: {
    id: "onboarding",
    trigger: { event: "user.signed_up" },
    entryLimit: "once",
  },
  run: async (user, ctx) => {
    await sendEmail({ to: user.email, template: "welcome" });

    // Park durably until THIS user creates a project — or 3 days pass.
    const { timedOut } = await ctx.waitForEvent({
      event: "project.created",
      timeout: days(3),
    });

    if (timedOut) {
      // Stalled — nudge them, and tag the team where it works.
      await sendEmail({ to: user.email, template: "activation-nudge" });
      await sendConnectorAction({
        connectorId: "discord",
        action: "sendChannelMessage",
        args: {
          channelId: process.env.GROWTH_CHANNEL_ID,
          content: `${user.email} stalled before their first project.`,
        },
      });
      return;
    }

    await sendEmail({ to: user.email, template: "first-win" });
  },
});

onboarding.tsabout

Send, wait, branch on what they did

waitForEvent parks the journey durably until THIS user creates a project — or three days pass. The branch afterwards is an if statement, and the stalled path tags the growth team on Discord.

Durable waitEvent or timeoutBranch = if

about

Send, wait, branch on what they did

waitForEvent parks the journey durably until THIS user creates a project — or three days pass. The branch afterwards is an if statement, and the stalled path tags the growth team on Discord.

Durable waitEvent or timeoutBranch = if

Using Hogsend means that lifecycle marketing becomes part of the product, not a campaign bolted on beside it.

Journeys as code

Lifecycle logic is TypeScript in your repo, reviewed, type-checked, and versioned like the rest of your product.

Your provider, your reputation

Sends go through your own Resend or Postmark account, or any provider behind the EmailProvider contract.

Durable execution

Journeys run as Hatchet durable tasks. A seven-day wait survives deploys, restarts, and crashes.

Source-availablenpmjs.com/@hogsend →

How it works

Measure everything. React in TypeScript. Prove what moved revenue. Steer it all from Studio. Review and ship marketing like the rest of your product, watched live as every send, wait, and branch runs.

Everything in

hogsend enginein your repo

$pageviewvia posthog

user.signupvia sdk

checkout.completedvia stripe

video.progress 75via video

support.ticket_openedvia intercom

email.link_clickedvia tracking

invoice.payment_failedvia stripe

demo.bookedvia segment

contact.subscribedvia engine

sms.link_clickedvia tracking

$pageviewvia posthog

user.signupvia sdk

checkout.completedvia stripe

video.progress 75via video

support.ticket_openedvia intercom

email.link_clickedvia tracking

invoice.payment_failedvia stripe

demo.bookedvia segment

contact.subscribedvia engine

sms.link_clickedvia tracking

hogsend — pnpm dlx create-hogsend@latest my-app

import { refineContact } from "@hogsend/engine";
import { defineJourney, sendEmail } from "@hogsend/engine";

export const highFitWelcome = defineJourney({
  meta: {
    id: "high-fit-welcome",
    trigger: { event: "user.signed_up" },
  },
  run: async (user, ctx) => {
    // Apollo fills title, company, size — only where your
    // own data has gaps. Cached, budget-capped, never throws.
    const { status, properties } = await refineContact({
      userId: user.id,
      email: user.email,
    });

    const bigTeam = (properties?.company_employees ?? 0) >= 50;

    await sendEmail({
      to: user.email,
      template: bigTeam ? "team-welcome" : "welcome",
    });
  },
});

contact — jamie@acme.dev

company—via apolloAcme Inc

role—via apolloHead of Growth

company size—via apollo51–200

groupcompany: acme.dev · 4 contacts

buckethigh-fit → welcome journey

fill-if-absent — your own data always wins

What's actually happening

1The moment someone signs up, enrichment looks them up: job title, company, company size.
2It only fills the blanks — anything you already know about a person is never overwritten.
3Lookups are cached and budget-capped, and a failed lookup never breaks the journey.
4So the very first email can already tell a 50-person team apart from a solo founder.

import { defineWebhookSource } from "@hogsend/engine";
import { z } from "zod";

// Any form vendor's webhook becomes a source —
// Heyflow, Webflow, Framer, or your own backend.
export const leadForm = defineWebhookSource({
  meta: { id: "lead-form", name: "Lead form" },
  auth: {
    header: "x-lead-form-secret",
    envKey: "LEAD_FORM_WEBHOOK_SECRET",
    type: "match",
  },
  schema: z
    .object({
      email: z.string().email(),
      name: z.string().optional(),
      value: z.number().finite().optional(),
    })
    .catchall(z.unknown()),
  async transform(payload) {
    return {
      event: "lead.submitted",
      userEmail: payload.email,
      properties: payload,
    };
  },
});

contact — jamie@acme.dev

company—via apolloAcme Inc

role—via apolloHead of Growth

company size—via apollo51–200

groupcompany: acme.dev · 4 contacts

buckethigh-fit → welcome journey

fill-if-absent — your own data always wins

What's actually happening

1Any tool that can send a webhook — a form builder, your billing system, anything — becomes a source with one small file like this.
2The payload is checked against a schema first, so junk never reaches your data.
3The event it produces joins the same stream as everything else — and can start journeys on its own.

import { Hogsend } from "@hogsend/client";

const hs = new Hogsend({
  baseUrl: process.env.HOGSEND_API_URL!,
  apiKey: process.env.HOGSEND_DATA_KEY!,
});

// The company behind the person — properties live
// on the account, not just the contact.
await hs.groups.identify({
  groupType: "company",
  groupKey: "acme.dev",
  displayName: "Acme",
  properties: { plan: "scale", seats: 14 },
});

await hs.groups.addMember({
  groupType: "company",
  groupKey: "acme.dev",
  contactId: contact.id,
  role: "admin",
});

contact — jamie@acme.dev

company—via apolloAcme Inc

role—via apolloHead of Growth

company size—via apollo51–200

groupcompany: acme.dev · 4 contacts

buckethigh-fit → welcome journey

fill-if-absent — your own data always wins

What's actually happening

1Groups track the company behind the person — things like plan and seat count live on the account itself.
2Add people to the group and their activity rolls up to the account.
3If PostHog is connected, all of it forwards as group analytics automatically. Without it, groups still work on their own.

import { days, defineBucket } from "@hogsend/engine";

// The segment behind the winback journey — going dormant
// IS the trigger.
export const wentDormant = defineBucket({
  meta: {
    id: "went-dormant",
    enabled: true,
    timeBased: true,
    criteria: (b) =>
      b.all(
        b.event("app.active").exists(),
        b.event("app.active").within(days(7)).notExists(),
      ),
  },
});

src/buckets/went-dormant.ts

trial

sam@

lee@

active

kai@

jo@

dormant

mia@

jo@

entering dormant triggers the win-back journey

What's actually happening

1This file describes who counts as dormant: they were active once, and have been silent for a week.
2Membership updates itself as events arrive — there's no nightly job and no stale list.
3Falling in, or climbing back out, fires an event that other code can react to.

import { days } from "@hogsend/core";
import { defineJourney, sendEmail } from "@hogsend/engine";

export const onboarding = defineJourney({
  meta: {
    id: "onboarding",
    trigger: { event: "user.signed_up" },
    entryLimit: "once",
  },
  run: async (user, ctx) => {
    await sendEmail({ to: user.email, template: "welcome" });

    // Park durably until THIS user creates a project —
    // or 3 days pass. Survives every deploy in between.
    const { timedOut } = await ctx.waitForEvent({
      event: "project.created",
      timeout: days(3),
    });

    await sendEmail({
      to: user.email,
      template: timedOut ? "activation-nudge" : "first-win",
    });
  },
});

a durable run — survives deploys

user.signed_up

trigger

welcome

sendEmail

project.created — 3d timeout

ctx.waitForEvent · survives deploys

timedOut ? activation-nudge : first-win

branch on the answer

What's actually happening

1Someone signs up and this journey picks them up. It runs once per person — the engine makes sure of that.
2The welcome email is a React component living in this same repo, right next to this file.
3Then it waits up to three days for them to create a project. The wait is durable — deploys, restarts, and crashes don't lose their place.
4One plain if/else decides the next email: a nudge if they stalled, a congratulations if they got there.

import { Layout } from "./_components/layout";
import { Body, Button, Title } from "./_components/ui";
import type { WelcomeEmailProps } from "./types";

export default function WelcomeEmail({
  name = "there",
  setupUrl,
  unsubscribeUrl,
}: WelcomeEmailProps) {
  return (
    <Layout
      preview="You're in — here's the fastest path to a first win."
      eyebrow="Welcome"
      unsubscribeUrl={unsubscribeUrl}
    >
      <Title>Welcome, {name}</Title>
      <Body>
        Your workspace is ready. The fastest way to see value
        is to send one event and watch a journey pick it up.
      </Body>
      <Button href={setupUrl}>Send your first event</Button>
    </Layout>
  );
}

a durable run — survives deploys

user.signed_up

trigger

welcome

sendEmail

project.created — 3d timeout

ctx.waitForEvent · survives deploys

timedOut ? activation-nudge : first-win

branch on the answer

What's actually happening

1Emails are React components — you build them the same way you build the rest of your product.
2Props are typed, so a journey passing the wrong data fails the build, not the send.
3The same component previews in Studio and renders to HTML at send time.

import { days } from "@hogsend/core";
import { defineJourney, sendEmail } from "@hogsend/engine";

export const nps = defineJourney({
  meta: {
    id: "feedback-nps",
    trigger: { event: "user.activated" },
    entryLimit: "once",
  },
  run: async (user, ctx) => {
    await ctx.sleep({ duration: days(14), label: "day-14" });

    // The 0–10 buttons in this email are links that fire
    // a real nps.submitted event with the score attached.
    await sendEmail({
      to: user.email,
      template: "nps-survey",
      idempotencyLabel: "nps-survey",
    });

    let answer = await ctx.waitForEvent({
      event: "nps.submitted",
      timeout: days(3),
      label: "await-score",
    });

    if (answer.timedOut) {
      await sendEmail({
        to: user.email,
        template: "nps-survey",
        idempotencyLabel: "nps-reminder",
      });
      answer = await ctx.waitForEvent({
        event: "nps.submitted",
        timeout: days(7),
        label: "await-score-reminder",
      });
    }

    const score = answer.properties?.score;
    if (typeof score !== "number") return;

    if (score <= 6) {
      // Another journey picks the save attempt up from here.
      await ctx.trigger({
        event: "nps.detractor",
        userId: user.id,
        properties: { score },
      });
    }
  },
});

a durable run — survives deploys

user.signed_up

trigger

welcome

sendEmail

project.created — 3d timeout

ctx.waitForEvent · survives deploys

timedOut ? activation-nudge : first-win

branch on the answer

What's actually happening

1Two weeks in, the survey goes out. The 0–10 buttons are just links — clicking one fires a real event with the score attached.
2The journey waits for that click and reads the score straight off it. No form to build, no webhook to wire.
3No answer after three days? One reminder. The label on each send means a crashed worker can never send it twice.
4A low score hands the person to a separate save journey — automatically.

import { days } from "@hogsend/core";
import { defineJourney, sendEmail } from "@hogsend/engine";

export const weeklyDigest = defineJourney({
  meta: {
    id: "weekly-digest",
    trigger: { event: "feature.used" },
    entryLimit: "unlimited",
  },
  run: async (user, ctx) => {
    // Absorb a rolling 7-day window of feature.used
    // into ONE execution — a busy week is one email.
    const digest = await ctx.digest({
      window: days(7),
      label: "weekly-activity",
    });

    // A week is a long wait — re-check consent first.
    if (!(await ctx.guard.isSubscribed())) return;

    // Batching is plain TypeScript over the window.
    const byFeature = Object.groupBy(digest.events, (e) =>
      String(e.properties?.feature ?? "Other"),
    );

    await sendEmail({
      to: user.email,
      template: "weekly-digest",
      props: {
        stats: Object.entries(byFeature).map(
          ([label, ev]) => ({ label, value: ev?.length }),
        ),
      },
    });
  },
});

a durable run — survives deploys

user.signed_up

trigger

welcome

sendEmail

project.created — 3d timeout

ctx.waitForEvent · survives deploys

timedOut ? activation-nudge : first-win

branch on the answer

What's actually happening

1Someone uses a feature and the journey starts collecting. Everything they do for the next seven days folds into one email instead of seven.
2Before sending, it re-checks they're still subscribed — a week is a long time.
3The summary itself is plain TypeScript: group the week's events however you like.

import { defineJourney, sendEmail } from "@hogsend/engine";
import { wentDormant } from "../buckets/went-dormant";

// Bucket → journey composition: falling into the
// bucket starts the sequence, leaving it ends it.
export const winback = defineJourney({
  meta: {
    id: "winback",
    trigger: { event: wentDormant.entered },
    // The moment they act again they leave the
    // bucket — and this run exits cleanly.
    exitOn: [{ event: wentDormant.left }],
  },
  run: async (user, ctx) => {
    await sendEmail({
      to: user.email,
      template: "reactivation-checkin",
    });
  },
});

src/buckets/went-dormant.ts

trial

sam@

lee@

active

kai@

jo@

dormant

mia@

jo@

entering dormant triggers the win-back journey

What's actually happening

1This journey starts the moment someone falls into the dormant lane — the bucket itself is the trigger, and a typo'd bucket name fails the build.
2If they come back, they leave the bucket and the journey ends itself — even mid-wait.
3No scheduler, no segment sync: the lane movement is the automation.

import { defineJourney, sendEmail } from "@hogsend/engine";

// Subject-line A/B without an external experiment tool.
export const welcomeExperiment = defineJourney({
  meta: {
    id: "welcome-experiment",
    trigger: { event: "user.signed_up" },
    // Converted? Out instantly — mid-sequence, anywhere.
    exitOn: [{ event: "subscription.created" }],
  },
  run: async (user, ctx) => {
    // Deterministic per user — recorded on first pass,
    // replayed verbatim across redeploys. No RNG, no drift.
    const arm = await ctx.variant("subject", [
      "subject-a",
      "subject-b",
    ]);

    await sendEmail({
      to: user.email,
      template: arm === "subject-a" ? "welcome" : "first-win",
    });
  },
});

impact — goal: credits-purchased · 90d

causal +111.8% · 100% win probability

entered (85%)660 contacts · 46.8%

held out (15%)95 contacts · 22.1%

Attributed revenue · blended, fractional

activation-nudge$12,370

activation-connect-repo$11,357

welcome$7,899

What's actually happening

1Half of new signups get one version, half get the other — decided per person, no external A/B tool.
2The split is stable: a redeploy or crash can never flip which version someone is in.
3The moment someone subscribes, they leave the experiment — no more test emails mid-checkout.
4The results read side by side in Studio, with revenue attached.

import { days } from "@hogsend/core";
import { defineJourney, sendEmail } from "@hogsend/engine";

export const winback = defineJourney({
  meta: {
    id: "winback",
    trigger: { event: "user.dormancy_detected" },
    entryLimit: "once_per_period",
    entryPeriod: days(60),
    // 15% never get the message — the baseline
    // your lift number is read against.
    holdout: { percent: 15 },
    // Credit is scoped to money, not opens.
    goal: "revenue",
  },
  run: async (user, ctx) => {
    await sendEmail({
      to: user.email,
      template: "reactivation-checkin",
    });

    await ctx.sleep({ duration: days(7), label: "day-21" });

    if (user.properties.plan === "paid") {
      await sendEmail({
        to: user.email,
        template: "winback-offer",
      });
    }
  },
});

impact — goal: credits-purchased · 90d

causal +111.8% · 100% win probability

entered (85%)660 contacts · 46.8%

held out (15%)95 contacts · 22.1%

Attributed revenue · blended, fractional

activation-nudge$12,370

activation-connect-repo$11,357

welcome$7,899

What's actually happening

115% of eligible people never get the emails. That's the control group — built in, one line.
2The goal is revenue, so the comparison is money made, not emails opened.
3Too few conversions to trust? Studio says “collecting” instead of showing you a fake percentage.
4And nobody gets worked more than once every 60 days.

import { defineFunnel } from "@hogsend/engine";

// The path to revenue, written as the events
// you already send. No query builder.
export const trialFunnel = defineFunnel({
  id: "trial",
  name: "Trial to paid",
  stages: [
    { id: "signed_up", on: "user.signed_up" },
    { id: "activated", on: "project.created" },
    { id: "trial_started", on: "trial.started" },
    {
      id: "subscribed",
      on: "subscription.created",
      milestone: "won",
    },
  ],
  // Only ever closes a deal that was actually open.
  lostOn: "trial.expired",
});

studio — deals

qualified

Acme$4.2k

Kite$1.8k

proposal

Nova$6.5k

won

Rove$3.1k

every email, SMS, and DM on the deal's timeline

What's actually happening

1The path to revenue, written as events you already send: sign up, activate, start a trial, subscribe.
2Deals move stage when their event fires. Browser events can't forge a move — only trusted server sources count by default.
3subscription.created is the money stage — that's what the revenue readouts count as won.
4An expiring trial marks the deal lost, but only a deal that was actually open.

import { Hogsend } from "@hogsend/client";

const hs = new Hogsend({
  baseUrl: process.env.HOGSEND_API_URL!,
  apiKey: process.env.HOGSEND_DATA_KEY!,
});

// A one-off send you drive by hand — to a list,
// or to a LIVE bucket.
const { campaignId, status } = await hs.campaigns.send({
  name: "March launch",
  list: "product-updates",         // or a live bucket
  template: "launch-announcement", // typed vs your registry
  props: { feature: "Flags" },
  sendAt: "2026-08-01T09:00:00Z",  // omit to send now
});

studio — deals

qualified

Acme$4.2k

Kite$1.8k

proposal

Nova$6.5k

won

Rove$3.1k

every email, SMS, and DM on the deal's timeline

What's actually happening

1A broadcast is a one-off send you drive by hand — to a list, or to a live bucket like “went dormant”.
2The audience is whoever is in the lane at send time, not a stale export.
3The template and its props are typed — a mistake fails the build, not the send.
4Schedule it with a date, or leave it off to send now. Either way it lands in the same stream and earns revenue credit like everything else.

import { defineFlag } from "@hogsend/engine";

// Flags live in your repo — typed, reviewed, deployed.
export const newCheckout = defineFlag({
  key: "new-checkout-flow",
  name: "New checkout flow",
  type: "boolean",
});

// In React — the same shape as PostHog's hook:
// const enabled = useFlag("new-checkout-flow");

studio — deals

qualified

Acme$4.2k

Kite$1.8k

proposal

Nova$6.5k

won

Rove$3.1k

every email, SMS, and DM on the deal's timeline

What's actually happening

1Feature flags live in the repo, next to the journeys and pages they gate.
2In React they read exactly like PostHog's hook — one line.
3One flag can gate an email, a page, or a whole branch of a journey.

{
  "mcpServers": {
    "hogsend": {
      "command": "npx",
      "args": ["-y", "@hogsend/mcp"],
      "env": {
        "HOGSEND_API_URL": "https://api.your-instance.com",
        "HOGSEND_ADMIN_KEY": "hsk_…"
      }
    }
  }
}

studio — deals

qualified

Acme$4.2k

Kite$1.8k

proposal

Nova$6.5k

won

Rove$3.1k

every email, SMS, and DM on the deal's timeline

What's actually happening

1Point your coding agent at the engine and it can operate it: draft journey blueprints, pull reports, inspect what's running.
2Risky actions stay operator-gated — an agent can prepare a test send, but a human approves it.
3Works over stdio here, or hosted at /v1/mcp — Claude, Cursor, anything that speaks MCP.

also reading the stream: groups · destinations · agents & MCP

Reach them where they are

Steer it from Studio

studio — a live instanceopen demo.hogsend.com →

Journeys

Visual flowcharts, live stats, experiments and conversions for every line of code.

Impact

Understand how your automations and experiments are driving growth with a best-in-class attribution engine.

Deals

Design powerful pipelines and GTM functions powered by the same events you collect.

Agent-native

Put your growth machine on autopilot.

Your coding agent works where your lifecycle does: inside your codebase. Ask for an outcome and it can write, modify, and validate the journey without another drag-and-drop builder.

Plain TypeScript surface

Journeys are defineJourney() files. Claude Code, Cursor, or any agent writes and modifies them like any other code.

export const onboarding = defineJourney({

trigger: { event: "user.signed_up" },

run: async (user, ctx) => { … },

});

Validated by your type-checker

No drag-and-drop canvas to drift out of date — the compiler rejects a journey that references a template that doesn't exist.

# pre-push

$ pnpm check-types

✓ journeys/welcome.ts

✓ journeys/winback.ts — 0 errors

A CLI agents can drive

hogsend skills plus --json on every command give agents a first-class interface to inspect and operate the running system.

$ hogsend journeys --json

[ { "id": "onboarding", "status": "registered" } … ]

Or authored at runtime

Journey Blueprints

Agents author journeys as JSON — stored in your database, enrolling users without a deploy. Review and enable them in Studio. When one earns permanence, hogsend blueprints promote turns it into a code journey in your repo.

MCP server

npx @hogsend/mcp connects Claude Desktop, Cursor, or claude.ai to your running instance. Create blueprints, run health reports, send test emails — your admin key, your infrastructure.

LLMs write and modify journeys like any other code in your repo

Claude CodeCursorCopilotOr any agent you prefer

Use cases

The journeys every product should run — shipped by default.

Welcome / onboarding. Greet people the moment they sign up, then branch on whether they've actually tried anything yet.

Activation nudge. Drive the one action most correlated with sticking around — before the trial clock runs out.

Feature adoption. Most churn is a feature users never found. Surface the one they're missing.

Trials that convert. Match the ask to how much they've really used, not the day on the calendar.

Payment saves. Involuntary churn is the biggest leak you can plug. Remind, and stop the moment it clears.

Win-backs. You already paid to acquire them once — winning them back costs a fraction of a new signup.

Milestones. Celebrate progress and reinforce the habit at the moments value actually lands.

Referrals. Ask for the referral at the moment value lands, when they're most likely to say yes.

Deep dive

Onboarding

Welcome flows that branch on what new users actually do.

Deep dive

Trial conversion

Usage-driven nudges that stop the moment they pay.

Deep dive

Win-back

Spot who's gone quiet and bring them back.

Deep dive

Community

Read Discord activity off the same contact as your product.

Every journey here sends one of 13 React Email templates in the scaffold → · copy-paste variants for all of these live in the 35-recipe cookbook →

Get set up

Start with one command. pnpm dlx create-hogsend@latest . Everything below ships with it, in v0.59.0.

pnpm dlx create-hogsend@latest .

create-hogsend

Run the scaffolder yourself: pnpm dlx create-hogsend@latest .

01/ 08Video

Hogsend Video

Every video becomes an event stream. This player is @hogsend/video. Press play — the feed beside it is the events it captures.

Elena Verna, Head of Growth at Lovable, on Lenny's Podcast. Played through our own @hogsend/video; press play and the real watch-depth events replace the loop. All our React components →

@hogsend/videostandby

Watch-depth events from the player, streaming live.

Depth that survives scrubbing

percentWatched is the deepest point reached — monotonic, so skipping back and forth never inflates it.

Milestones fire once

video.progress lands a single event at 25, 50, 75, and 90 percent, alongside started, completed, and replay.

One event shape, any player

YouTube, Vimeo, and native <video> emit the same events, so journeys never care where the video lives.

Emitters, not lock-in

createHogsendEmitter feeds your journeys; the same interface writes to PostHog or GA4, or all of them combined.

Watch depth is a journey trigger like any other event — the retargeting play in the playbook runs on it.

Read the video docs →

02/ 08Feature flags

Feature flags

Customize the whole journey with feature flags. Flip any part of your marketing on or off, anytime.

Native, DB-backed flags, evaluated against your Hogsend contacts by the same targeting engine that runs your journeys. One flag can swap a headline, a video, an email, or a whole branch of a journey. Flip the arms below and the page reacts, running on the real API on the right.

Lifecycle without the hire

Onboarding, trials, and win-back ship as code your agents extend, with no lifecycle team to staff.

visitor-teammultivariate

One arm per visitor. Your targeting rules choose it in production; flip the arms here to preview.

import { useFlag } from "@hogsend/react";

export function Hero() {
  // One flag decides who's reading. Sticky per visitor, no redeploy.
  const team = useFlag("visitor-team");

  return <TeamHero team={team} />; // swaps the video + the pitch
}

evaluated for you

visitor-team→"founder"

One definition, read everywhere. The same evaluation runs in the browser, on the server, and inside a journey. Already run PostHog flags? Keep them and read them right beside these.

Read the flags docs →

03/ 08Groups

Contact groups

Bill, Derek, and Bob all work at Acme. Hogsend can treat them as one account.

Contact groups roll individual activity up to the company, team, or workspace it belongs to. One call associates a contact with a group; every event they fire carries the association, membership accrues automatically, and the account reads back as one entity in Studio.

Acme Inc

pro

Company · acme.com · ID: grp_8f4a72e9

Members

350%

vs last 30 days

MRR

$4.2k8.3%

vs last 30 days

Customer since

Mar '25

32 days

Health score

Excellent

6 pts

Usage & Health

Seats used42 / 50

Feature adoption78%

Account health92%

Team engagement68%

Activity (events)

Last 30 days

1.5k1k5000

1,240

Apr 19Apr 26May 3May 10May 17

Properties

Planpro

Seats42

IndustryDeveloper tools

Regionus-east-1

Member	Email	Events (30d)	Last seen	Role
Bill Chen	bill@acme.com	1,24018%	2h ago	admin
Derek Vaughn	derek@acme.com	4306%	1d ago	member
Bob Portis	bob@acme.com	2104%	3d ago	member

The email answers back. Send surveys, questions and buttons in your email.

Every link in every email is rewritten to your own domain at send time, so opens and clicks are tracked first-party — no provider pixels. An EmailAction goes further: the click emits a named event with properties, and a waiting journey reads the answer directly.

to: founder@acme.dev

subject: Quick check-in on your trial

Hey — you're a week into the trial. One click tells us where you are, straight from this email:

Each button is an EmailAction — a link whose click emits trial.check_in with its answer. First click wins.

trial-check-inwaiting

Sent through the tracked mailer: every link rewritten to your domain, opens and clicks first-party.

email.senttrial-check-in
links rewritten/v1/t/c/9f2c…
open pixel/v1/t/o/58d1…
ctx.waitForEventtrial.check_in · 3d

the journey hears

ctx.waitForEvent→waiting for founder@acme.dev…

05/ 08Links

Tracked links + QR

Tracked Links & QR Codes. Mint a link, get a QR code, put it on anything.

Every managed link gets a vanity slug, first-party click tracking, and a print-ready SVG or PNG QR code from the API. Scans count separately from clicks, a personal link identifies the scanner, and because the QR encodes a durable engine URL you can re-point a printed code any time.

spring-mailertracked link

Minted with one call, hs.links.create() or the Studio Links view. SVG and PNG QR straight from the API.

One code on 5,000 postcards. A public link never carries a person — scans count separately from web clicks, so the mailer reports like a channel.

1,204

qr scans

310

web clicks

9.8%

scan rate

on scan

link.clicked · source: "qr"→ journey enrolled

Direct mail, conference badges, packaging — anything you can print becomes a journey trigger.

Read the direct-mail play →

06/ 08Discord

Community channel

Your Discord is a lifecycle channel, too. Connect a Discord account to a user on your app.

The bot verifies through their inbox — a one-click emailed confirm, never the Discord-reported address. From then on messages and reactions keep a last-seen on the contact, and a journey can send a DM the same way it sends an email, gated on the member’s channel preference.

generalyour server

jamie11:12 AM

/link

Message #general

GIF

discord-connectlive flow

One slash command folds a Discord account onto the contact — verified through their inbox, never the Discord-reported email.

contact

emailjamie@northwind.io

discord_id—

isDiscordLinked—

last_seen—

on the wire

POST /interactionsed25519 verified

Built for community-led companies — the channel your users actually read, wired into the same journeys as email and SMS.

Read the Discord docs →

07/ 08Impact

Impact experiments

Every journey change is an experiment. So prove it moved the number.

Ship two versions of a journey to a randomised split, hold back a control, and Hogsend measures the goal event against it. You get the incrementality — the welcome series raised activation, and by how much — not a guess.

activation-welcomelive test

Every version ran against a holdout. Select one to read the lift it measured on the goal event.

primary goal

activation

significant

+22%

activation lift vs holdout

96%

confidence

8,412

enrolled users

14 days

experiment window

readout · v3

activation.completed→"+22% vs holdout"

Illustrative readout — the report Hogsend generates from your own journeys and goals.

Version the journey
Every edit is a version. Run the new one against the last — no separate tool.
Split with a holdout
A randomised share gets the change; a control gets nothing to measure against.
Read the lift
The goal event, measured against the control, with a confidence you can act on.

Know which edit moved the number

You reworked the welcome series three weeks ago — did it work? Every enrollment carries a fingerprint of the journey code that created it, so the readout splits before-vs-after on its own. No tagging, no spreadsheet archaeology.

meta.version

Split-test without an experiment platform

One call inside the journey assigns each user an arm — sticky across retries and redeploys, no assignment service to run. The readout reports every arm against the same control.

ctx.variant

Proof, not attribution flattery

Opens and clicks can't tell you what would have happened anyway. Hold back 10% as a control and the lift is measured against people who got nothing — the only number allowed to say "caused".

meta.holdout

It won't let you fool yourself

A +40% on twelve users is noise. Under 10 conversions the verdict stays "collecting" — never a percentage; small cohorts ship flagged. You act when the number can carry the decision.

smallSample

Attributed, influenced, and incremental stay separate numbers — only the holdout-backed one may say "caused". Already live? hogsend attribution backfill credits your whole history.

Read the impact docs →

08/ 08Event plugins

Event plugins

People do more than click emails. Payments, sign-ups, support threads, SMS replies — and more to come.

There’s one plugin system behind all of these — webhook presets in the engine, @hogsend/plugin-* packages beside it, built in the open in the same repo. Signals land as first-class events that trigger, branch, or exit a journey; the CRM and ads legs carry conversions back out.

Stripe
Clerk
Supabase
Segment
Intercom & Fin
Vapisoon
Stripe
Clerk
Supabase
Segment
Intercom & Fin
Vapisoon

Twilio
Discord
Telegram
PostHog
Resend
Crispsoon
Twilio
Discord
Telegram
PostHog
Resend
Crispsoon

Postmark
HubSpot
Attio
HighLevel
Meta CAPI
Slacksoon
Postmark
HubSpot
Attio
HighLevel
Meta CAPI
Slacksoon

Every preset is defineWebhookSource() under the hood — a source we don’t ship is a transform function away.

See all integrations →

Try it live

We use Hogsend to power hogsend.com.

Sign up below. Our own Hogsend install sends the welcome email and powers the feed, bell, survey, and branching that follows.

hogsend.com — live demo

live

Loading your session…

This isn’t a mock — it’s our own install, a stock create-hogsend app in production. The welcome email arrives from hello@hogsend.com in seconds; the feed, bell, and survey card are real @hogsend/react components. See the full set →

The elephant in the room

Why not just use PostHog Workflows? Sometimes you should.

Workflows is genuinely good. It lives in the PostHog UI your team already has open, consumes the events you already capture, and needs nothing deployed. And it isn't either/or — both run off the same PostHog events. Hogsend amplifies everything PostHog does.

What Workflows does well

Zero extra infrastructure. A tab in the PostHog UI your team already has open, consuming the events you already capture — nothing to deploy, nothing to operate.

Multi-channel out of the box. Email, SMS, push, Slack, and webhooks without writing a line.

Non-engineers can ship. The no-code canvas means whoever owns lifecycle can see and edit the flow — no developer in the loop.

A genuinely generous free tier. Light volume fits inside it; after that it's per-send pricing on top of your PostHog bill.

Why you'd reach for Hogsend

The flow is code you own. Versioned completely — git log knows who changed the discount email and why. PR review, tests, and rollback apply like everywhere else.

Your domain, your reputation. Sends go through your own Resend or Postmark account, not a managed sender.

Past the canvas ceiling. Park until this user acts, send in their timezone, trigger journeys from journeys, cap re-entries — control flow boxes and arrows can't express.

Integrate any service. A journey is an async TypeScript function — call any API you can import, or an LLM mid-run, and branch on the answer.

They scratch different itches. If you want a drag-and-drop editor, Workflows has you covered — you're here because you'd rather build marketing in, as a developer or a product-first engineering team. If you're a PostHog team, or about to become one, use each where it fits.

Read the full comparison

Durable execution, by Hatchet.

Every journey runs on Hatchet, the durable execution engine underneath Hogsend. It's what lets a long ctx.sleep survive a deploy and resume two days later exactly where it left off. Hogsend builds on Hatchet rather than rolling its own durability.

Survives deploys & restarts

A long ctx.sleep keeps running across a deploy and resumes days later, exactly where it left off.

Automatic retries & timeouts

Failed steps retry and waits expire on their own — durability you don't have to hand-roll.

Self-host it, or use Hatchet Cloud

Run Hatchet-Lite next to your app, or point at Hatchet Cloud. Same engine either way.

Economics

What it costs. Contact count appears in neither bill.

There is no paid tier. You pay for hosting — the Railway template provisions Postgres, Redis, Hatchet, the API, and the worker — and for your own Resend or Postmark account.

HogsendSelf-hosted · $0 software

Software$0, ELv2

Hostingyour infrastructure

Sendingyour Resend / Postmark

Per contactnothing

LoopsSubscribed contacts

5,000 contacts$49/mo*

50,000 contacts$249/mo*

Sendingtheir infrastructure

Grows withyour list

Customer.ioProfiles + emails + credits

Billingper profile + volume

At scalecustom pricing

Sendingtheir infrastructure

Grows withyour list

PostHog WorkflowsPer message sent

Free tier10k msgs/mo*

After that$0.003/send*

Sendingmanaged sender

Grows withsend volume

*Published pricing, checked July 2026.

Have it built and run for you →Full pricing

FAQ

Find what you need.

Is Hogsend open source?

Hogsend is source-available under the Elastic License 2.0 (ELv2). You can read, modify, and self-host all of it for free; the only restriction is offering Hogsend itself as a managed service.

What does Hogsend cost?

The software is free — there is no paid tier. You self-host and pay only your own infrastructure plus your Resend or Postmark account. No per-contact, per-profile, or per-send fees.

How is Hogsend different from PostHog Workflows?

Workflows is PostHog's built-in no-code canvas with a managed sender. Hogsend is typed TypeScript in your repo with durable waits, behavioral branching, and your own email provider — for when lifecycle logic outgrows boxes and arrows.

Does Hogsend replace Resend or use it?

It uses it. Hogsend is the orchestration layer — journeys, segments, suppression, tracking — and sends through your own Resend account by default, with Postmark as a one-env-var swap. Resend's own Automations cover simple dashboard-built sequences; Hogsend is for when the logic belongs in your repo — event-triggered, type-checked, and portable across providers.

Do I need PostHog to use Hogsend?

No. Send first-party events directly with @hogsend/js or the Data API, use signed webhook presets for Stripe, Clerk, Supabase, or Segment, or define any custom source. PostHog is a first-class optional integration.

Will my emails survive a deploy mid-journey?

Yes. Journeys run as Hatchet durable tasks: a user three days into a seven-day wait keeps waiting through deploys, restarts, and crashes, and resumes exactly where they were.

Can AI agents write Hogsend journeys?

Yes — journeys are plain TypeScript files, so coding agents can read your product events and types, write or modify a journey, and leave you a reviewable diff. Your type-checker validates it before it ships.

Get started

First send in minutes.

One prompt scaffolds the app, Docker, env, and ten journeys — the welcome series included. Your agent reads the docs and does the rest.

your agent, one prompt

❯Visit hogsend.com/docs and implement lifecycle marketing for our product — start with the welcome series.

Paste into your coding agent

Superpowers for growth engineers.

WhenWhenlifecyclelifecycleliveslivesininyouryourcodebase,codebase,everyeveryleakleakisisfixable.fixable.When lifecycle lives in your codebase, every leak is fixable.

Journeys as code

Your provider, your reputation

Durable execution

Put your growth machine on autopilot.

Plain TypeScript surface

Validated by your type-checker

A CLI agents can drive

Journey Blueprints

MCP server

The journeys every product should run — shipped by default.

Onboarding →

Trial conversion →

Win-back →

Community →

Start with one command. pnpm dlx create-hogsend@latest . Everything below ships with it, in v0.59.0.

Every video becomes an event stream. This player is @hogsend/video. Press play — the feed beside it is the events it captures.

Depth that survives scrubbing

Milestones fire once

One event shape, any player

Emitters, not lock-in

Customize the whole journey with feature flags. Flip any part of your marketing on or off, anytime.

Lifecycle without the hire

Bill, Derek, and Bob all work at Acme. Hogsend can treat them as one account.

The email answers back. Send surveys, questions and buttons in your email.

Tracked Links & QR Codes. Mint a link, get a QR code, put it on anything.

Your Discord is a lifecycle channel, too. Connect a Discord account to a user on your app.

Every journey change is an experiment. So prove it moved the number.

Version the journey

Split with a holdout

Read the lift

Know which edit moved the number

Split-test without an experiment platform

Proof, not attribution flattery

It won't let you fool yourself

People do more than click emails. Payments, sign-ups, support threads, SMS replies — and more to come.

We use Hogsend to power hogsend.com.

Why not just use PostHog Workflows? Sometimes you should.

Durable execution, by Hatchet.

Survives deploys & restarts

Automatic retries & timeouts

Self-host it, or use Hatchet Cloud

What it costs. Contact count appears in neither bill.

Find what you need.

First send in minutes.

Whenlifecyclelivesinyourcodebase,everyleakisfixable.When lifecycle lives in your codebase, every leak is fixable.

Onboarding

Trial conversion

Win-back

Community