What I Learned Shipping a Spiritual App to 100+ Users and ₹15K Revenue in 3 Months

Source: Dev.to

For the past few months, I’ve been building Anahad — a spiritual app for sādhanas, pujas, and meditation. I recently shipped it to production on both app stores as a solo developer. Three months in, the app has 100 + monthly active users and has generated ₹15,000 in revenue from subscriptions and ads.

But the real lessons weren’t in the code. They were in everything that happened after I hit deploy.

The Numbers (Because Everyone Wants to Know)

• 100 + MAUs in 3 months
• ₹15,000 total revenue (~$13 from ads, rest from subscriptions)
• Zero marketing budget — all growth from WhatsApp community shares
• 3 languages (English, Hindi, Telugu) — this grew the user base from ~20 to 100
• User retention fluctuates between 90–140 MAUs, depending on the month

The Stack

Frontend

• Flutter

Backend

• NestJS
• PostgreSQL

Monetisation

• Adapty (subscriptions)
• Razorpay (payments)
• Google AdMob

Observability

• Sentry
• Axiom
• Uptime Kuma
• Firebase Crashlytics

1. The Backend Went Down Twice (And I Didn’t Know)

Early on, I made a rookie mistake: I shipped without proper monitoring.

The backend crashed twice, and I didn’t even know. I only found out when users started DM‑ing me:

“Hey, the app isn’t working.”

No Sentry. No uptime monitoring. No crash reports. Just blind panic and users waiting.

After scrambling to fix it both times, I immediately set up:

• Sentry for backend error tracking
• Uptime Kuma for service monitoring
• Firebase Crashlytics for mobile crashes
• Axiom for logging

Lesson: Observability isn’t something you add later. It’s the difference between knowing your app is down and your users telling you it’s down.

2. Building the App Was Easy. Selling It Is the Hard Part.

I spent months building features: clean architecture, optimised queries, beautiful UI. Then I launched.

Crickets… 🪲

What I learned: Engineering maturity isn’t about building things; it’s about building the right things.

My first 100 users came from one channel: WhatsApp groups. My guru runs a spiritual community that’s been active for 5 + years. I shared the app there. People tried it; some stayed.

• No ads
• No SEO
• No marketing campaigns

Just real people in a community who actually wanted what I built. That taught me more about product‑market fit than any course ever could.

3. Real Users Aren’t Tech‑Savvy (And That’s a Feature, Not a Bug)

When you build alone, you assume everyone thinks like a developer. They don’t.

Feedback I got:

• “The meditation timer stops when my screen locks.”
• “How do I delete my account?” (It existed — they just couldn’t find it)
• “Can you add Telugu? My mother wants to use this but doesn’t read English.”

That shifted my mindset. The question stopped being “What features should I add?” and became “How do I make this so smooth that my user’s 60‑year‑old mother can use it without asking questions?”

Resulting actions:

• Added translations: English, Hindi, Telugu
• Focused obsessively on UX

Outcome: Users grew from 20 → 100 and retention stabilised.

4. App Store Approval Is a Special Kind of Hell

Google Play Store: Approved in one shot. Easy.

Apple App Store: Absolute nightmare.

Rejections I dealt with:

1. “Your app doesn’t work on iPad.” – No explanation, just rejection.
2. “Add Sign in with Apple.” – Apple only gives the email on first registration, which forced handling weird edge cases.
3. “Your app doesn’t have delete‑account functionality.” – I replied with screenshots showing exactly where it was. They approved, then the same rejection appeared on the next build.

After multiple rounds of back‑and‑forth, it finally got approved.

Then came ASO (App Store Optimization):

• Learning keywords
• Optimising screenshots
• Writing descriptions in multiple languages

Lesson: Shipping to production isn’t a one‑time event. It’s an ongoing negotiation with gatekeepers.

5. An App with 4 Features People Use > An App with 10 Features Nobody Touches

In the beginning I was in builder mode: What can I add next?

By the third or fourth release, something interesting happened. Users weren’t asking for new features; they were asking for better versions of existing ones.

That click led to a new rule:

An app with 4 features people actually use is infinitely better than 10 features nobody touches.

My current process is ruthless:

• Does this make the core experience smoother?
• Does this remove friction?
• Will users even notice?

If the answer isn’t yes to all three, I don’t build it.

6. Revenue Is Real, But It’s Not Why You Keep Going

₹15,000 in 3 months isn’t life‑changing money. But seeing real people practising daily through something you built? That’s different.

The most rewarding moment wasn’t the first rupee. It was the first message from a stranger:

“This helped me stay consistent with my practice. Thank you.”

That’s when it hit me: I’m not just writing code anymore. I’m building something people rely on.

What I’d Tell My Past Self

If I could go back to day one, here’s what I’d say:

• Set up monitoring from day one. Don’t wait for things to break.
• Ship fast, but ship to real users. Feedback beats perfection.
• Your users aren’t developers. Design for your users’ parents.
• App‑store approval will test your patience. Budget extra time.
• Growth comes from community, not code. Find where your users already are.
• Mature as a product thinker, not just an engineer.

The hard part isn’t building. It’s shipping, listening, and iterating.

It’s knowing what to build.

What’s Next

We’re now shifting from organic growth to actual marketing.

• The product works.
• Users are retained.
• Now it’s about reach.

If you’re a solo developer sitting on an idea:

• Stop overthinking.
• Start shipping.
• Let the market sculpt you.

Real learning doesn’t start when you write your first line of code. It starts when your code meets real users.