The Quit-Tracker That Taught Me Retention

Before Frictionwell was a habit tracker, it was a much smaller, weirder app called Quit Log, and it taught me something about retention that I don't think I could have learned any other way: an app that is genuinely good at its job will, on purpose, make you open it less over time, and if your business model or your ego is attached to daily-active-users going up forever, that's a direct conflict you have to resolve honestly or you'll end up building the wrong product.

What Quit Log actually did

I built Quit Log for myself in about four days, to track a bad habit I was trying to break — nothing sophisticated, just a log entry every time I slipped, a running count of days clean, and a short note field for what triggered it. I put it in the app store almost as an afterthought, priced it at three dollars, and it slowly picked up a genuinely dedicated few hundred users, mostly through word of mouth in recovery-adjacent communities I hadn't targeted and didn't fully understand at first.

The retention curve on Quit Log looked, for the first several months, like nothing else I'd built. Week-one retention was extraordinary — over seventy percent of new users were still logging entries a week in, a number that would be a headline result for almost any consumer app. And then, starting around week six or eight for the users who were actually succeeding at the thing they'd downloaded the app to do, usage fell off a cliff. Not because they'd churned in the normal sense — uninstalled, forgotten, moved on to a competitor — but because they didn't need to log a slip they weren't having anymore.

"The users who were succeeding were the users who stopped opening the app. Every growth instinct I had told me that was a retention problem. It was actually the product working exactly as designed."

I want to be specific about the numbers here, because vague retention talk is exactly the kind of thing this desk exists to avoid. Of roughly 640 users who'd installed Quit Log in its first year, about 210 hit what I'd eventually define as a graduation threshold — a sustained clean streak past ninety days followed by a clear drop in logging frequency. Another 90 or so were still actively logging past the six-month mark, genuinely still using the app the way it was designed to be used day to day. The remainder, a bit under 340 users, dropped off early with no meaningful streak progress at all — the group that was, on reflection, the only group a normal churn definition would have correctly flagged as lost.

The dashboard that lied by omission

I spent an embarrassing number of weeks trying to "fix" this the way I'd fix any retention cliff — more notifications, a streak mechanic to reward continued logging, a weekly digest email to pull lapsed users back in. Every one of these made the retention number look marginally better and made the actual product marginally worse, because they were all, in one way or another, trying to give people a reason to open an app that had successfully done the one thing it existed to do.

The moment this actually clicked for me was a support email from a user who'd stopped logging entirely around week ten. She wasn't churning in any sense that should have worried me. She wrote, unprompted, to say the app had genuinely helped her get through the hardest part of quitting, and that not needing it anymore felt like the actual proof it had worked. She wasn't complaining. She was thanking me, for a product she'd stopped using, in a tone that made it obvious my retention dashboard had absolutely no way to represent what she was telling me.

Redrawing the chart I actually needed

Once I understood that the standard retention curve was measuring the wrong thing for this specific product, I built a different chart for myself — one that split "still logging" from "graduated," where graduated meant a user who'd hit a meaningful clean streak, then tapered their logging frequency without any of the churn signals that usually predict someone has actually left disengaged, like uninstalling, stopping push notification opt-in, or leaving a negative review. That second chart told a completely different, much better story than the first one.

The graduated cohort — people whose usage fell because the product had worked — made up a genuinely large share of what would have shown up, on a naive chart, as failed retention. The actually-churned cohort, people who gave up early with no progress to show for it, was smaller than I'd assumed and, more usefully, identifiable by a very different early signal: short, infrequent sessions with no streak progress in the first two weeks, rather than the long, engaged sessions the graduated cohort had before their usage tapered.

Three things fell out of that split that I now treat as fixed rules for any product I build. Not every drop in usage is churn — for a product whose job is to make itself unnecessary, a falling engagement curve can be the strongest possible signal of success, and treating it as a problem to fix will make the product worse. A retention metric needs to split by outcome, not just by activity, because "still opening the app" and "opening the app for the reason it exists" are different measurements, and conflating them hides the story that actually matters. And the early signal that predicts real churn turned out to be a different signal entirely from the one that predicts graduation — short, shallow, disengaged early sessions predicted genuine churn, while long, engaged early sessions followed by a taper predicted success. I only found that distinction by putting week one and week ten side by side, cohort by cohort, rather than trusting either number on its own.

The investor conversation this ruined, on purpose

I raised this exact chart, unprompted, in a conversation with someone who'd expressed casual interest in putting a small amount of money into Frictionwell after Quit Log's numbers had started attracting attention. I could have shown him the naive engagement chart — the one where usage climbs steadily and never dips — and let the graduated-user tapering stay buried in a cohort split he'd never think to ask for. I showed him the real chart instead, split cleanly into graduated and churned, and explained exactly why a meaningful chunk of my "lost" users were actually the closest thing this product had to a five-star outcome.

He passed, and he was honest about why: a habit-forming consumer app that structurally works toward reducing its own usage is a much harder story to underwrite than one with a clean, ever-climbing engagement line, regardless of how honest or how good for users that structural honesty is. I don't think he was wrong to pass, given what he was optimising for. But I've never regretted showing him the real number instead of the flattering one, because the version of this business built around hiding that tension from an investor is also, structurally, the version built around eventually hiding it from myself — adding streak mechanics and push notifications not because they served the user, but because they served a metric I'd have committed to defending. Losing that round of funding cost me nothing I actually wanted to keep.

"I could have shown him the chart that looked good. I showed him the chart that was true. Those turned out to be different charts, and I'd rather build the business the true one describes."

What this changed about Frictionwell

When Quit Log's core mechanics evolved into Frictionwell, the habit tracker, I carried this lesson forward on purpose, even though habit tracking doesn't have the same clean "graduation" moment quitting does — you don't ever definitively finish being a person who exercises regularly the way you can finish quitting a specific habit. But the underlying discipline transferred directly: I still, every quarter, ask whether a falling usage number for any given user cohort represents disengagement or represents the product having done its job well enough that daily check-ins matter less. It's a harder question to answer for Frictionwell than it was for Quit Log, and I don't always get it right. But I'd rather ask a hard question honestly than keep optimising a dashboard that can't, even in principle, tell success from failure — because that's the version of the mistake that's cheap to make and expensive to notice, and Quit Log is the only reason I noticed it before it cost me something bigger.