AARRR Is Not a Funnel, It's a Health Check: An Indie Dev's Operations Review
The AARRR model is not a user funnel but a systematic product ops checklist. This article breaks down each stage with an executable checklist and common pitfalls from an indie developer's perspective.
Why I Rethink AARRR
When I first started building products, I drew countless AARRR funnels—Acquisition, Activation, Retention, Revenue, Referral—each stage a rectangle, wider at the top and narrower at the bottom, connected by arrows. It looked logical, but it felt awkward in practice. Users don't behave like parts on an assembly line. More importantly, as an indie developer with limited resources, I can't push equally on all stages at once.
So I changed perspective: treat AARRR as a health check sheet, where each stage is a medical check item with specific indicators. After every product update or ops adjustment, instead of looking at funnel conversion rates, I go through each indicator, find the red flag, and focus only on fixing that one. This approach shifted me from "trying to optimize the whole pipeline" to "precisely locating the bottleneck."
Acquisition: Not More, but Efficient Sources
For acquisition, I track three things:
- Cost per user (by channel)
- Channel activation rate (percentage of downloads that complete registration or first core action)
- Channel day-1 retention (compare different channels)
Example: Suppose I have a language learning app. Users from ads have only 20% day-1 retention, while users from organic search for "Russian accent mark" have 45% day-1 retention. If I only look at download numbers, ads might seem attractive. But organic users have much higher long-term value. So I'd prioritize ASO and content marketing over ad spend.
A common trap in acquisition is a channel that brings many new users but extremely low activation (e.g., incentivized video ads). Cut that channel first.
Activation: Does the First Use Deliver Value?
Activation is not registration. I define activation as "the first time a user completes the core value action." This varies per product: for a note app, it's "create and save the first note"; for a music app, "finish listening to one song"; for a language app, "complete the first word exercise."
Checklist:
- Percentage completing the core action (from app open to completion)
- Time to complete core action (how long from open to finish)
- Whether first use triggers return (e.g., via push or notification)
Example: I built an AI writing tool. Many users registered, wrote a sentence or two, then left and never came back. I changed the activation event to "generate a full article" and added a 3-step guide. Completion rate went from 12% to 38%, and retention improved. The key was lowering the activation bar to show users a complete value output in the first session.
Retention: The Core Health Metric
Retention is the most important metric for indie developers—full stop. If a new feature doesn't improve retention, I don't build it. But many people confuse "new user retention" with "existing user retention." New user retention (D1/D7/D30) reflects onboarding and initial value; existing user retention (e.g., monthly retention > 60%) reflects long-term stickiness.
Checklist:
- New user D1/D7/D30 retention (by weekly cohorts)
- Existing user monthly retention (users who have been active for > 3 months)
- Revisit interval (days between two uses; if too long, the product is replaceable)
Example: My To-Do app had 30% D7 retention for new users, but 85% monthly retention for users who stayed over 3 months. The problem was early guidance—users didn't know how to integrate the app into their daily routine. I added a "daily review" template so new users formed a habit in the first week.
Revenue: Payment ≠ Business Success
In revenue stage, I rarely look at total revenue. Instead, I track ratios:
- Paying user percentage (paying / total users)
- LTV / CAC (lifetime value vs acquisition cost)
- Payback period (average days to recover acquisition cost)
Example: I once added a $6/month subscription to an app; the paying rate was only 1%. I changed to "free for 7 days, then buy feature packs on demand." Paying rate rose to 4%, but LTV decreased because many users bought one feature and churned. The healthy model turned out to be "high-frequency low-price feature packs" combined with a long-term subscription—let users experience value before committing to pay.
Revenue is not about maximizing the total, but about sustainability.
Referral: Viral Coefficient vs Organic Word-of-Mouth
Referral comes in two forms: active invites (e.g., share with friends for a reward) and passive word-of-mouth (users naturally recommend). As an indie developer with limited resources, I prefer the latter, but it's harder to measure.
Checklist:
- Invite rate (percentage of users who clicked the invite button)
- Invite conversion (percentage of invitees who registered)
- Natural recommendation (via NPS or user surveys)
Example: In a security app, I added "invite a friend and get 7 days of premium." Invite rate jumped from 2% to 15%, but invitee registration was only 10%—reward-driven invites often bother people. I changed to "share a feature tutorial," and invitee registration rose to 25%. The key is that the shared content is valuable to the receiver, not just a reward.
Summary: AARRR Is a Parallel Health Check, Not a Serial Funnel
Here's a table summarizing check items for each stage:
| Stage | Key Indicators | Common Pitfalls |
|---|---|---|
| Acquisition | Channel activation rate, channel D1 retention | Focusing only on downloads, ignoring channel quality |
| Activation | Percentage completing first core action | Confusing registration with activation |
| Retention | D1/D7/D30 retention, revisit interval | Looking only at average retention, mixing new and old users |
| Revenue | Paying rate, LTV/CAC, payback period | Focusing only on total revenue, ignoring sustainability |
| Referral | Invite rate, invite conversion, natural recommendation | Reward-driven invites ignoring content value |
I recommend doing this health check every two weeks: find the red-flagged indicator, then change only one variable. Don't try to optimize all stages at once. The biggest advantage of indie development is speed—focus on the most painful bottleneck.
PaxLee