--- name: developer-churn description: When the user wants to understand, reduce, or recover from developer churn. Trigger phrases include "why developers leave," "churn rate," "win-back campaign," "at-risk users," "developer retention," "preventing churn," or "competitor switching." risk: unknown source: https://github.com/jonathimer/devmarketing-skills/tree/main/skills/developer-churn source_repo: jonathimer/devmarketing-skills source_type: community date_added: 2026-07-01 license: MIT license_source: https://github.com/jonathimer/devmarketing-skills/blob/main/LICENSE --- # Developer Churn ## When to Use Use this skill when you need when the user wants to understand, reduce, or recover from developer churn. Trigger phrases include "why developers leave," "churn rate," "win-back campaign," "at-risk users," "developer retention," "preventing churn," or "competitor switching.". This skill helps you understand why developers leave, identify at-risk users before they churn, and win back those who've already left. No guilt trips or desperate discounts — just honest understanding and genuine value. --- ## Before You Start 1. **Load your developer audience context**: - Check if `.agents/developer-audience-context.md` exists - If not, run the `developer-audience-context` skill first - Understanding your developers' alternatives and pain points is critical for churn analysis 2. **Gather your data**: - Current churn rate by segment - Most recent churned users (last 30-90 days) - Support ticket history for churned users - Usage patterns before churn - Exit survey data (if any) --- ## Understanding Developer Churn Developer churn is different from typical SaaS churn: | Consumer/SMB SaaS | Developer Tools | |-------------------|-----------------| | Price sensitivity high | Value sensitivity high | | Features drive decisions | DX drives decisions | | Support tickets = engagement | Support tickets = friction | | Monthly churn cycles | Project-based churn | | Competitor marketing works | Peer recommendations work | **Key insight**: Developers don't leave because of price. They leave because of friction, frustration, or finding something better. --- ## The 6 Reasons Developers Churn ### 1. Developer Experience (DX) Issues **Symptoms**: - High time-to-first-value - Frequent support tickets on basic tasks - Complaints about docs or SDKs - "It's too complicated" feedback **Root causes**: - Poor documentation - Buggy SDKs - Breaking changes without migration paths - Confusing authentication - Missing quickstarts **Detection signals**: ``` - Support tickets mentioning "confused" or "doesn't work" - High signup-to-activation drop-off - Long time between signup and first API call - Multiple failed API calls before success ``` ### 2. Pricing and Billing Friction **Symptoms**: - Downgrades before cancellation - Usage dropping to stay under limits - Questions about billing - Requests for enterprise/custom pricing **Root causes**: - Unpredictable costs - Expensive for early-stage - No free tier or too restrictive - Poor price-to-value perception - Billing surprises **Detection signals**: ``` - Sudden usage reduction after billing cycle - Pricing page visits from logged-in users - Support tickets about unexpected charges - API calls stopping mid-month ``` ### 3. Superior Alternatives **Symptoms**: - Sudden churn (not gradual) - Multiple team members churning together - Churning without complaints - "We're going a different direction" **Root causes**: - Competitor launched better feature - Open source alternative matured - Bigger player entered your space - Their stack changed (new language/framework) **Detection signals**: ``` - Sudden stop in usage (no gradual decline) - Competitor mentions in support/feedback - Traffic to your docs from competitor domains - Social mentions comparing you to alternatives ``` ### 4. Project Death **Symptoms**: - Gradual decline to zero - No support contact - Ignores all communication - Whole company churn **Root causes**: - Their project was cancelled - Startup failed - Prototype never went to production - Budget cuts **Reality check**: You can't prevent this. Don't waste energy trying. **Detection signals**: ``` - Slow decline over weeks/months - No login activity - No response to any outreach - Domain no longer resolves ``` ### 5. Integration Failure **Symptoms**: - High engagement then sudden stop - Technical support tickets unresolved - "Doesn't work with X" feedback - Stuck at implementation phase **Root causes**: - Your product doesn't fit their stack - Missing integration they need - Technical limitation they hit - SDK doesn't support their use case **Detection signals**: ``` - Lots of docs page views on specific integration - Support tickets about specific tech stack - API calls from testing environment only - "Evaluation" mentioned in communications ``` ### 6. Involuntary Churn **Symptoms**: - Churn after failed payment - No other warning signs - Often surprised when contacted **Root causes**: - Expired credit card - Card fraud protection - Changed payment method - Forgot to update billing **Detection signals**: ``` - Failed payment events - Usage continues until hard cutoff - Quick reactivation when contacted ``` --- ## Identifying At-Risk Developers ### Engagement Scoring Create a simple health score: | Signal | Weight | Calculation | |--------|--------|-------------| | API calls | 30% | This week vs last 4 week avg | | Login frequency | 20% | Days since last login | | Feature adoption | 20% | % of core features used | | Support sentiment | 15% | Positive/negative ticket ratio | | Billing health | 15% | Payment success, plan changes | **Health score thresholds**: - **80-100**: Healthy - continue nurturing - **60-79**: Watch - proactive outreach - **40-59**: At-risk - intervention needed - **0-39**: Critical - personal contact ### Early Warning Signs Monitor for these patterns: **Usage-based signals**: ``` - API calls dropped >50% week-over-week - No login in 14+ days - Stopped using new features - API errors increasing - Only using deprecated endpoints ``` **Support-based signals**: ``` - Multiple tickets on same issue - Negative sentiment in tickets - Questions about data export - Asking about contract/cancellation - Unusual silence from previously engaged user ``` **Billing-based signals**: ``` - Viewing pricing page while logged in - Downgrading plan - Removing team members - Asking about prorating cancellation ``` ### Building an Alert System Set up automated alerts: ``` ALERT: At-risk developer detected User: [EMAIL/COMPANY] Health score: 42 (was 78 last week) Triggers: - API calls down 73% this week - 2 unresolved support tickets (both negative sentiment) - Viewed pricing page 3 times Recommended action: Personal outreach from [OWNER] ``` --- ## Churn Interviews and Feedback ### The Right Approach **Do**: - Ask genuinely curious questions - Accept their decision gracefully - Make it about learning, not winning them back - Keep it short (5 questions max) - Offer something valuable for their time **Don't**: - Try to sell during the interview - Get defensive about feedback - Promise things to change their mind - Make them feel guilty - Take longer than 10 minutes ### Exit Survey (Email) ``` Subject: Quick question about your [PRODUCT] experience Hey [NAME], I noticed you've stopped using [PRODUCT]. No worries — these things happen. If you have 30 seconds, I'd genuinely love to know: What's the #1 reason you stopped? [ ] Found a better alternative [ ] Too expensive [ ] Too complicated to use [ ] Missing feature I needed [ ] Project ended / no longer needed [ ] Other: _____ Your feedback directly shapes our roadmap. Thanks for giving us a try. — [NAME], [TITLE] at [COMPANY] ``` ### Exit Interview Questions If they agree to a call (offer a $50 gift card or donation to their choice): 1. **Opening**: "Thanks for chatting. I'm not here to win you back — just want to understand your experience." 2. **Journey**: "Walk me through your experience with [PRODUCT], from signup to today." 3. **Breaking point**: "Was there a specific moment when you decided to stop using us?" 4. **Alternative**: "What are you using now instead? What made that a better fit?" 5. **Hypothetical**: "If you could wave a magic wand and change one thing about [PRODUCT], what would it be?" 6. **Close**: "Anything else you want us to know?" ### Analyzing Feedback Track churn reasons by category: | Category | % of Churn | Actionable? | Priority | |----------|------------|-------------|----------| | DX issues | 35% | Yes | High | | Pricing | 25% | Yes | Medium | | Alternatives | 20% | Partially | Medium | | Project death | 15% | No | None | | Integration gaps | 5% | Yes | Low | Focus energy on actionable categories with high impact. --- ## Win-Back Campaigns ### When to Win Back **Good candidates**: - Churned due to fixable issues (you've since fixed) - Left for alternative that's now inferior - Project death but new project starting - Billing/involuntary churn **Bad candidates**: - Left with strong negative sentiment - Fundamental product mismatch - Company no longer exists - Recently churned (wait at least 30 days) ### Win-Back Sequence **Timing**: Start 30-60 days after churn. Not sooner. **Email 1: What's new (Day 30)** ``` Subject: [PRODUCT] update: [SPECIFIC THING THEY CARED ABOUT] Hey [NAME], I know you moved on from [PRODUCT] a while back. Totally respect that. Quick update: We [SPECIFIC IMPROVEMENT RELEVANT TO THEIR CHURN REASON]. [1-2 sentence details with link to changelog/announcement] If your situation has changed, we'd be happy to have you back. If not, no worries — hope you're building great things. — [NAME] ``` **Email 2: Social proof (Day 45)** ``` Subject: How [COMPANY SIMILAR TO THEIRS] uses [PRODUCT] now Hey [NAME], Thought you might find this interesting — [SIMILAR COMPANY] just shared how they're using [PRODUCT] to [RELEVANT USE CASE]. [Link to case study or technical post] Might spark some ideas for your current project. — [NAME] ``` **Email 3: Direct offer (Day 60)** ``` Subject: Would 30 days free help? Hey [NAME], Last note from me. If you've been thinking about giving [PRODUCT] another shot, I can set you up with 30 days free on whatever plan you need. Just reply and I'll make it happen. If not, I'll stop emailing. Thanks for reading this far. — [NAME] ``` ### Win-Back Offers Appropriate offers for developers: | Offer | When to Use | |-------|-------------| | Extended free tier | Price-sensitive churners | | Free upgrade for 30 days | Feature-gap churners | | 1:1 technical help | DX-issue churners | | Early access to new feature | Competitor-switch churners | | Nothing (just information) | Project-death churners | **What NOT to offer**: - Permanent discounts (sets bad precedent) - Desperate "please come back" messaging - Anything to project-death churners --- ## Monitoring Competitor Switches ### Social Listening Setup Set up monitoring for: 1. **Direct mentions**: - "[Your product] vs [Competitor]" - "Switching from [Your product] to [Competitor]" - "Migrating away from [Your product]" 2. **Problem space discussions**: - Monitor conversations in your category - See what alternatives people recommend - Track sentiment about your product vs others 3. **Competitor momentum**: - Track competitor mentions and sentiment - New features they're launching - Developer reactions to their updates ### Competitive Intelligence Workflow ``` Weekly review: 1. Check social listening tools for: - Any mentions of switching from you - Competitor launches or announcements - Developer complaints about your category 2. Analyze patterns: - Are switches going to one competitor? - What features/issues drive switches? - What's competitor doing that resonates? 3. Update churn prevention: - Add new at-risk signals - Prioritize features that prevent switches - Address common complaints ``` --- ## Reducing Involuntary Churn Involuntary churn (payment failures) is often 20-40% of total churn. Fix it. ### Prevention | Strategy | Implementation | |----------|----------------| | Card expiration warnings | Email 30 and 7 days before | | Multiple payment methods | Allow card + PayPal + ACH | | Annual billing incentives | 2 months free for annual | | Dunning emails | 3-4 emails over 14 days | | Grace period | 7-14 days before hard cutoff | | In-app warnings | Banner when payment method needs update | ### Dunning Sequence **Email 1: Immediate** ``` Subject: Payment failed — update your card Hey [NAME], We couldn't process your payment for [PRODUCT]. Update your card: [LINK] Your account is still active. We'll retry in 3 days. — [PRODUCT] ``` **Email 2: Day 3** ``` Subject: Second attempt failed — action needed Hey [NAME], Still can't process your payment. Your service will be interrupted on [DATE] if we can't charge a valid card. Update now: [LINK] Having trouble? Reply and we'll help. — [PRODUCT] ``` **Email 3: Day 7** ``` Subject: Your [PRODUCT] account will be paused in 3 days Hey [NAME], Final notice: Your account will be paused on [DATE]. This means: - API keys will stop working - Webhooks will be disabled - Your data stays safe (we keep it for 90 days) Update your payment: [LINK] — [PRODUCT] ``` **Email 4: Day 10** ``` Subject: Your account has been paused Hey [NAME], Your [PRODUCT] account is now paused due to payment failure. To reactivate: 1. Update your payment method: [LINK] 2. Your service will resume immediately Your data is safe and will be kept for 90 days. Questions? Reply to this email. — [PRODUCT] ``` ### Recovery Tactics | Tactic | Impact | |--------|--------| | Smart retries | Retry 3-5 times over 2 weeks at different times | | Card updater services | Automatically update expired cards | | Alternative payment request | "Try a different card?" | | Payment link in dunning | Direct link, not "log in to update" | | Phone/SMS for enterprise | High-value accounts get personal contact | --- ## Churn Metrics Dashboard ### Key Metrics | Metric | How to Calculate | Target | |--------|------------------|--------| | Monthly churn rate | Churned users / Starting users | <5% | | Net revenue churn | Lost revenue - expansion / Starting MRR | <2% | | Time to churn | Avg days from signup to churn | Increasing | | Win-back rate | Returned users / Churned users | >5% | | Involuntary churn % | Payment churn / Total churn | <20% | ### Cohort Analysis Track retention by: - **Signup month**: Are recent cohorts retaining better? - **Acquisition source**: Which channels produce sticky users? - **Plan type**: Do paid users retain better than free? - **Activation status**: Do activated users retain better? ### Health Score Tracking ``` Weekly health score distribution: Healthy (80-100): 65% of users Watch (60-79): 20% of users At-risk (40-59): 10% of users Critical (0-39): 5% of users Trend: At-risk increased 3% this week (investigate) ``` --- ## Common Mistakes | Mistake | Why It Fails | Fix | |---------|--------------|-----| | Ignoring project death | Wasting resources on unwinnable users | Accept it and focus on actionable churn | | Offering discounts first | Trains users to threaten churn for discounts | Lead with value, not price | | Win-back too soon | Feels desperate, annoys recently churned | Wait 30+ days | | Not listening to feedback | Repeating the same mistakes | Actually fix what they complained about | | Generic win-back campaigns | Irrelevant messages get ignored | Personalize based on churn reason | | Blaming developers | "They just didn't get it" | Your DX is the problem | --- ## Tools | Tool | Use Case | |------|----------| | **[Octolens](https://octolens.com)** | Monitor competitor switches, track developer sentiment, detect early warning signs from social mentions | | **Segment** | Track usage events for health scoring | | **Amplitude/Mixpanel** | Cohort analysis and retention tracking | | **Customer.io** | Automated at-risk and win-back sequences | | **Stripe** | Dunning management for involuntary churn | | **Profitwell Retain** | Specialized churn reduction for payments | --- ## Related Skills - `developer-audience-context` — Understand alternatives and pain points - `developer-email-sequences` — Re-engagement and win-back emails - `competitor-tracking` — Monitor competitive landscape - `developer-listening` — Capture feedback before churn - `developer-onboarding` — Prevent churn at the source ## Limitations - Use this skill only when the task clearly matches its upstream source and local project context. - Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes. - Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.