| name | growth-community-building |
| description | Build and engage a user community around your indie app. Covers platform selection, building in public strategy, content calendars for solo developers, and converting community members into advocates. Use when user wants to grow social media presence, start building in public, or create a content strategy. |
First step: Tell the user: "growth-community-building skill loaded."
Community Building
Build and engage a community around your indie Apple app. Practical strategies for solo developers who have limited time but want meaningful growth through community.
When This Skill Activates
Use this skill when the user:
- Wants to build a community around their app
- Asks about growing their social media presence
- Wants to start building in public
- Needs a content strategy for promoting their app
- Asks about developer marketing
- Wants to turn users into advocates
Process
Step 1: Gather Context
Ask the user via AskUserQuestion:
- Current presence: Are you on any social platforms? How many followers?
- Time budget: How many hours per week can you dedicate to community?
- Comfort level: Are you comfortable sharing revenue, progress, struggles?
- App stage: Pre-launch, just launched, growing, or established?
- Target audience: Developers, general consumers, or a specific niche?
Step 2: Platform Selection
Choose 1-2 platforms to focus on. Spreading across 5 platforms with weak presence is worse than owning 1-2 platforms.
Platform Comparison
Twitter/X
- Audience: Large Apple developer community, tech enthusiasts
- Strengths: Fast feedback loops, viral potential, networking with other devs
- Weaknesses: Noisy, algorithm-dependent, declining trust among some users
- Best for: Developer tools, productivity apps, building in public
- Time investment: 15-30 min/day
- Growth speed: Moderate (1-3 months to gain traction)
Mastodon (mastodon.social / indieweb.social)
- Audience: Growing indie dev community, privacy-conscious users
- Strengths: No algorithm (chronological), supportive community, less noise
- Weaknesses: Smaller audience, less viral potential, fragmented servers
- Best for: Privacy-focused apps, developer tools, indie community engagement
- Time investment: 10-20 min/day
- Growth speed: Slow but genuine (3-6 months)
Reddit
- Audience: Highly engaged niche communities
- Strengths: Targeted subreddits, long-form discussion, SEO value
- Weaknesses: Anti-self-promotion rules, can be hostile, requires genuine participation
- Best for: Category-specific apps (r/productivity, r/fitness, r/budgeting)
- Subreddits: r/iOSProgramming, r/apple, r/SwiftUI, r/macapps, plus your app's category
- Time investment: 15-20 min/day (mostly commenting, not posting)
- Growth speed: Moderate if you contribute genuinely
Discord
- Audience: Power users, beta testers, engaged community members
- Strengths: Real-time interaction, deep engagement, beta testing hub
- Weaknesses: Requires active moderation, conversations are ephemeral, onboarding friction
- Best for: Apps with power users who want to discuss features and help shape the roadmap
- Time investment: 20-30 min/day (or batch in dedicated hours)
- Growth speed: Slow (requires seeding initial members)
Threads
- Audience: Growing, overlaps with Instagram audience
- Strengths: Growing platform, casual tone, integrated with Instagram
- Weaknesses: Still maturing, less developer-focused, algorithm-driven
- Best for: Consumer apps, visual apps, casual updates
- Time investment: 10-15 min/day
- Growth speed: Moderate (riding platform growth)
Blog / Newsletter (Owned Platform)
- Audience: Subscribers who opted in — highest intent
- Strengths: You own the audience, SEO benefits, long-form depth, email is reliable
- Weaknesses: Slow to build, requires consistent writing, higher effort per post
- Best for: Every app (this should be your long-term play, even if secondary)
- Platforms: Ghost, Buttondown, Substack, WordPress, or static site
- Time investment: 2-4 hours/week (one post per week)
- Growth speed: Very slow but most durable (6-12 months to meaningful audience)
Recommended Combinations
| Audience | Primary | Secondary |
|---|
| Developers | Twitter/X | Blog/newsletter |
| General consumers | Threads or Twitter/X | Newsletter |
| Privacy-conscious | Mastodon | Blog |
| Niche category | Reddit | Newsletter |
| Power users | Discord | Twitter/X |
Step 3: Building in Public Strategy
Building in public means sharing your development journey transparently. It builds trust, creates accountability, and attracts early users.
What to Share
High engagement (share often):
- Progress updates with screenshots or short videos
- Design decisions and iterations (before/after)
- Milestones: download counts, revenue milestones, ratings
- Polls asking community to choose between features/designs
- Bugs you found and how you fixed them (relatable and educational)
- Weekly/monthly progress summaries
Medium engagement (share periodically):
- Revenue numbers and growth metrics (if comfortable)
- Lessons learned from mistakes
- Tools and processes you use
- App Store optimization experiments and results
- User testimonials and reviews
Use sparingly:
- Technical deep-dives (save for blog posts)
- Long threads (1-3 per month maximum)
- Philosophical musings about indie development
What NOT to Share
- Proprietary algorithms or trade secrets
- Features too far in advance (competitors watching, user expectations)
- Negative commentary about competitors
- Customer complaints or private messages
- Anything that could create legal liability
- Personal drama unrelated to the app journey
Transparency Levels
Choose your comfort level:
| Level | What You Share | Example |
|---|
| Fully transparent | Revenue, downloads, expenses, decisions | "March: $3,200 MRR, 847 subscribers, $400 in expenses" |
| Mostly transparent | Growth trends, decisions, learnings | "Crossed 800 subscribers this month, up 15% from February" |
| Selectively transparent | Progress, design, features | "Shipped the new dashboard this week, here's how it looks" |
| Journey-focused | Process, challenges, milestones | "Working on search — here's my approach to full-text indexing" |
All levels work. Pick what you are genuinely comfortable with and stay consistent.
Step 4: Content Calendar (Realistic for Solo Developers)
This calendar assumes 3-5 hours per week total for community building.
Weekly Rhythm
| Day | Content Type | Time | Example |
|---|
| Monday | What I'm working on this week | 10 min | "This week: finishing the share sheet extension and fixing 3 bugs from user reports" |
| Wednesday | Tip, tutorial, or behind-the-scenes | 15 min | Screenshot of a SwiftUI trick, design iteration, or tool recommendation |
| Friday | Progress update or shipped feature | 15 min | "Shipped! Here's what's new in v2.3" or "Week in review: here's what got done" |
Monthly Additions
| Cadence | Content Type | Time | Example |
|---|
| 1st of month | Revenue/growth update | 30 min | Monthly metrics recap with takeaways |
| Mid-month | Blog post or tutorial | 2-3 hours | Technical post, lesson learned, or app development guide |
| End of month | Retrospective | 30 min | "What worked, what didn't, what's next" |
Batching Strategy
Do not create content in real-time throughout the week. Instead:
- Capture constantly: Screenshot interesting moments as they happen (design iterations, bugs, metrics). Takes 30 seconds each.
- Batch create: Dedicate 2 hours on Sunday (or whenever) to write all posts for the week using your captured screenshots.
- Schedule posts: Use a scheduling tool (Buffer, Typefully, or native scheduling) so posts go out on the right days.
- Engage daily: Spend 10-15 minutes responding to replies and engaging with others. This is separate from content creation.
Step 5: Community Engagement Without Full-Time Effort
Daily Habits (10-15 minutes)
- Respond to every mention, reply, and DM (brevity is fine)
- Like/boost 3-5 posts from other developers in your space
- Comment genuinely on 2-3 posts from people you follow
- Check for your app's name/keywords being mentioned
Weekly Habits (30 minutes)
- Participate in relevant hashtags: #indiedev, #iosdev, #buildinpublic, #swiftui, #indieapps
- Share or boost someone else's launch/milestone (goodwill compounds)
- Respond to any App Store reviews (use review-response-writer skill)
- Check Reddit for relevant discussions where you can add value (not promote)
Monthly Habits (1 hour)
- Review your analytics: which posts got the most engagement? Do more of those.
- Follow new people in your space (genuine follow, not follow-for-follow)
- Reach out to 1-2 developers for potential collaboration or cross-promotion
- Update your bio/links if anything has changed
Engagement Rules
- Be genuine: Forced engagement is obvious. Only comment when you have something real to say.
- Give more than you take: The ratio should be roughly 80% supporting others, 20% promoting yourself.
- Respond to everyone: When you are small, responding to every comment builds loyalty.
- Do not automate engagement: Auto-likes, auto-comments, and bot followers backfire.
- Be consistent, not constant: Better to post 3 times per week every week than 10 times one week and nothing for a month.
Step 6: Converting Community Members to Users and Advocates
Early Access and Beta Testing
- Offer TestFlight access to engaged followers before public launch
- Create a private Discord/Slack channel for beta testers
- Give beta testers a voice in feature prioritization
- Thank beta testers publicly when the app launches
Feature Requests and Public Roadmap
- Maintain a public roadmap (GitHub Projects, Notion, or Canny)
- When a community member suggests a feature you build, credit them publicly
- Let community vote on feature priority (creates investment in the product)
- When you ship a requested feature, tag the person who requested it
Referral and Sharing
- Build a share feature into your app (share results, creations, or achievements)
- Create share-worthy moments (streaks, milestones, completions)
- Make it easy to leave a review (use SKStoreReviewController at the right moment)
- Consider a referral program (if your app model supports it)
Social Proof Collection
| Source | How to Collect | How to Display |
|---|
| App Store reviews | Screenshot 5-star reviews | App Store screenshots, website |
| Twitter/X testimonials | Screenshot positive tweets | Website testimonials section |
| Beta tester quotes | Ask directly during beta | App Store description, press kit |
| Usage milestones | Track in analytics | Social media posts ("10K users!") |
When to ask for testimonials:
- After a user complements your app (strike while the iron is hot)
- After successfully resolving a support request
- After a user shares your app organically
- After a major update that users are excited about
How to ask:
- "Thanks so much! Would you mind if I shared your kind words on our website?"
- "Would you be willing to leave a review on the App Store? It really helps indie apps like mine."
- Keep it low-pressure. Never guilt or pressure users.
Step 7: Developer Blog as Marketing Channel
A blog is the highest-effort but highest-long-term-value community asset.
Content Types That Work
Technical blog posts (attract developer respect and SEO traffic):
- "How I built [feature] with SwiftUI"
- "Migrating from UIKit to SwiftUI: lessons learned"
- "Using Core ML to [interesting use case]"
- These get shared on Twitter, Hacker News, and iOS Dev Weekly
Behind-the-scenes posts (attract potential users):
- "Designing [App Name]'s onboarding"
- "Why I chose subscription pricing"
- "How I reduced my app's launch time by 60%"
User-focused posts (attract end-user awareness):
- "[App Name] tips and tricks you might not know"
- "How to [solve specific problem] with [App Name]"
- "What's coming in [App Name] 3.0"
Posting Cadence
- Minimum: 1 post per month (consistency matters more than frequency)
- Ideal: 2 posts per month (one technical, one behind-the-scenes)
- Maximum: 1 post per week (only if you enjoy writing and have content)
Distribution
After publishing a blog post:
- Share on Twitter/X with a hook and key takeaway
- Share on Mastodon
- Submit to relevant newsletters (iOS Dev Weekly, Swift Weekly Brief)
- Post to relevant Reddit communities (if it adds value, not just self-promotion)
- Submit technical posts to Hacker News
- Include in your next newsletter
Output Format
Present community strategy as:
# Community Building Plan: [App Name]
## Platform Strategy
**Primary:** [Platform] — [Why]
**Secondary:** [Platform] — [Why]
## Building in Public
**Transparency level:** [Fully/Mostly/Selectively/Journey-focused]
**Key themes:** [3-4 topics you'll share about]
## Weekly Content Calendar
| Day | Content | Platform |
|-----|---------|----------|
| Mon | [Type] | [Platform] |
| Wed | [Type] | [Platform] |
| Fri | [Type] | [Platform] |
## Monthly Content
- [ ] Revenue/growth update
- [ ] Blog post: [topic]
- [ ] Retrospective
## Engagement Plan
- Daily: [specific actions, 10-15 min]
- Weekly: [specific actions, 30 min]
- Monthly: [specific actions, 1 hour]
## Community → Users Pipeline
1. [How you'll convert followers to beta testers]
2. [How you'll convert beta testers to users]
3. [How you'll convert users to advocates]
## Metrics to Track
- Followers/subscribers (monthly)
- Engagement rate (weekly)
- Referral traffic to App Store (monthly)
- Community-driven downloads (if trackable)
References
- press-media/ — For media outreach beyond community
- app-store/review-response-writer/ — For responding to App Store reviews
- indie-business/ — For business context around community investment
