Our students kept cancelling every summer, so we built our own retention system. Churn went from 24.7% to 13.4%

Abdulhafeth Salah — Thu, 03 Sep 2026 12:47:30 +0000

Every June, our revenue chart did the same thing. It fell off a cliff.

My cofounders and I were running Quizplus, a subscription education platform. Students paid monthly, studied during the semester, and then summer break arrived and they cancelled in waves. Winter break, same story. Our churn during those periods hit 24.7 percent. We were basically rebuilding a chunk of our customer base twice a year.

The obvious take was "that's just seasonality, students don't study in summer." And that's true. But when we actually talked to cancelling users, the picture was more interesting:

Most of them were not leaving us. They were leaving for eight weeks and our billing system only offered them a door marked EXIT.

What we found when we looked closer

Cancellations fell into three buckets:

Pausers in disguise. Students who fully intended to come back in September, but the only way to stop paying for the summer was to cancel. We then had to win them back from scratch, competing with whatever they discovered in the meantime.
Price-sensitive, not product-unhappy. Users who liked the product but couldn't justify full price during months of light usage.
Involuntary churn. This one surprised us most. A meaningful slice of "cancellations" were not decisions at all. They were expired cards and failed payments that our billing provider retried once or twice on a dumb schedule and then gave up on. The user often had no idea they'd churned.

Three different problems. Our cancel button treated them all identically.

What we built

Instead of a cancel button that pointed straight at the confirmation screen, we built a flow that asked why the user was leaving and branched on the answer:

Taking a break? We offered a pause for one to three months. Subscription state machine gets a new paused status, no invoices generated, everything resumes automatically.

Too expensive right now? A temporary discount or a switch to a lighter plan, instead of losing the whole subscription.
Actually done with us? Fine. Clean exit, short survey, no dark patterns. We logged the reason so the data compounded.

For the involuntary side, we rebuilt payment recovery: smarter retry timing instead of the default schedule, plus email notifications that told users their card had failed before their access disappeared. It felt almost too simple. It recovered a shocking amount of revenue.

The result

During break periods, churn dropped from 24.7% to 13.4%. Roughly half the loss we'd been treating as inevitable was recoverable with better mechanics.

The lesson that stuck with me: churn is not one metric, it's a bucket of different problems wearing the same label. A pause request, a price objection, and an expired Visa are three unrelated failures. If your cancellation path handles them with one generic flow, you're leaving money on the table and, worse, annoying users who wanted to stay.

Where this ended up

We eventually realized every subscription business has some version of our summer-break problem, just with different seasons. So we spun the internal tooling into its own product, Churn Solution, which is now my full-time work (we're a team of three founders). Happy to answer anything about that journey too.

But the reason I'm writing this first post is the general point, not the pitch: before you spend another dollar on acquisition, go read your cancellation data. Ask the three-bucket question. You might find that a lot of your "churned" users never wanted to leave.

Question for you: if you run or work on a subscription product, what does your cancel flow actually do today? One confirmation screen, or something smarter? Curious what's worked for others.

DEV Community: Abdulhafeth Salah

Our students kept cancelling every summer, so we built our own retention system. Churn went from 24.7% to 13.4%