The canon · Post 01

Revenue. Get paid, keep getting paid, get paid more.

Revenue is the first Post most founders feel. Get paid, keep getting paid, get paid more. At $5K to $500K ARR, the revenue layer is failed-payment recovery, renewal preparation, expansion detection, and trial conversion — four moves the founder rarely has time to do well by hand. The Revenue Post is what every micro-SaaS converges on once growth becomes operational instead of motivational.

The problem

What's actually going wrong.

Every SaaS at our scale loses 5–10% of monthly revenue to failed payments. Stripe's smart retries help; Churnkey-style dunning workflows help more; an opinionated email layer that reads each customer's history before drafting a recovery note helps most of all. But solo founders running $5K–$500K ARR almost never have all three working together, because the operational layer that ties them is what they don't have time to build.

The pattern repeats across the Revenue surface. Annual renewals slip because the founder forgot to send the 14-day touchpoint. Expansion conversations don't happen because the usage spike that warranted one was buried in three other dashboards. Trial-to-paid conversion tops out at 8% when the day-7 email that would have lifted it to 12% is the email the founder kept meaning to write.

These aren't strategic problems. They're operational ones. The strategic answer — "have a renewal cadence," "detect expansion," "recover failed payments" — is well-known. The operational answer — "write the renewal email, send it on time, log who paid late and why" — is the work the founder doesn't have a spare hour for. By month six of running the business, the founder has internalized that these things matter and also that none of them are getting done. That's the Revenue Post problem.

Most founders try to fix it with tooling: Churnkey for dunning, Profitwell for retention, Smart Retries on Stripe, a Notion table of renewal dates. Each one solves a slice. None of them tie the slices together with the customer's history and the founder's voice. The result is a stack of tools doing 60% of the job each, none of them actually shipping a recovery email when a payment fails.

Porchops is the operational layer that ties them. Stripe stays as the rails. The customer graph stays as the source of truth. Lou and Cleo are the agents that read both, draft the right email, and either send it or hand it to the founder for one-click approval. The Revenue Post stops being a list of things the founder meant to do and starts being the work the back office actually shipped this month.

Why now

Why this matters in 2026.

OpenAI shipped Workspace Agents in April 2026. Anthropic, Google, and Microsoft will follow within six months. The horizontal AI layer is becoming a utility — every desk worker will have a generic agent that can read calendars and draft emails. What that doesn't solve is the operational layer for solo SaaS founders running their own businesses on their own data.

The 5–10 million micro-SaaS founders who shipped products on Lovable, Replit, v0, Bolt, Bubble, and Cursor have customers, MRR, and an inbox of customer support that needs answering. They don't have engineering teams. They don't have operations teams. They don't have the budget to subscribe to four different SaaS products to handle the operational layer. They need the back office that does the things the back office is supposed to do — and they need it pre-configured.

Revenue is the urgent surface because revenue is what shuts the business down when it doesn't work. A solo founder can survive a month without an updated changelog. A solo founder can survive a quarter without a polished status page. A solo founder cannot survive six months of failed payments going un-recovered. The MRR that walks out the door to dunning never comes back, and by month nine the founder is asking why they're not growing despite acquiring 40 new trial signups in March.

This is why the Revenue Post is the wedge. It's the thing every solo SaaS founder feels first, fixes last, and would happily pay for if a credible operational layer existed. Porchops is that layer. Lou owns the failed-payment recovery; Cleo owns the renewal preparation and expansion detection; Maggie owns the trial-to-paid conversion. Together they cover the four corners of the Revenue Post, and together they ship the work the founder kept meaning to do.

What data it needs

The five inputs.

The Revenue Post needs five data sources to operate well. Stripe is the primary one — payment_intent events, invoice events, customer records, subscription state. Without Stripe data, Lou has nothing to recover from and Cleo has nothing to renew.

The customer graph is the second. Tenure, MRR, prior failure history, support tickets, last-7-days usage. The customer-graph view is what makes a recovery email read like the customer matters; without it, every recovery email is a generic dunning note.

Email is the third — both the inbound (Frankie classifying customer questions about billing) and the outbound (Lou and Cleo's drafts going out from the founder's address). The email layer is what most stack-of-tools approaches miss; the recovery email matters more than the retry logic.

Founder voice is the fourth. Lou and Cleo learn from the founder's previous emails so the drafts read like the founder. Three to five edits is usually enough for the voice to align closely. Without voice consistency, the recovery emails feel like marketing automation.

Decline codes from Stripe are the fifth. Hard decline (card closed) gets different copy than soft decline (insufficient funds), which gets different copy than expired card. The four-bucket classification is conservative and based on what works for $5K–$500K ARR SaaS recoveries; the mapping is configurable per founder.

Services that do it well

What's already on the market.

The market has good players. Naming them is healthy — most micro-SaaS founders have used at least two of these and porchops fits alongside them, not against them.

  • stripe smart retries

    Stripe's built-in retry logic. Reads decline codes, retries on optimal cadences (immediate, 24-hour, 72-hour, 7-day). Free with Stripe. Doesn't draft emails, doesn't read customer history. Useful as the underlying retry layer.

  • churnkey

    Churn prevention with cancel-survey logic, in-product offers, and customizable dunning workflows. Strong on the win-back surface; less opinionated on the email-content layer. Pairs well with porchops if you've already invested in Churnkey's cancel flows.

  • churn buster

    Email-driven dunning with customizable templates and lifecycle awareness. Good template library; less reading of customer-graph-level history. Solid choice if you want template flexibility but don't need contextual drafting.

  • flycode

    AI-driven retry strategy with bank-level decline-code intelligence. Strong on the technical retry layer; pairs with Stripe rather than replacing it. Less focused on the customer relationship after the recovery succeeds or fails.

  • stunning

    Founder-friendly dunning emails with payment-update reminders. Good at the basics. Less depth on lifecycle context.

  • profitwell (paddle studios)

    Retention metrics, cohort analysis, dunning. Strongest on the analytics layer; less opinionated on the operational draft-and-send.

  • porchops

    Lou drafts cause-matched recovery emails after Stripe's retries; Cleo handles renewal touchpoints and expansion detection. The email layer reads the customer graph before drafting. Configuration not code; pre-built playbooks; founder approval thresholds. Does the emails the way you'd do them yourself if you had the time, in a stack with whatever you already have.

The porchops minimum

What we actually do.

What Lou actually does: reads payment_intent.payment_failed webhooks from Stripe, pulls the customer's full record (tenure, MRR, prior failure history, lifecycle stage), identifies the failure cause from the decline code, drafts a contextual email that matches the cause and the customer's history, lands the draft in the founder's inbox via the porchops dashboard. The founder reviews and sends with one click, or sets a configurable auto-send threshold.

What Cleo does: tracks renewal dates 30/14/3 days out, drafts personalized renewal touchpoints based on the customer's tenure and usage trajectory, watches for expansion signals (usage spikes 50% over rolling baseline) and flags accounts worth a conversation. The founder edits or approves; the email goes from the founder's address.

What Maggie does (Customers Post, but supports Revenue): nudges trial users on day 1, day 7, and day 14 with messages personalized to where they are in the product. A user who connected Stripe but hasn't configured Lou yet gets a different day-7 note than a user who's already shipped a recovery and is exploring Cleo.

What porchops does together: ties Stripe data, customer-graph history, and email drafting into one operational layer. The founder sets guardrails — auto-send thresholds, customer-tenure thresholds, escalation rules, daily volume caps — and the crew operates inside them. Every action is auditable and explainable. Six months in, the audit log tells you which dunning approaches worked, which renewal cadences converted, and which Hank flags were saves. That feedback loop is the porchops product.

The porchops minimum is: connect Stripe, configure Lou, set the auto-send threshold conservatively, and let the rest of the crew turn on as you're ready. Most founders need 30 minutes to be productive on day one.

Which Ops light up

The 5 Ops on the Revenue Post.

Five Ops touch the Revenue Post:

  • lou

    Lead Op for failed-payment recovery. Reads Stripe webhooks, customer history, decline codes; drafts cause-matched recovery emails. Usually the first Op customers configure.

    Read Lou's profile →

  • cleo

    Owns renewal cadence (30/14/3 days out) and expansion detection (usage anomalies). Pairs with Lou for end-to-end revenue ownership: Lou keeps existing revenue from leaking; Cleo grows it.

    Read Cleo's profile →

  • maggie

    Lives mostly on the Customers Post but supports Revenue through trial-to-paid conversion. Day 1/7/14 cadence personalized to product state. Activation is upstream of all the revenue work.

    Read Maggie's profile →

  • hank

    Customers Post Op; Revenue-relevant because the customers Hank flags are often the customers about to lapse on a renewal Cleo would otherwise be drafting for. Hank's flag and Cleo's calendar reinforce each other.

    Read Hank's profile →

  • dale

    Rhythm Post Op; Revenue-relevant because Dale's Monday brief is what tells the founder how the Revenue Post is doing this week. "MRR up $620, 1 churn, 2 Hank flags awaiting review" — five minutes to read, all the operational state.

    Read Dale's profile →
Deeper questions

Common questions about revenue.

  • Should I use Stripe Smart Retries with porchops?

    Yes. They're complementary. Stripe Smart Retries handle the retry attempt cadence (when to try the card again); Lou handles the email layer (what to say to the customer when retries finish). Most porchops customers run both. Stripe is the rails, Lou is the conversation.

  • What's the realistic recovery rate?

    Empirically, 35–55% of failed payments are recoverable across $5K–$500K ARR SaaS. Lou's value is the email layer of that — the contextual drafts that increase recovery on the soft-decline and expired-card buckets. We don't promise 30% recovery; we drop the time it takes to ship the email layer.

  • Do I need a dedicated dunning team?

    No. The dunning team is the founder, Lou, and Cleo. The point of porchops is that the operational layer is configured and running before the founder has time to hire a dunning specialist. If you grow past 500 customers and want a human in the loop, that's a Scale-tier decision; until then, the crew handles it.

  • What about international payments?

    Lou reads Stripe in multi-currency. Renewal emails render in the customer's billed currency. Decline-code mappings cover Stripe's full code library, including non-USD declines. Multi-language drafts are English-only at MVP; Spanish, French, and German are on the roadmap.

  • How does porchops handle customers on grandfathered pricing?

    Cleo reads Stripe subscription data including grandfathered plans. Renewal touchpoints reference the customer's actual plan, not your current pricing page. If you raise prices and want existing customers grandfathered, configure that in Stripe; Cleo reads it correctly.

  • What if my decline rate is 0.5% — do I even need this?

    Probably not as urgently. The Revenue Post matters most when 5%+ of MRR fails per month. At lower rates, Lou is still useful for the recoveries that do happen, but Cleo's renewal preparation and Hank's silent-churn watch are higher-leverage. Configure those first.