Skip to content
PorchOps
how to run a saas · 01

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

Revenue is the first area 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 area 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 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 is the bookkeeper agent that reads both, drafts the right email — recovery, renewal, or expansion — and either sends it or hands it to the founder for one-click approval. The Revenue area 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 Revenue 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 bookkeeping work end-to-end — failed-payment recovery, renewal preparation, expansion detection. Hank owns trial-to-paid conversion as part of customer success. Together they cover the four corners of Revenue, and together they ship the work the founder kept meaning to do.

What data it needs

The five inputs.

The Revenue area 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.

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'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 learns 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, tracks renewals on a 30/14/3-day cadence, and flags expansion signals when usage spikes. 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. Reviews and sends with one click, or auto-sends below a configurable threshold.

Lou also tracks renewal dates 30/14/3 days out and drafts personalized renewal touchpoints based on tenure and usage trajectory; watches for expansion signals (usage spikes 50% over rolling baseline, sustained 14 days) and drafts a no-pressure conversation note when one fires.

What Hank does (Customers area, but supports Revenue through trial activation): 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.

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 agents light up

The 5 agents on revenue.

All five agents touch the Revenue area:

  • lou

    The bookkeeper. Lead agent for everything billing — failed-payment recovery (reads Stripe webhooks, customer history, decline codes; drafts cause-matched recovery emails), renewal cadence (30/14/3 days out), and expansion detection (usage anomalies). Usually the first agent customers configure.

    Read Lou's profile →

  • hank

    Customer success. Revenue-relevant because Hank's day-1/7/14 trial nudges drive trial-to-paid conversion, and the silent-customer flags Hank surfaces are often the customers about to lapse on a renewal Lou would otherwise be drafting for. Hank's flag and Lou's calendar reinforce each other.

    Read Hank's profile →

  • frankie

    Support coordinator. Revenue-relevant because billing questions land in the support inbox first; Frankie classifies them and routes to Lou. Without Frankie, billing questions get buried under newsletters.

    Read Frankie's profile →

  • dale

    Chief of staff. Revenue-relevant because Dale's Monday brief is what tells the founder how Revenue 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 →

  • inky

    Communications writer. Revenue-relevant through the lifecycle email layer — trial activation emails (handed off from Hank), expansion-conversation drafts (handed off from Lou), renewal touchpoints. Inky calibrates the language; Lou and Hank trigger the moment.

    Read Inky'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?

    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 and Lou. 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?

    Lou 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; Lou reads it correctly.

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

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