The 90-day cliff: the churn math that decides build vs rent

Every build vs rent argument for membership platforms eventually collapses into a pricing-page comparison: Patreon's take rate against Circle's monthly fee against a developer's quote. Ours starts somewhere less comfortable, in an incident log. Before the aggregate model, the anatomy of one engagement: INSPIRELLE, a subscription business running WooCommerce Subscriptions, a cohort of subscribers that had to be restructured mid-life without breaking a single renewal, and the store-credit engineering that turned refund emails into renewals.

Anatomy: two incident codes and one collation error

The setup. INSPIRELLE carried a cohort of Type-B subscriptions that needed a multi-phase restructure while live: issue store-credit coupons to every affected subscriber, switch automatic renewal to manual, generate renewal orders, and sync next-payment dates across the whole cohort to a single target date. Any one of those phases run twice, or half-run once, would corrupt live renewal state. That constraint shaped everything that follows.

Two of those phases deserve a sentence each, because they look like busywork and are not. Switching automatic renewal to manual is what makes store credit meaningful: an automatic charge fires before the customer ever sees the credit, while a manually generated renewal order gives the mu-plugin below a checkout to apply it at. And syncing next-payment dates to one target date converts a cohort that renews on 412 different days into a cohort that renews in one window, which turns every future operation on that cohort, repricing, pausing, migrating, from a month of dribbling edge cases into a single supervised event.

INC-2024-INSPIRELLE-01: the cohort recovery. We built the migration as one unified tool, migrate-typeb.php, with idempotent meta flags so each subscription records exactly which phase has already been applied to it, bulk-send capability, and a three-state preview, confirm and apply UI. Preview shows precisely which rows will change and how; confirm locks the scope; apply writes with an audit log. Around it: cron-friendly sync scripts that kept next-payment dates converging on the target date, and a rollback script for cleared end-dates, written before anyone needed it. That is the difference between a migration and a script you run twice and pray.

INC-2024-INSPIRELLE-02: the auto-apply mu-plugin.Store credit only recovers renewals if the customer never has to think about it. So inspirelle-typeb-autocoupon.php applies the pre-issued credit at renewal checkout automatically: email-restricted, so a coupon only fires for its owner; per-session dedup, so it applies exactly once; and silent on failure, because an expired coupon must not throw a scary red banner at the precise moment a customer is deciding whether to keep paying. It overrides WooCommerce's default coupon notice with "Your INSPIRELLE store credit of XX.XX has been applied to this renewal." The 0-order edge case, where credit fully covers the renewal, has its own branch because payment gateways behave differently when the charge amount is zero. This is the kind of mu-plugin work that sits inside our WordPress plugin development practice, and every plugin we ship through it clears the same review rubric we built for our 217-plugin security audit.

MySQL error #1267.Reconciling what credit had actually been applied meant raw SQL: wp_posts rows where post_title matches the coupon code, joined to wp_postmeta rows where meta_key = 'coupon_amount'. The join failed with error #1267, illegal mix of collations, because coupon codes and postmeta values had drifted onto different collations over years of plugin churn. The fix is an explicit COLLATE clause on the join key, and the lesson is the one we keep re-learning: subscription work happens at the row level, not the brochure level.

Why this is a churn story. Every subscriber in that cohort who received store credit and then renewed is a subscriber a rented platform would very likely have lost. Platform-default dunning would have retried the card, sent two templated emails, and cancelled. The custom recovery path is why the funnel we publish later in this post ends at 91% renewed rather than 84%. The whole build vs rent question, in our experience, hides inside exactly this kind of seven-point gap.

The 90-day cliff, and why the 2026 numbers changed

The membership market picked 2026 to reprice itself. The fan subscription market reached an estimated $10.26B, and the same industry data puts first-quarter attrition in brutal territory: roughly 44% of subscriptions cancel within 90 days of starting. Meanwhile Patreon's 10% platform fee plus payment processing is driving a visible exodus toward owned platforms, with every alternatives roundup now leading on fee math rather than features.

The churn side has an equally sharp finding. Platforms report that members who engage with community features churn at roughly half the rate of content-only subscribers: 73% vs 46% still active at three months. Community is not a marketing bullet; it is churn engineering with a two-times multiplier attached.

And the billing substrate moved underneath everyone. Stripe acquired Metronome for roughly $1B in January 2026 and now meters AI usage natively. For membership operators bolting usage-billed AI features onto a flat subscription, the metering discipline is the same one we mapped in our per-token economics study: model the unit cost before the billing schema locks, or discover it on an invoice.

Why 90 days specifically? Because three separate clocks expire there. It is the outer edge of habit formation: a member who has not built a usage routine by month three has quietly decided to leave and is waiting for the renewal email to remind them. It is the first renewal for quarterly billing and the third for monthly, which is where involuntary failures (expired cards, insufficient funds, bank blocks on a now-unfamiliar merchant name) concentrate. And it is where introductory promos unwind, so the price the member agreed to and the price on the receipt diverge for the first time. Three clocks, one cliff, and only one of the three is about your content.

So the question this post answers: at what subscriber count does the fee drag of renting outweigh the cost of building, once real churn and real recovery rates are in the model?

Methodology

Three data sources. First, renewal-event exports from Stripe, Zoho Subscriptions and WooCommerce Subscriptions across our billing implementations, which together have handled $5M in recurring revenue; the funnel in Finding 2 is indexed from those 90-day renewal cohorts. Second, engagement records for INSPIRELLE and PlusHeat, published with consent and with figures exactly as they appear in our incident documentation. Third, platform pricing pages captured in July 2026 for the fee model. The model's fixed assumptions:

Three computed metrics run through the findings: Platform Fee Drag (PFD), 90-Day Survival (D90S), and Dunning Recovery Rate (DRR), each defined in full further down.

Finding 1: fee drag crosses build cost between 1,100 and 9,000 members

Read the crossovers, not the columns. The custom build passes Patreon's all-in take (10% platform fee plus roughly 6.4% blended processing on small charges) at about 1,100 members. It passes Memberful Pro at about 2,200. The Circle-class SaaS, a flat $219 tier plus 1% transaction fee, is genuinely hard to beat and holds until roughly 9,000 members at this price point. Below those lines, renting is the correct answer and building is vanity engineering.

The crossovers are violently sensitive to price. Re-run the model at a $25 average subscription and the Patreon crossover falls under 400 members, the Circle-class crossover to roughly 3,700. Percentage fees scale with revenue; a build does not. That asymmetry, which we formalise below as Platform Fee Drag, is the entire economic argument, and it is why the fee columns deserve the same engineering scrutiny as the product. Our Stripe billing engineeringengagements usually begin with exactly this spreadsheet, filled in with the operator's real ARPU rather than our baseline.

One honest caveat the table cannot show: Patreon and Circle bundle discovery, apps and community infrastructure into their take. The model prices what you pay, not what you would rebuild. The point is not that platforms are overpriced; it is that past a knowable member count you are paying an acquisition-tool price for a billing commodity.

Finding 2: the renewal funnel is where an owned platform earns its keep

Fee drag decides when building becomes cheaper. The renewal funnel decides how much better an owned platform can perform once you control every step of it. This is the attrition path across a 90-day renewal cycle in our engagement data, indexed to a starting cohort of 100:

Two numbers matter. The trough is 84%: that is where a cohort lands with competent but conventional retry and dunning, and it is where most platforms and most agencies stop. The final state is 91%, and the seven-point difference is the store-credit layer, the INC-02 machinery from the anatomy above, applied automatically at renewal checkout. Sixteen points of the cohort entered the failure or lapse path; seven were recovered. On a 10,000-member base at $10, those seven points are $7,000 of MRR every billing cycle, $84,000 a year, from code that took a fraction of that to build.

Two details in that funnel repay attention. The dunning stage runs gateway-specific copy because the failure modes are not interchangeable: a card decline wants a one-click update link, while a Direct Debit failure wants a different message on a different clock, since DD settles days after the charge date and a card-shaped "payment failed, retry now" email to a DD customer is both wrong and alarming. And the store-credit stage sits deliberately late in the ladder, after retries and dunning have exhausted the payment-shaped fixes, because credit is the expensive lever: applied too early it subsidises renewals that would have recovered on their own; applied at day 14 it only touches genuine at-risk members.

The retry ladder itself is unglamorous enough to fit in one table:

-- Offsets are days from the failed scheduled charge.
CREATE TABLE dunning_schedule (
  attempt        TINYINT PRIMARY KEY,
  offset_days    TINYINT NOT NULL,
  action         VARCHAR(24) NOT NULL,
  email_template VARCHAR(40)
);

INSERT INTO dunning_schedule VALUES
  (1, 0,  'charge',         NULL),                  -- scheduled renewal fires
  (2, 1,  'retry',          'soft_decline_notice'),
  (3, 3,  'retry',          NULL),                  -- silent retry, no email
  (4, 5,  'retry_fallback', 'card_update_request'), -- fallback method if on file
  (5, 8,  'grace_period',   'access_pause_warning'),
  (6, 14, 'store_credit',   'store_credit_applied'),-- the INC-02 mu-plugin path
  (7, 21, 'cancel',         'winback_offer');

None of it works if the event plumbing underneath is unreliable: a dunning ladder driven by webhooks that double-fire or arrive out of order will charge someone twice and cancel someone paid-up. The five guarantees a production handler owes you, with the TypeScript and SQL we ship, are in our Stripe webhooks guide.

Pricing the cliff: what D90S does to a year of revenue

The survival statistics only become an argument when they are priced. So: 1,000 joiners at $10 a month, three survival scenarios, twelve months of revenue. We assume the published three-month survival figures, then a steady 3% monthly churn from month four onward, which matches what stabilised cohorts look like in our exports once the cliff is behind them.

The spread between the top and bottom rows is roughly $25k per 1,000 joiners per year: a community-led membership earns about 43% more from identical acquisition. Two implications follow. First, this dwarfs the fee differences in Chart 1 at small scale, which is why the recommendation for sub-500 operators below is to stay rented and spend the energy on retention instead. Second, it compounds with recovery: the DRR layer from Chart 2 defends the surviving base at every single renewal, so the two levers multiply rather than add. An operator who moves D90S from 46% to 60% and DRR from a third to 44% has changed the business more than any replatform ever will, which is exactly why we treat churn work as engineering with a revenue line, not as a marketing afterthought.

Finding 3: the combinatorial billing matrix kills spreadsheets, not platforms

The third cost centre is invisible on every pricing page: what happens when your plans stop being a list and become a matrix. PlusHeat, a home-cover subscription business, sells through a configurator, and every signup is the output of seven dimensions: plan tier x customer type x call-out excess x billing frequency x add-ons x promo state x payment method. Multiply honestly and the space looks like this:

A naive WooCommerce Subscriptions setup buckles under that combinatorial space; so does the spreadsheet nobody can read by month three. What we built for PlusHeat, logged as INC-2024-PLUSHEAT-01, is an orchestration layer between the marketing site, the customer and Zoho Subscriptions: every configurator outcome maps deterministically to the correct billing plan in the source-of-truth system, with dunning and proration handled there, and Direct Debit's settlement lag reconciled against the instant-charge profile of cards. That discipline, the billing system is the source of truth and the site never invents pricing, is what let a 50%-off-for-three-months promo run cleanly across the matrix instead of leaking revenue through edge cases. The layer has generated 40K+ subscriptions on Zoho.

The build vs rent relevance: no rented membership platform models a seven-dimension matrix. Operators in this situation are not choosing between Patreon and a build; they are choosing between an orchestration layer and a support queue full of wrongly billed customers.

The video aside: content delivery is a second subscription on your books

Membership platforms with gated video carry a cost line that behaves like a subscription in reverse: it grows with engagement. For Player Profile Hub we modelled the Mux economics before the billing schema locked: $0.003/min storage, $0.0008/min blended delivery, 100K free minutes a month, a 75% watch-rate cap, and a 50/50 720p/1080p blend at a 0.9 factor. Baseline result: $4.42/user/month at the modelled watch profile.

Put that against the fee model in Finding 1 and the problem is obvious: on a $10 membership, $4.42 of delivery cost is 44% of ARPU before a single platform or processing fee. The free tier masks it early, which is precisely the danger; the per-user cost curve only stabilises past several thousand users, and if pricing was set assuming flat costs, the margin error is unrecoverable without repricing. We delivered the model as a written report plus an interactive React calculator (Vite + React 18 + Tailwind) so the founders could stress their own assumptions before a line of platform code existed.

The watch-rate cap matters more than it looks. Delivery cost scales with minutes watched, and minutes watched is exactly the behaviour the churn side of this post is trying to maximise: a community-led platform with 73% three-month survival is also a platform whose delivery bill grows fastest. Retention success and margin pressure arrive in the same invoice. The general rule carries beyond video: any usage-shaped cost inside a flat-priced membership, delivery minutes, AI tokens, SMS, transactional email at scale, needs its unit economics modelled before pricing locks, which is the same conclusion our per-token study reached for AI features. The alternative, discovering the curve from a production invoice, converts a pricing decision into a repricing announcement, and repricing announcements are churn events.

How we measure membership economics

1. Platform Fee Drag (PFD)

PFD = (Platform fees + transaction fees + processing) / MRR

The share of recurring revenue consumed by the stack before you touch it. At a $10 price: Patreon lands around 16%, Memberful Pro around 11% all-in, a Circle-class SaaS around 6% at 5,000 members, and a custom build's marginal PFD is processing only, roughly 3.2%, plus its fixed amortisation.

2. 90-Day Survival (D90S)

D90S = Subscribers still active at day 90 / Subscribers in the joining cohort

The cliff metric. Market-wide data implies a D90S around 56%. Community-led platforms report 73%; content-only, 46%. Every recommendation below is downstream of which side of that spread you are on.

3. Dunning Recovery Rate (DRR)

DRR = Renewals recovered by retry, dunning and store credit / Renewals entering the failure path

In the Chart 2 cohort, 16 points entered the failure or lapse path and 7 were recovered: DRR of 44%. Platform-default dunning, in our audits, rarely clears a third.

What the engagements actually taught us

1. Store credit converts refunds into renewals. A refund is revenue leaving with a goodbye note; credit auto-applied at renewal checkout is the same money holding the subscriber through the next cycle. It is the single largest recovery lever in our funnel, worth seven points of a 100-point cohort.
2. Idempotency is the difference between an incident and a catastrophe. Preview, confirm and apply, meta flags recording applied phases, and a pre-written rollback are why INC-01 stayed one incident code instead of becoming three.
3. The billing system is the source of truth; the site never invents pricing. Every wrongly billed customer we have ever been called in on traces to a website computing a price the billing system never agreed to.
4. Direct Debit lag breaks dashboards that card billing built. DD settles days after cards do; promo states and dunning windows tuned to instant charges misfire on the slower rail unless reconciliation treats them separately.
5. Community features are churn engineering, not marketing. A two-times difference in three-month survival outweighs almost anything you can do to the checkout. Budget for it as retention infrastructure.
6. The 90-day cliff is partly a billing artefact.First renewals concentrate involuntary failures: cards saved months earlier, promo prices unwinding, unfamiliar merchant descriptors triggering bank declines. A meaningful share of what gets reported as "churn" in month three is recoverable payment failure wearing churn's clothes, which is why DRR belongs in every churn conversation.

Recommendations

Under roughly 500 members: rent, deliberately

At this scale fee drag is noise and your scarce resource is attention. Stay on Patreon or a Circle-class platform, but rent deliberately: keep an export of your member list, prefer platforms where the Stripe customer objects are yours, and instrument D90S from day one so the eventual decision is made with your own cohort data rather than industry averages.

500 to 5,000 members: rent the platform, own the billing

This is the band where the crossovers in Chart 1 start to bite, especially above a $10 price. A Stripe-first setup (Memberful, Ghost, or custom checkout in front of a rented community) keeps PFD in single digits and makes the eventual migration a re-skin rather than a rescue. This is also the point to get the dunning ladder and webhook reliability engineered properly; our Stripe billing integration work most often lands here, where a two-point DRR improvement already outearns its invoice.

One habit worth forming in this band: reconcile monthly. Billing events to application database to accounting, on a schedule, so that fee drag, failed-charge recovery and promo leakage are numbers you read rather than numbers you estimate. Every operator we have moved from estimate to export has found at least one surprise, and it has never once been a pleasant one.

Above 5,000 members, or any operator with $1M+ recurring: run the build math

Here the fee columns dominate and the edge cases multiply: combinatorial plans, store credit, cohort migrations, mixed payment rails. This is the territory our membership and subscriptions engineering practice exists for: audits and recoveries on WooCommerce Subscriptions, migrations between WCS, Stripe Billing, Zoho and Chargebee that preserve renewal cadence and payment methods, and the recovery layer that moves the funnel from 84 to 91. Whether the answer is a full build or an orchestration layer over Zoho, as at PlusHeat, the decision should come out of the PFD and DRR numbers, not out of a feature comparison.

Limitations

The renewal funnel is indexed from our own engagements, which skew toward operators with subscription edge-cases painful enough to hire us: selection bias likely flatters the recovery layer's headline. Fee figures are July 2026 snapshots and reprice frequently; the build cost band uses blended UK / India rates. The market-wide 90-day and community statistics are third-party and platform-reported, not independently audited by us. Chart 3 cardinalities are illustrative of the PlusHeat configurator's shape, not its exact catalogue. Client names appear where we have consent; everything else is anonymised.

The decision is a churn decision, not a feature decision

Strip the pricing pages away and build vs rent reduces to three numbers you can compute this week: your PFD at current and projected scale, your D90S measured on your own cohorts, and the DRR your current stack actually achieves. Rent while PFD is noise and community is unbuilt. Build, or take control of the billing layer, once fee drag crosses your amortised build cost or once the recovery gap between platform-default dunning and an engineered funnel is worth more than the engineering. The 90-day cliff is not weather; it is a measurable slope with known handholds.

And when the decision does land on build, or on taking over an existing stack, treat the unglamorous layers as the product: idempotent migration tooling, a dunning ladder with gateway-aware copy, store credit that applies itself, reconciliation that closes in hours. Nothing in this post came from a feature launch. The 91% came from a mu-plugin, a retry table, and a COLLATE clause.

Pair this model with the engineering guides and studies underneath it:

And the engagements that do the work described in this post: