Skip to content

Which pricing and packaging changes would lift Workflows' growth ceilings? #217

Closed

Description

@Silthus

Part of #210

Question

Which pricing and packaging changes would lift Workflows' growth ceilings? Recommendations only: this map changes no prices.

  • How each channel and recipient type is metered today (email, SMS, push, cc and bcc recipients, workflow invocations), and whether the sending cap and billing count the same thing.
  • Whether the sending tier should show in the UI, and whether caps should follow the PostHog plan.
  • How Customer.io, Loops and Resend price and package the same jobs (public pricing pages).

Answer with a short list of recommendations for billing and leadership, each with its reasoning. Code and public pricing pages only.

Activity

  1. self-assigned this
    on Oct 3, 2026
  2. Silthus commented on Oct 3, 2026

    @Silthus
    OwnerAuthor

    Claimed by a Claude Code research worker (Opus 5.5)

  3. removed their assignment
    on Oct 3, 2026
  4. Silthus commented on Oct 3, 2026

    @Silthus
    OwnerAuthor

    Lane orphaned: the worker's temporary worktree was removed while its sub-agents ran. Unassigned; the conductor redispatches it in a persistent worktree.

  5. self-assigned this
    on Oct 3, 2026
  6. Silthus commented on Oct 3, 2026

    @Silthus
    OwnerAuthor

    Claimed by a Claude Code research worker (Opus 5.5), redispatch

  7. Silthus commented on Oct 3, 2026

    @Silthus
    OwnerAuthor

    Resolution

    Evidence: the code on master and the public pricing pages of PostHog, Customer.io, Loops and Resend. Guesses are marked as guesses. Full findings with sources: https://github.com/Silthus/posthog/blob/research/pricing-packaging/research-pricing-packaging.md

    What the code shows

    • One email is counted three ways: billing counts one per send step, the sending cap counts each to, cc and bcc recipient, and the Reputation tab meter counts one per send.
    • Only email and destinations have a public price. SMS has a usage key but no price, quota or billing view. Push bills and is limited as a destination.
    • A spent email quota blocks every run of a flow that has an email step, even runs that only reach a webhook.
    • The sending tier ignores the plan. Every new team starts at 100 emails a day, below its own 10,000 free emails a month. The tier shows on the Reputation tab only.
    • Reading the code, a send that ends in a provider error, such as an unverified domain, seems to bill. Not yet confirmed by a test.

    Recommendations for billing and leadership

    1. Let a paying team start above the lowest sending tier (guess: tier 1 or 2). Tier 0 caps a team below its free allowance, and Customer.io switchers arrive with a real list. Resend lifts its daily quota on any paid plan. Reputation-driven demotion stays as it is.
    2. Show the sending allowance where it limits someone, for example when picking a batch audience or when a workflow slows down, with the way to raise it.
    3. When a quota runs out, block only the channel that ran out, and show the upgrade path. Today the whole workflow stops without a visible reason.
    4. Count one email the same way everywhere, per delivered recipient, so the cap, the meter and the bill agree. Resend and SES count each recipient.
    5. Charge only for sends the provider accepted. Confirm the failed-send billing with a test first.
    6. Decide a price and a quota for SMS and push, and make the quota check match the bill. A simple option (guess): price both as destination dispatches, since the carrier cost sits with the customer.
    7. Review the entry price per email, and lead with "no per-contact pricing". The first paid tier is $3 per 1,000 emails, against $20 for 50k at Resend Pro. PostHog is the only one of the four that does not charge for contacts.
    8. Consider a larger free allowance paid for by a "Sent with PostHog" footer, as Loops does. Removable on paid plans.
    9. Consider bring-your-own sending as a paid lever for Customer.io switchers. A team on its own sending provider carries its own reputation and could skip the shared-pool ramp. This is a separate bet, not a pricing change alone.

    Re-check every guess against real usage data after 2026-11-02, in the private note.

    Security note, ask Michael.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions