How I Built a Portfolio of 10+ Apps as a Solo React Native Developer

February 2026

In 2017, I started teaching myself to code in Białystok, Poland. Today, I have 10+ React Native apps under my belt — some active, some sold, some retired.

This isn't a "how I made millions" story. It's about the unglamorous reality of building a sustainable app portfolio as a solo developer who started with zero mobile experience.

Table of Contents

From Logistics to Code

I started teaching myself to code in 2017. Not the typical "coding since I was 12" story.

I was curious about how the apps I used daily actually worked. So I started learning.

The timeline:

• 2017: Started learning JavaScript and React Native
• 2018-2019: Built apps, most never shipped
• 2020-2021: Started freelancing, learned how to actually ship
• 2022-2023: Built a portfolio of indie apps
• 2025: Sold two apps on Flippa
• 2026: Running Silpho (app studio) + still shipping indie apps

The key insight: You don't need 10 years of experience to build profitable apps. You need to solve real problems for real people.

The Freelancing Years

Freelancing taught me how to ship. Working with clients meant deadlines, real requirements, and apps that actually had to work.

What freelancing gave me:

• Experience with different React Native patterns
• Understanding of what makes apps feel "right"
• Client feedback on UI/UX decisions
• Revenue to support learning

The limitation:

Building for others taught me the craft, but not the business. Clients had the ideas, the market research, the vision. I was just the execution.

After 3 years of freelancing, I realized: I was good at building apps, but I had no idea how to come up with app ideas that people would pay for.

The Decision to Go Indie

The transition wasn't planned. In late 2021, I had a gap between freelance projects and decided to build something for myself.

The first experiment: Coldsmith

• Cold exposure tracking app
• Built it because I was doing Wim Hof breathing exercises
• Tiny niche, but passionate users
• First app to make any money from my own idea

The revelation:

Small, focused apps could be profitable. I didn't need to build the next Instagram. I needed to build tools that solved specific problems for specific people.

The mindset shift:

• From "build something huge" to "build something useful"
• From "find a big market" to "find an underserved niche"
• From "compete with big apps" to "serve small communities"

My App Portfolio Strategy

After Coldsmith worked, I developed a pattern:

Small and Focused

Every app does one thing well. No feature bloat.

Examples:

• Newsletterytics: Only Beehiiv analytics (not all newsletter platforms)
• MoonLatte: Only caffeine tracking (not all health metrics)
• TeleprompterX: Only teleprompter features (not video editing)
• FIFTN: Only focus timer (not a full productivity suite)

Quick to Build

Most apps take 2-4 weeks to ship the MVP. I'm not building enterprise software.

The stack that enables speed:

// Every app starts with this foundation
export const AppFoundation = {
  navigation: '@react-navigation/native',
  ui: 'react-native-paper', // or NativeBase
  storage: '@react-native-async-storage/async-storage',
  payments: 'react-native-purchases',
  analytics: '@segment/sovran-react-native'
}

Validated Ideas

I only build apps after seeing demand signals:

• Reddit posts asking for the solution
• Twitter threads about the problem
• Existing apps with terrible reviews
• Personal pain points I can't find solutions for

Independent Revenue Streams

Each app can stand alone financially. No dependencies.

The Apps That Made It

Here's my current portfolio with honest details:

Newsletterytics (4.6/5 stars, 10 ratings)

What it does: Analytics dashboard for Beehiiv newsletter creators

Why it works: Beehiiv's native analytics are basic. Creators want deeper insights.

Pricing: Free with IAP (Weekly $3.99, Monthly $9.99, Yearly $24.99, Lifetime $19.99)

Key insight: Started Beehiiv-only instead of trying to support all platforms

TeleprompterX (4.7/5 stars, 38 ratings)

What it does: Teleprompter app for video creators, especially iPad users

Why it works: Most teleprompter apps are either terrible or overpriced

Features: Apple Watch control, PiP mode, voice control, Bluetooth controller support

Key insight: The Apple Watch companion feature was the differentiator

BeatAI (AI Music Practice Coach)

What it does: AI-powered music practice companion with 40+ presets

Why it works: Simple interface for AI-assisted practice

Unique feature: "Smart AI Composer" - type anything, it converts to music instructions

Key insight: AI tools need human-friendly interfaces

The Other Apps

• Coldsmith: Cold exposure tracking (ice baths, cold showers)
• MoonLatte: Minimal caffeine tracker
• VidNotes: Video notes with AI summarization (my main focus right now)
• YapperX: Voice memos → shareable content
• FIFTN: Focus timer with smart app blocking

Pattern: All solve specific problems I had personally.

The Apps That Didn't

Not everything worked. Here's what failed and why:

Apps I Retired

• Early utility apps: Too generic, no clear value proposition
• Social experiment apps: Built features users didn't want
• Overly complex apps: Tried to solve too many problems

What I Learned from Failures

What I Learned About Building vs Selling

Two of my apps were acquired:

AIVidly (Sold 2025 on Flippa)

What it was: AI video creator, built in late 2024

Why I sold: Video generation was too expensive to maintain as a solo dev, and I couldn't grow the user base. ASO wasn't working.

Lesson: Sometimes an app needs resources you don't have.

Rhava → Bibleily (Sold 2025 on Flippa)

What it was: Bible app that became Bibleily after the sale

Why I sold: Basically zero users. The Bible app space is brutally competitive and I couldn't compete in ASO.

Lesson: A good product with no distribution is worth very little.

What Makes Apps Sellable

The Emotional Side of Selling

Selling apps you built is weird. It's like selling a piece of yourself. But it also validates that you built something valuable.

My rule now: Build every app like someone might want to buy it, but don't optimize for acquisition over user value.

The Technical Foundation That Scales

After building 10+ apps, these patterns consistently work:

Project Structure

src/
  components/     # Reusable UI components
  screens/        # Screen components
  services/       # API calls, storage, external integrations
  utils/          # Pure utility functions  
  types/          # TypeScript definitions
  hooks/          # Custom React hooks

The Stack That Scales

{
  "dependencies": {
    "react-native": "0.73.x",
    "@react-navigation/native": "^6.x",
    "react-native-paper": "^5.x",
    "@react-native-async-storage/async-storage": "^1.x",
    "react-native-purchases": "^7.x",
    "@tanstack/react-query": "^5.x"
  }
}

Code Patterns That Work

1. Screen-level state management

// Don't use Redux for simple apps
const useNewsletterScreen = () => {
  const [data, setData] = useState<Newsletter[]>([])
  const [loading, setLoading] = useState(false)
  
  const loadData = async () => {
    setLoading(true)
    try {
      const newsletters = await api.getNewsletters()
      setData(newsletters)
    } finally {
      setLoading(false)
    }
  }
  
  return { data, loading, loadData }
}

2. Service layer for external APIs

// services/newsletter.ts
export const NewsletterService = {
  async getStats(newsletterId: string): Promise<NewsletterStats> {
    const response = await fetch(/api/newsletter/${newsletterId}/stats)
    return response.json()
  },
  
  async getSubscribers(newsletterId: string): Promise<Subscriber[]> {
    const response = await fetch(/api/newsletter/${newsletterId}/subscribers)
    return response.json()
  }
}

3. Custom hooks for complex state

// hooks/useSubscriptionStatus.ts
export const useSubscriptionStatus = () => {
  const [isSubscribed, setIsSubscribed] = useState(false)
  
  useEffect(() => {
    Purchases.addCustomerInfoUpdateListener((info) => {
      setIsSubscribed(info.entitlements.active.premium !== undefined)
    })
  }, [])
  
  return { isSubscribed }
}

Debugging Setup That Saves Time

// .vscode/launch.json
{
  "configurations": [
    {
      "name": "Debug iOS",
      "request": "attach",
      "type": "reactnativedirect",
      "platform": "ios"
    }
  ]
}

Revenue Reality Check

Let me be honest about the numbers without giving specifics:

What "Profitable" Means

• Covers my living expenses in Poland
• Allows reinvestment in new app ideas
• Not "quit your day job in Silicon Valley" money
• Sustainable, not explosive

Revenue Patterns

• Subscription apps (Newsletterytics, BeatAI): Recurring revenue, higher LTV
• One-time purchase: Predictable conversion, lower LTV
• Freemium with IAP (TeleprompterX): Broader user base, conversion optimization challenges

What Surprised Me

The Portfolio Effect

Having multiple apps creates stability. When one app has a slow month, others compensate. It's like diversifying an investment portfolio.

What I'd Do Differently

Looking back, here's what I'd change:

Start with Revenue Models Earlier

I built too many apps thinking "I'll figure out monetization later." Start with how users will pay, then build the product.

Focus on Fewer Apps

I have too many apps to properly maintain. Better to have 5 excellent apps than 10 mediocre ones.

Build Email Lists from Day One

Every app should capture emails for users who want updates. This is the most valuable asset for future launches.

Document Everything

I spent months reverse-engineering my own code. Good documentation isn't just for teams.

Network More

The indie dev community is incredibly supportive. I should have connected with other developers sooner.

Learn Marketing Alongside Development

Building is 30% of success. Marketing, user acquisition, and retention are the other 70%.

The Ship React Native Connection

After building 10+ apps, I started noticing patterns. The same architectural decisions, the same boilerplate, the same mistakes.

That's why I created Ship React Native. It's not just a boilerplate - it's the distilled experience from all these apps. The foundation I wish I had when building Coldsmith.

What I packed into Ship RN:

• The project structure that scales from 1 to 10 apps
• The authentication flows that actually work
• The subscription setup that handles edge cases
• The debugging setup that saves hours
• The deployment pipeline that just works

I learned these lessons by building real apps for real users. Ship React Native lets you skip the expensive mistakes and start with what works.

Building a portfolio of React Native apps isn't about being a genius developer. It's about consistently shipping small, focused solutions to real problems.

Start with one app. Solve one problem. Ship it. Learn from users. Then build the next one.

The compounding effect of small apps solving real problems is more powerful than trying to build one perfect app.