Shipped what looks like one RetryFix release. Backend billing landed first; the Account / pricing UI followed. Same change.
What merchants see
What we had to get right (and why it took more than copy)
Stripe will not swap a licensed price and a metered price on the same subscription item. So a switch is not “change the price.” It’s: schedule the old sub to end at period end, start the other plan with trial_end on that date so nobody is billed twice today.
That has sharp edges: Checkout must attach to the existing customer (email-only Checkout creates a second cus_), pending state must survive until the booked date, cancel-pending must not send cancel_at and cancel_at_period_end in one API call, platform webhooks must not write billing onto the support user.
Also dropped “start your free trial” on the post-demo CTA. There isn’t one. You see more payment data after setup; you commit when you subscribe.
If you’re in the same licensed ↔ metered trap: don’t fight Subscription.modify on the item. Cancel-at-period-end + new Checkout + honest UI was the boring path that works.
#buildinpublic #indiehackers #saas #stripe #payments
The useful change is not just the price cards: you made the buying commitment more honest by separating recovery-based pricing from a fixed-cost choice and removing a trial CTA that did not match the product. I run a small public-URL-only Revenue Path Diagnostic for three design partners: five pages, one decision-path map, and a ranked queue covering buyer segmentation, pricing/comparison clarity, post-demo commitment, trust framing, and what to measure next—without Stripe, merchant, payment, or account access. For RetryFix, I would focus on how a merchant moves from understanding the recovery outcome to choosing the pricing model that fits their risk and volume. The design-partner fee is USD 499; it is a scoped diagnostic, not a promise of conversion or recovered revenue. If relevant, I can share the exact five-page scope first.