Audit how my app handles subscription plan changes. Find the upgrade/downgrade flow and check what actually happens to billing and access when a customer switches plans. Implement deliberate rules: upgrades take effect immediately with prorated billing (the provider computes the proration; use its mechanism rather than calculating partial amounts myself, since providers handle the edge cases around billing cycle dates); downgrades take effect at the end of the current paid period (the customer paid for the higher tier, they keep it until it expires), unless the product decision is immediate downgrade with prorated credit, which should be a deliberate choice; access changes match the billing timing exactly (immediate access to the new tier on upgrade, scheduled change on downgrade); and the customer sees what they'll be charged and when before confirming, including the prorated amount. Handle the pending-change state: a scheduled downgrade must be stored, applied by the renewal webhook, and cancellable if the customer changes their mind. Don't change prices on existing subscribers silently as part of this; plan changes are customer-initiated. Don't roll my own proration math. Deliver: the rules per change direction, the implementation using provider proration, the pending-change handling, and verification in test mode: upgrade mid-cycle (immediate access, prorated invoice), downgrade mid-cycle (current tier until period end, then the change applies), and cancel a pending downgrade.