Build a membership site with AI: entitlement, cancellation and content access

A worked example: where the task becomes difficult

A fictional craft educator sells access to a lesson library. A visitor can read free lessons; an active member can open paid lessons; a cancelled member retains access only until the approved expiry. The first build uses fake entitlements and one lesson of each type. Write the policy in plain language before asking the agent to create subscription cards, because trial promises and refunds change who should retain access.

Decisions to make before implementation

Specify when access starts, whether failed renewals have a grace period and whether refunds remove access. Keep these decisions out of arbitrary frontend conditions. The trusted billing or entitlement service should own the state used by content endpoints. Also decide what a user may download permanently. Revoking access to a web lesson cannot necessarily revoke a file already saved to a personal device.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Write a membership-state table with start and expiry rules approved by the owner.
• Implement free and restricted lesson retrieval against controlled entitlement records.
• Connect billing events only after event authenticity and duplicate handling are designed.
• Test expiry, cancellation and payment failure before publishing membership promises.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement lesson access from a server-owned entitlement record. Model free, trial, active, grace and expired states only where the supplied policy uses them. Keep billing identifiers private. Do not trust checkout redirects for authorization. Provide controlled tests for cancellation and expiry, plus a user-facing explanation of denied access that does not reveal another account.

Failure modes that an attractive preview can hide

An agent may unlock content when a query string says payment succeeded or when a browser flag is set. Those signals are user-controlled and cannot authorize paid access. Another trap is deleting access immediately when cancellation is requested despite a paid-through period. Match behavior to the published policy and preserve a support trace for disputed entitlement decisions.

Technical references: MDN: sending form data

Acceptance checks and the evidence to retain

Retain the policy table, entitlement source, protected-content checks and event reconciliation plan. Clearly identify payment integrations that are still simulated rather than operational.

Specific answers

Common questions