What It Actually Takes to Build a $19/Month Android App Solo

There’s a specific kind of hubris that comes with deciding to compete with Calm and Headspace as a solo developer. I have it. This is what I’ve learned so far.

The quality bar is not where you think it is

When I set SAM’s price at $19/month, I committed to a quality level that most indie apps don’t hit. Not because of the price itself, but because of who pays that price.

Users who spend $19/month on a wellness app are not comparing you to other indie apps. They’re comparing you to Calm, to Notion, to Linear. They have a reference point for what premium software feels like. You have to meet that.

The practical implication: every screen matters. Not just the onboarding. Not just the paywall. The settings screen. The error states. The loading states. The empty states. All of it.

Kotlin Multiplatform is worth the bet

I chose KMP knowing it’s not fully stable and the iOS story was still maturing. The reason: I write Kotlin every day, and the alternative was maintaining two separate codebases or giving up on iOS eventually.

The tradeoff in practice:

• Android is the primary target and gets everything first
• Shared business logic (data models, repositories, use cases) is in commonMain and works without modification on both targets
• UI is platform-specific — Compose for Android, eventually SwiftUI for iOS

The part that’s underrated: having your domain logic in pure Kotlin with no Android dependencies makes it dramatically more testable. No instrumentation tests needed for business logic.

The AI architecture decision I keep not regretting

The easiest thing would have been to call OpenAI for everything. One API key, one integration, done.

I didn’t do that for two reasons:

Privacy: OpenAI gets your data. For a mental health app, that’s a meaningful concern.

Cost: At scale, per-token API costs compound. On-device inference has a fixed cost (device compute). For the features that run on every log entry — sentiment classification, theme extraction — on-device is the only unit economics that work at $19/month.

The InferenceOrchestrator abstraction means I can route different tasks to different providers based on complexity and privacy requirements. Groq for fast cloud inference when needed. Local model for everything that can run locally.

The thing that took longest: the subscription flow

Subscriptions on Android are miserable to implement correctly. Not because RevenueCat isn’t good (it is), but because there are so many edge cases:

• User subscribes → app updates → entitlement check happens before RevenueCat SDK initializes
• User subscribes on web → app doesn’t know
• Trial ends → user doesn’t get a downgrade screen, just silently loses features
• Restore purchases flow on a new device

Every one of these is a potential support ticket or a chargeback. Getting them right took longer than any single feature I’ve built.

What I’d tell myself at the start

Ship uglier, sooner. I spent too long perfecting screens no user had ever seen. The feedback from the first 50 users was worth more than three months of solo iteration.

The Insights screen first. I eventually used the analytics/insights screen as my quality reference for everything else. I should have built that first and propagated its design language outward, rather than building screens in the order they appear in the user flow.

Docs for your own future self. I have a CLAUDE.md in the repo that describes the architecture, conventions, and decisions. I started treating my AI coding assistant as a junior developer who needs context. Writing that doc made both of us more productive.

---

More posts on the specific technical decisions coming. If there’s something specific about the KMP setup, the AI inference architecture, or the Supabase integration you want me to write about, let me know.