How to Manage 20+ Android Apps as a Solo Developer Without Burning Out

People always ask: how do you maintain 22 apps alone?

The honest answer is that most of the work is architecture decisions made years ago. If every app is a snowflake with its own patterns, dependencies, and release process, managing 20 is impossible. If they share 80% of their structure, managing 20 is manageable.

Here's what actually works.

The Architecture Decision That Enables Scale

Every app I build follows the same structure:

app/
├── data/           # Room DAOs, API clients, repositories
├── domain/         # Use cases, domain models
├── presentation/   # ViewModels, Compose screens
└── di/             # Hilt modules

Same package structure. Same layer names. Same patterns for state management (StateFlow), DI (Hilt), navigation (Compose Navigation), and async (Coroutines + Flow).

When I context-switch between apps, the mental model doesn't change. I know where the repository is. I know how state flows from the ViewModel to the UI. There's no "wait, how does this one work?"

This isn't about being dogmatic. It's about reducing cognitive overhead.

Shared Tooling Across All Apps

Common build configuration:

All apps use a version catalog (

libs.versions.toml

[versions]
kotlin = "2.1.20"
compose-bom = "2025.05.00"
hilt = "2.51"
room = "2.6.1"

[libraries]
compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "compose-bom" }
hilt-android = { group = "com.google.dagger", name = "hilt-android", version.ref = "kotlin" }
room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" }

When Hilt releases a new version, I update one file and run

cross-sdk-update.sh

Common scripts:

• code Copy

  dependency-check.sh

  — checks all apps for outdated dependencies
• code Copy

  release-status.sh

  — shows version/uncommitted changes across all apps
• code Copy

  version-bump.sh

  — bumps version in
  code Copy

  config/version.properties

These live in

~/.claude/

The Release Calendar

22 apps can't all release in the same week. I maintain a simple release calendar:

Most apps release on a 4-6 week cycle. Critical bug fixes release immediately on any app that needs it.

The calendar prevents the "everything is due this week" panic.

CI Does the Heavy Lifting

Every app has the same GitHub Actions configuration:

# Triggered on every PR
- Run unit tests
- Run lint
- Build debug APK

# Triggered on tag v*.*.*
- Build signed release AAB
- Upload to Play Store internal track

A release is: merge PR → create tag → CI builds and uploads automatically. No manual build steps.

This removes the cognitive burden of "did I build with the right signing config?" and "did I upload to the right track?"

The Triage System

With 22 apps, bugs and feature requests come in constantly. Without a triage system, everything feels urgent and nothing gets done.

My priority system:

• P0 — Crash affecting > 1% of sessions: Fix immediately, release hotfix same day
• P1 — Major functionality broken: Fix in next sprint (1-2 weeks)
• P2 — Minor bug: Fix in next scheduled release
• P3 — Feature request / enhancement: Backlog, reviewed monthly

Each app has a GitHub Issues board. Weekly I spend 30 minutes reviewing all boards and assigning priorities. Daily I work on whatever P0/P1 items exist.

Context Switching Strategy

Switching between apps is the hidden productivity killer. A 10-minute task becomes 25 minutes when you spend 15 minutes re-orienting.

What I do:

Keep one app per day as primary. Don't jump between 5 apps in one day unless there's a P0.

Leave a "breadcrumb" when switching. Before stopping work on an app, write one sentence in the commit message or a TODO comment: "Next: add input validation to task title field before implementing the sync logic."

Git stash before switching. Don't context-switch with uncommitted changes — you'll forget which app they're for.

What Doesn't Scale: Doing Everything Manually

Things I've automated that solo devs often do manually:

• Dependency updates:
  code Copy

  dependency-check.sh

  tells me which apps need updates. I don't manually check Maven Central for each app.
• Release process: CI builds and uploads. I create a git tag.
• Signing: Secrets are in GitHub. No manual keystore management at release time.
• Cross-app gitignore sync:
  code Copy

  sync-common-files.sh

  keeps the same
  code Copy

  .gitignore

  across all repos.

If a task is done more than once a month the same way, it should be a script.

Mental Health: The Real Bottleneck

22 apps means 22 potential P0 incidents at any time. Burnout is a real risk.

What helps:

• Time-boxing: Work on apps from 9am-12pm. 12pm-3pm is for new development or blog writing. No app work after 3pm.
• Acceptance that maintenance is real work. Keeping 22 apps current with Android API changes, Play Store requirements, and library updates IS product work.
• Saying no to feature requests. Most feature requests in small apps don't get built. A polite "not in the roadmap currently" and moving on is the sustainable answer.

The goal isn't to be maximally productive. It's to be sustainable across years.

Takeaways

• Identical architecture across all apps eliminates context-switching overhead
• Shared tooling (version catalogs, scripts, CI templates) multiplies your leverage
• A release calendar prevents "everything is urgent" chaos
• Automate everything that happens more than monthly
• The real scaling limit is mental bandwidth, not technical complexity — protect it