Building 20+ Android Apps Solo — What I Learned About Architecture

After shipping more than 20 Android apps solo — everything from habit trackers to sleep monitors to focus tools — I've made the same architectural mistakes enough times to know exactly what works and what quietly destroys you at 2am before a Play Store deadline.

Here's what I landed on, and why.

The Mistake Everyone Makes First

When you're building your first Android app, you put everything in the Activity. It works. Then you add a second screen, a third, a network call, a database — and suddenly you have a 1000-line Activity that nobody (including future-you) can read.

The second mistake is overreacting and building a giant framework before you have anything to show. I've done both.

The right level of structure is: just enough to not drown.

MVVM + Clean Architecture

Every app I ship now follows the same three-layer pattern:

Data layer — repositories, Room DAOs, DataStore, network calls. Nothing here knows about the UI.

Domain layer — one UseCase class per action.

GetHabitsUseCase

LogWaterUseCase

CompleteOnboardingUseCase

Presentation layer — ViewModels that hold

StateFlow<UiState>

The rule I enforce: if a Composable contains an

if

Why StateFlow Over LiveData

LiveData requires an Activity or Fragment lifecycle owner. StateFlow doesn't. When I moved to pure Compose, I stopped needing lifecycle owners for UI observation — StateFlow just works.

The other reason: StateFlow is explicit about initial state. You declare

MutableStateFlow(initialValue)

Hilt Over Manual DI

I tried manual dependency injection once. You create a factory, pass it everywhere, update 12 files when a constructor changes. It's miserable.

Hilt adds two annotations to your module, one to your ViewModel, and everything gets wired automatically. The compile-time validation means you find missing dependencies at build time, not runtime.

The rule:

@HiltViewModel

@Provides @Singleton

KSP Over KAPT

KAPT (Kotlin Annotation Processing Tool) is deprecated. It compiles Kotlin to Java stubs, runs Java annotation processors, then compiles back. It's slow and occasionally broken.

KSP (Kotlin Symbol Processing) processes Kotlin directly. Build times dropped noticeably on my larger projects. Room, Hilt, and every major library support it. There's no reason to use KAPT in a new project today.

One Mistake That Cost Me Twice

I shipped two apps with bare

CoroutineScope(Dispatchers.IO).launch {}

@Singleton

The fix is one extra class:

@Qualifier @Retention(AnnotationRetention.BINARY)
annotation class ApplicationScope

@Provides @Singleton @ApplicationScope
fun provideApplicationScope(): CoroutineScope =
    CoroutineScope(SupervisorJob() + Dispatchers.IO)

Inject

@ApplicationScope CoroutineScope

What I'd Tell Myself Starting Out

1. Pick an architecture and stay consistent. The specific choices matter less than applying them uniformly. Mixed patterns across screens are harder to debug than a slightly imperfect pattern applied everywhere.

2. UseCase classes feel over-engineered until they save you. When you need to reuse logic across two ViewModels, or test business logic without mocking Android, you'll be glad it's in its own class.

3. StateFlow initial state is not optional. Every screen should render something on first observation. Define your sealed class or data class upfront.

4. KSP from day one. Never KAPT.

5. Hilt is not boilerplate — it's leverage. The annotations pay for themselves the first time you need to swap an implementation for tests.

The architecture isn't the goal. Shipping apps that don't embarrass you in six months is the goal. These choices just happen to make that easier.

All 20+ apps are live on Google Play under SudarshanTechLabs.