Paid Membership & Access Planner

The problem

Paid membership apps built with AI tools lose money quietly, and the loss is hard to see when you only test the normal path. Your agent ships a signup form, a pricing page and a user.tier === "premium" check in the template. The demo looks perfect: you sign up, you pay, the article unlocks. Everything the founder clicks through works.

What is missing is every way a membership ends:

• The card fails on renewal. Nothing happens, and access continues.
• A member cancels. The row is marked cancelled, the gate never reads it again, and access continues.
• A refund is issued, a chargeback arrives, a subscription expires, or a member downgrades in the middle of a cycle.

The app has no idea of an entitlement that can be taken away, because it only modelled the moment the money arrived. You end up with a paid tier that anyone who paid once keeps forever.

The gate itself is the worse failure. When "premium" is decided in the template, the protected content is usually already in the JSON the page fetched. The paywall is only CSS. The member does not need to hack anything. They only need to open devtools, or scroll before the script runs. A whole membership business can ship with its product served to visitors who are not logged in.

What it is built from

The planner is based on a verified count of 100 products: a fixed 60-product core cohort plus 40 adjacent products, checked across 150 verified source rows. The counts are conservative on purpose. A product is credited only where a retained official source explicitly documents the capability, so every number below is a minimum.

Your agent cannot rebuild this cohort, because "membership software" is four different product categories that disagree with each other. The core covers:

• WordPress membership plugins: MemberPress, Paid Memberships Pro, ARMember, Restrict Content Pro, s2Member, WishList Member.
• Hosted membership platforms: Memberful, MemberSpace, Memberstack, Outseta, AccessAlly.
• Publisher paywalls: Piano, Zephr, Poool, Pelcro, Leaky Paywall, Accesstype, Evolok.
• Video/OTT access control: Uscreen, Muvi, ViewLift, Cleeng, InPlayer.

The adjacent cohort covers creator and entitlement infrastructure: Patreon, Ko-fi, Circle, Mighty Networks, Whop, RevenueCat, and the Stripe / Chargebee / Recurly entitlement APIs. An agent that works from blog posts mixes those four categories together. The research keeps them separate and tells your agent which one it is building.

The key finding is that what the market advertises and what breaks are opposite:

• Plans and tiers are documented in 36 of 60 products.
• Recurring pricing: 24 of 60.
• Failed-payment retry and dunning: only 4 of 60.
• What happens to access after a refund or chargeback: 6 of 60.
• Proration: 3 of 60.
• Explicit server-side entitlement verification: just 3 of 60.

The low counts do not mean these matter less. They are rarely documented. They are the lifecycle edges where access stays on after the money stops. A planner that ranked features only by how often they are advertised would push every one of them down. This planner ranks them higher because of their lifecycle risk.

What you get

A planner that puts the member first and treats entitlement as a server-side decision with an end date. A flag on a user row is not enough. It takes your agent through the membership model and depth before any code, then holds the build to lifecycle checks:

• Depth tiers with clear limits. Basic is 9 features / 45 sub-features / 9 lifecycles. Moderate is 15 / 75 / 15. Advanced reaches 17 to 19 features / up to 95 sub-features / 17 to 19 lifecycles. The resolver enforces the budget and stops the build when a selection goes over. It does not quietly expand the scope.
• The member is the user the product must serve best. Join, sign in, read or watch what they paid for, see what their plan includes, and change or cancel it without emailing support. That leads the product. Admin and reporting screens are not allowed to crowd the main navigation.
• Every entitlement has an end. Cancellation, expiry, refund, chargeback, failed payment and plan change must each reverse access in the same transaction that records them. Each one is proven by running its own lifecycle. A ticked box is not accepted as proof.
• The gate runs on the server. Protected content is resolved and held back on the server. Teaser, meter, drip and denied states are designed screens. A stylesheet that hides data the browser already holds is not a gate.
• Membership model as a separate choice. Content paywall, community access, file or video library, and course-style drip are separate decisions with different data models. They are never quietly joined into one generic "membership."

The planner produces a main CLAUDE.md or AGENTS.md and separate spec files. A custody check stops the agent from writing code before the spec is written and locked.