Building a Premium Android App Solo (Honest Story)

Building a premium Android app solo means handling design, development, testing, and distribution without a team. For a mental health app, this includes implementing secure data handling, offline-first architecture, accessibility standards, and meeting medical content guidelines while maintaining a quality bar competitive with funded teams.

There’s a specific kind of hubris that comes with deciding to compete with Calm and Headspace as a solo developer. I have it. I wrote about why I built it in the first place. 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 $9.99/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 pay for 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. That means no gamification shortcuts, no cutting corners on data handling, no half-built features.

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. When someone is living with bipolar, the app has to work on their worst day, not just their best.

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 tracker where AI touches sensitive clinical data, that’s a meaningful concern.

Cost: At scale, per-token API costs compound. The InferenceOrchestrator abstraction means I can route different tasks to different providers based on complexity and privacy requirements (Groq for fast inference, HuggingFace as a free fallback) and swap providers without touching the rest of the app. This architecture powers everything from pattern detection to the daily insights.

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 things that actually matter, like tracking the right clinical signals, only became clear after real people used it.

The Insights screen first. I eventually used the analytics/insights screen (the one that powers episode prediction and pattern detection) 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.

---

If you’re curious about the privacy architecture, I wrote about how Steadyline keeps your mental health data safe. 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.