DEV Community: Utkarsh Mishra

🦀 Rust Foundations — The Stuff That Finally Made Things Click

Utkarsh Mishra — Sat, 04 Apr 2026 08:41:36 +0000

"Rust compiler and Clippy are the biggest tsunderes — they'll shout at you for every small mistake, but in the end… they just want your code to be perfect."

Why I Even Started Rust

I didn't pick Rust out of curiosity or hype.

I had to.

I'm working as a Rust dev at Garden Finance, where I built part of a Wallet-as-a-Service infrastructure. Along with an Axum backend, we had this core Rust crate (standard-rs) handling signing and broadcasting transactions across:

Bitcoin
EVM chains
Sui
Solana
Starknet

And suddenly… memory safety wasn't "nice to have" anymore.

It was everything.

Rust wasn't just a language — it was a guarantee.

But yeah… in the beginning?

It felt like the compiler hated me :(

So I'm writing this to explain Rust foundations in the simplest way possible — from my personal notes while reading "Rust for Rustaceans".

What is a "value" in Rust?

A value in Rust is:

Type + actual data from that type's domain

let x = 42;

This isn't just 42. It's:

Type: i32
Value: 42

Rust always tracks both. That's why it feels stricter than dynamically typed languages like Python or JavaScript — there's no "figure it out at runtime." Rust knows everything at compile time.

Borrowing — The part that scares everyone

Let's look at this:

fn main() {
    let mut x = 42;

    let y = &x;        // immutable borrow
    let z = &mut x;    // mutable borrow

    println!("{}", z);
    println!("{}", y);
}

Your brain immediately says:

"You can't have a mutable and immutable borrow at the same time. This should fail."

And classically, you'd be right.

But here's the thing that changed everything for me:

Non-Lexical Lifetimes (NLL)

Before NLL, Rust kept a borrow alive until the end of the scope block {}. That made the code above illegal — y would still be "alive" when z tried to take a mutable borrow.

After NLL (which is now the default), Rust is smarter. It keeps a borrow alive only until its last actual use.

Let's trace what the compiler sees:

y is created   (immutable borrow of x)
y is never used again
→ borrow ends immediately

z is created   (mutable borrow of x)
→ no active immutable borrows exist
→ ✅ Allowed

Rust isn't being lenient. It's being precise.

NLL made Rust go from "technically correct but infuriating" to "actually ergonomic."

Memory — Stack vs Heap vs Static

This is the part where things start clicking.

┌─────────────────┐
│  Static/Data    │ ← Binary code + static variables + string literals
│  Segment        │   (baked into your executable)
├─────────────────┤
│  Heap           │ ← Box, Vec, String (grows upward →)
│       ↕         │
│       ↕         │
│  Stack          │ ← Local variables, function calls (grows downward ←)
└─────────────────┘

Stack

Fastest read/write memory
Each function call creates a stack frame — a contiguous chunk holding all local variables and arguments for that call
Stack frames are the physical basis of lifetimes — when a function returns, its frame is popped, and everything in it is gone

Heap

A pool of memory not tied to the call stack
Values here can live past the function that created them
Access via pointers — you allocate, get back a pointer, pass it around
Easiest way to heap-allocate: Box::new(value)
Want something to live for the entire program? Use Box::leak():

// This gives you a 'static reference — lives forever
let config: &'static Config = Box::leak(Box::new(load_config()));

Static Memory

Part of your actual binary on disk
static variables and string literals ("hello") are baked directly into the executable
Loaded into memory when the OS runs your program

`&str` vs `String` — The Confusion Killer

These two look similar but live in totally different places.

`&str` — a borrowed view into existing bytes

Stack:
┌─────────────┐
│ s: &str     │ ← pointer + length (that's it)
│ ptr: 0x1000 │ ───┐
│ len: 5      │    │
└─────────────┘    │
                   │
Static Memory:     │
┌─────────────┐    │
│ 0x1000:     │ ←──┘
│ "hello"     │   ← baked into your binary
└─────────────┘

The reference (ptr + len) lives on the stack. The actual bytes live in static memory, embedded in your binary at compile time.

&str is immutable and borrowed — you don't own the data.

`String` — owned, heap-allocated bytes

Stack:
┌─────────────┐
│ s: String   │
│ ptr: 0x2000 │ ───┐
│ len: 5      │    │
│ cap: 5      │    │   ← also tracks capacity for growing
└─────────────┘    │
                   │
Heap:              │
┌─────────────┐    │
│ 0x2000:     │ ←──┘
│ "hello"     │   ← allocated at runtime, can grow
└─────────────┘

String owns its data. It can grow, shrink, be mutated.

When to use which:

Use `&str` when...	Use `String` when...
You just need to read/pass text	You need to own, build, or modify text
Taking function arguments (prefer `&str`)	Returning text from a function
Working with string literals	Reading user input or building dynamic strings

Quick rule of thumb: Function parameters? Use &str. Owned data you return or store in a struct? Use String.

`const` vs `static`

These look similar. They're not.

`const` — compile-time copy-paste

const MAX_RETRIES: u32 = 3;

No memory address. The compiler literally copy-pastes the value everywhere it's used
Every usage creates a fresh copy
Must be known at compile time (must implement Copy)
Think of it like a find-and-replace the compiler does before running anything

`static` — single memory location, lives forever

static MAX_POINTS: u32 = 100;

Has a real memory address — same one every time
Lives for the entire program ('static lifetime)
All references point to the same place
Exists in your binary's static memory section

You can actually see the difference:

const X: u32 = 5;
static Y: u32 = 5;

fn main() {
    println!("{:p}", &X);  // may print different addresses each time
    println!("{:p}", &X);  // copy-pasted, so may differ

    println!("{:p}", &Y);  // always the same address
    println!("{:p}", &Y);  // always the same address
}

Quick rule: Use const for magic numbers and fixed values. Use static when you need a single global memory location (like a config that multiple places reference).

Ownership — Rust's Core Rule

A value has exactly one owner. Always.

When the owner goes out of scope, the value is dropped. Memory is freed. No garbage collector needed.

let s1 = String::from("hello");
let s2 = s1;  // ownership MOVES to s2

println!("{}", s1);  // ❌ compile error: s1 is moved

Two important behaviors:

Primitive types (i32, f64, bool, etc.) implement Copy — they're duplicated on assignment, not moved
Heap data (String, Vec, Box) is moved — ownership transfers, the original is invalid

This is enforced by the borrow checker at compile time. Zero runtime cost.

Drop Order — Underrated but Powerful

Rust drops variables in reverse declaration order.

Why? Because a variable declared later might reference one declared earlier. Dropping in forward order could leave dangling references.

struct HasDrop(&'static str);

impl Drop for HasDrop {
    fn drop(&mut self) {
        println!("Dropping: {}", self.0);
    }
}

fn main() {
    let var1 = HasDrop("Variable 1");
    let var2 = HasDrop("Variable 2");

    let tuple = (
        HasDrop("Tuple elem 0"),
        HasDrop("Tuple elem 1"),
        HasDrop("Tuple elem 2"),
    );

    let var3 = HasDrop("Variable 3");

    println!("End of scope!");
}

Output:

End of scope!
Dropping: Variable 3      ← last declared, drops first
Dropping: Tuple elem 0    ← tuple drops, elements in SOURCE order
Dropping: Tuple elem 1
Dropping: Tuple elem 2
Dropping: Variable 2      ← variables drop in reverse
Dropping: Variable 1

Notice the split behavior:

What	Drop order	Why
Variables	Reverse	Later vars may reference earlier ones
Nested (tuple/struct fields)	Source order	Rust doesn't allow self-references within a single value

The `&mut` move problem

Here's a footgun related to ownership + mutable references:

// This is ILLEGAL — and for good reason:
fn broken(s: &mut String) {
    let stolen = *s;  // trying to move OUT of a mutable reference
    // s now points to... nothing? 💀
}

If you move a value out of a &mut reference, the original owner still exists and will try to drop it — causing a double free. Undefined behavior. Chaos.

The fix: use mem::replace() or mem::take() to safely swap in a new value:

use std::mem;

fn take_it(s: &mut String) -> String {
    mem::take(s)  // moves out the String, leaves an empty String in its place
}

Interior Mutability — Rust Bending Its Own Rules

Normally Rust's rule is:

Either many immutable references OR one mutable reference. Never both.

But sometimes you genuinely need to mutate something through a shared (&T) reference. That's where interior mutability comes in — it moves the borrow check from compile time to runtime.

For single-threaded code:

Cell<T> — for types that implement Copy:

use std::cell::Cell;

let x = Cell::new(42);
x.set(100);               // mutate through shared reference
println!("{}", x.get()); // 100

RefCell<T> — for types that don't implement Copy:

use std::cell::RefCell;

let v = RefCell::new(vec![1, 2, 3]);
v.borrow_mut().push(4);   // runtime borrow check

⚠️ The footgun with RefCell: The borrow check happens at runtime. If you violate the rules (two mutable borrows), it doesn't fail at compile time — it panics at runtime:

let v = RefCell::new(vec![1, 2, 3]);
let b1 = v.borrow_mut();
let b2 = v.borrow_mut(); // 💥 panics: already mutably borrowed

Use RefCell sparingly — it trades compile-time safety for runtime flexibility. If it panics in production, that's on you.

For multi-threaded code:

// Share AND mutate across threads:
let x = Arc::new(Mutex::new(vec![1, 2, 3]));

// Just need a fast counter across threads:
let x = Arc::new(AtomicU32::new(0));

// Read-only sharing across threads:
let x = Arc::new(vec![1, 2, 3]);

Note: Arc alone only gives you shared ownership — it does not give you mutability. You need Mutex (or RwLock) for that.

Quick cheat sheet:

Scenario	Use
Single thread, `Copy` type	`Cell<T>`
Single thread, non-`Copy` type	`RefCell<T>`
Multi-thread, any type	`Arc<Mutex<T>>`
Multi-thread, fast counter	`Arc<AtomicU32>`
Multi-thread, read-mostly	`Arc<RwLock<T>>`

Lifetimes — Don't Overcomplicate This

A lifetime ensures a reference doesn't outlive the data it points to.

Lifetimes are compile-time only — they're erased after compilation and have zero runtime cost.

The compiler infers most lifetimes automatically. You only write them explicitly when the compiler can't figure it out on its own.

// The compiler needs help here — which input does the output reference?
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

The 'a annotation says: "the output reference lives at least as long as the shorter of x and y."

Without it, the compiler has no idea whether the returned reference points to x or y — and therefore can't verify it's safe.

The dangling reference problem lifetimes solve:

fn dangle() -> &String {    // ❌ what lifetime does this have?
    let s = String::from("hello");
    &s                       // s drops here, reference would dangle
}

The compiler rejects this because the reference would outlive the data it points to. Lifetimes make this impossible to sneak through.

Final Thought

Rust isn't hard.

It just forces you to think clearly about:

who owns what
who borrows what
how long things live

The compiler isn't your enemy. It's a tsundere — it yells at you precisely because it refuses to let your code betray you in production.

Once that mental model clicks?

You stop fighting Rust… and start trusting it.

All notes from "Rust for Rustaceans" by Jon Gjengset. Highly recommend.

From Spaghetti to Structure: Why I Migrated My Production Flutter App to Clean Architecture

Utkarsh Mishra — Thu, 26 Mar 2026 15:50:56 +0000

"First make it work, then make it beautiful and robust."

I'm a junior dev. I built a real app — Anahad — that real people use. And for a while, I was proud of it.

Then it grew. And I wasn't so proud anymore.

This isn't a textbook post about Clean Architecture. This is the story of what broke, why I finally made the switch, and what actually clicked for me — told by someone who was in the trenches with a messy codebase and had to ship features at the same time.

The Mess I Was Living In

Picture this: 6 features. Each with their own screens, widgets, blocs, services, and utils — all distributed across a directory structure that looked neat on day one and became a labyrinth by month three.

Most screens were monoliths — all-in-one files with UI and logic tangled together. The ones that did use components? Everything went into a global widgets/ directory. So you'd have prop drilling across three levels just to pass something that one widget needed. Tracking the flow of data meant hopping between directories, mentally stitching together a picture of how things connected.

Error handling was... creative. I'd built my own AsyncResult<Success, Error> sealed class — functional programming vibes without the actual library. It worked at the service layer, but it was an island. Nothing else was consistent.

And the worst part? My services were tightly coupled to Dio and the remote API. No abstraction. No interface. You couldn't mock anything. You couldn't test anything. If Dio failed, the whole thing failed, and you had to dig to figure out why.

The moment I truly felt it was when I had to trace a bug and found myself drilling through 5 directories just to understand the flow. That's when I knew — this isn't scaling. This is surviving.

What Is Flutter Clean Architecture, Actually?

Before I get into the migration, let me walk you through the structure — because once it clicked, I couldn't unsee it.

Clean Architecture splits your app into three layers:

🎨 Presentation Layer

This is everything the user sees and touches.

Screens — Your UI pages
Widgets — Reusable UI components
Bloc — State management; the brain between UI and business logic

The Bloc only talks to the Domain layer. It doesn't know where data comes from. Doesn't care.

🧠 Domain Layer

This is the pure heart of your app. No Flutter. No Dio. No Firebase. Just Dart.

Entities — Plain Dart classes representing your core data models
Use Cases — Single-responsibility classes that each do one thing (e.g., LoginUseCase, FetchUserProfileUseCase)
Repository (Interface) — Abstract contracts defining what data operations exist, not how they work

This layer has zero dependencies on anything external. It's the most stable, most testable code in your app.

🗄️ Data Layer

This is where the real world connects.

Models — Extend your Entities; handle JSON serialization, API mapping
Repository (Implementation) — Implements the Domain's repository interface
Data Sources — Remote (Dio, Firebase) and Local (Hive, SQLite)

The magic line? The Repository Implementation delegates data fetching to the datasource. The domain doesn't care if it's coming from the internet or a local cache.

Bloc → UseCase → Repository Interface
                        ↑
              Repository Implementation → Remote / Local Datasource

The Migration: Incremental, Not a Rewrite

Here's the thing nobody tells you: you don't have to nuke your codebase.

I had features to ship. Users on the app. I couldn't just disappear for two weeks and "do clean architecture." So I went incremental.

I started with the auth flow — the most self-contained, most critical part of the app. My service methods were already well-written, so the migration was mostly structural:

Converted service methods into Use Cases
Moved Dio calls into a RemoteDataSource
Created a Repository Implementation that satisfied the Domain's abstract interface
Wired the Bloc to talk to the Use Case instead of the service directly

It wasn't that hard, honestly. But the payoff was immediate.

Now if I want to add offline support to Anahad? I create a LocalDataSource, and the Repository Implementation switches between them. The Bloc doesn't change. The Use Cases don't change. The Domain doesn't even know it happened.

That's the beauty.

fpdart and Functional Programming in Use Cases

Coming from a Rust background, I was already comfortable with Option and Result types. I'd even hacked together my own AsyncResult<Success, Error> sealed class before this migration.

When I discovered fpdart, it was like: oh, this is just the proper version of what I was already doing.

In my Use Cases, I now use Either<Failure, Success> for all return types. Left is failure, right is success — and you chain transformations cleanly without nested try-catches or nullable hell.

// Use Case
class LoginUseCase {
  final AuthRepository repository;

  LoginUseCase(this.repository);

  Future<Either<Failure, User>> call(LoginParams params) async {
    return await repository.login(params.email, params.password);
  }
}

// In the Bloc
final result = await loginUseCase(LoginParams(email: email, password: password));

result.fold(
  (failure) => emit(AuthError(failure.message)),
  (user)    => emit(AuthSuccess(user)),
);

No try-catch spaghetti. No "did this return null or did it actually fail?" ambiguity. The types tell the story.

The "Aha" Moment

I'll be honest — my first reaction to Clean Architecture was "this is way too much boilerplate."

Why write a Use Case class that just calls a repository method? Why create an abstract interface when I could just use the implementation directly? Seemed like over-engineering for the sake of it.

Then I migrated the auth flow. And something just... clicked.

I was looking at my Bloc, and I realized: this Bloc has no idea where the user data comes from. It doesn't import Dio. It doesn't know about Firebase. It just calls loginUseCase() and reacts to the result.

Before this, I couldn't test anything because everything was tightly coupled. The service needed Dio, Dio needed a real network, the network needed... you get it. Now, because the Repository is an abstract interface, I can mock it in tests trivially:

class MockAuthRepository extends Mock implements AuthRepository {}

That's it. Inject it. Test your Use Cases in complete isolation.

Ambiguity went away. I know exactly what each file does, what it depends on, and what it's responsible for. When something breaks, I know which layer to look at.

Should You Use Clean Architecture for Every App?

No. Please don't.

If you're building a weekend project or learning Flutter for the first time, don't start with Clean Architecture. You'll spend more time setting up the structure than building the thing, and you'll learn why the architecture exists without ever feeling the pain it solves.

The pain is the teacher.

Build the app. Ship it. Let it grow. Feel the moment where you're drilling through 5 directories to trace a bug, where you can't mock a thing for testing, where adding one feature means touching 8 files in 6 different folders.

Then reach for Clean Architecture. Because then you'll understand it — not just intellectually, but in your bones.

The architecture exists to solve real problems. Let the problems teach you first.

Quick Reference: The Layer Cheat Sheet

Layer	Contains	Depends On
Presentation	Screens, Widgets, Bloc	Domain only
Domain	Entities, Use Cases, Repository Interface	Nothing (pure Dart)
Data	Models, Repository Impl, Data Sources	Domain interfaces

What's Next for Anahad

Migrating the remaining 5 features incrementally
Adding a proper logging layer
Writing actual unit tests now that mocking is possible
Maybe offline support — and thanks to clean architecture, it'll be a datasource swap, not a rewrite

If you're a fellow junior dev with a production app that's starting to smell — I see you. You don't have to have everything figured out from day one. Build it, feel the pain, then build it better.

That's not a failure. That's engineering.

Built with love (and a lot of refactoring) while working on Anahad.
Hit me up on Twitter/X if this resonated — always happy to talk Flutter, architecture, or why Rust spoils you for everything else.

I Built a Spiritual App With AI and Watched My Users Disappear

Utkarsh Mishra — Sat, 21 Mar 2026 17:40:21 +0000

For five years, I've been walking the spiritual path with my guru. I've done the processes, sat through the practices, and experienced real transformation in my life. But here's what drove me crazy: finding authentic spiritual guidance online is nearly impossible.

You either get:

YouTube videos with hyped-up content that teaches you nothing
Blogs gatekeeping everything behind "contact this number for guru guidance"
Random people claiming to be masters when they have no idea what they're doing

I'd found the real thing—a legitimate guru, authentic processes that actually work—and I wanted other seekers to have access to the same structured path I had. So five months ago, I decided to build an app.

A hub for authentic meditations, mantras, and saadhnas (deity practices). Gamified with streaks and leaderboards. Progressive unlocking—certain processes only available when you reach specific levels. Discipline meets fun.

I had a vision. I had a full-time job. And I had AI to help me code after work.

What could go wrong?

The Honeymoon Phase: Shipping at Light Speed

Every evening after work, I'd open my IDE with two options:

Write everything from scratch
Prompt AI and ship features instantly

I chose speed.

I laid out the architecture myself—Android app, admin dashboard, backend, deployment flows—but then I let AI write the actual code. And honestly? It felt amazing.

Features shipped fast. Users loved it. Fellow spiritual seekers were finally finding something authentic and engaging. I told myself I was "focusing on the bigger picture"—what to build and when to ship it. The details? AI handled those.

The human mind is built for comfort. And I got very comfortable.

So comfortable that I stopped reviewing the logic entirely. I didn't know what was actually running in production. I just knew that features worked and users were happy.

Until they weren't.

The Collapse: When 50 People Stop Trusting You

One day, the complaints started flooding in.

"My streak isn't updating."

"The app freezes when I try to do my chanting practice."

"My meditation stats are completely wrong."

I watched my daily active user count plummet. All 50 of them—people who had finally found an authentic spiritual tool—were leaving.

And I sat there, staring at a codebase I'd "written," realizing I had no idea how any of it actually worked.

Bug #1: The Streak Calculation Nightmare

The streak logic was mixing UTC time and local time haphazardly in the backend. Users' meditation stats were a complete mess. I opened the backend code and thought: I've literally never seen this logic before.

It had my name on it. I'd shipped it. But I didn't own it.

Bug #2: The Audio Player That Killed Phones

I was using a deprecated method to play audio in Flutter. For smaller rep counts (108, 324 mantras), it worked fine. But when I added a practice that required 1,080 repetitions, users' phones started lagging and becoming completely unresponsive.

The classic developer tragedy: "It works on my system."

And it did! It ran perfectly on simulators and my Android 11 device. Meanwhile, production users were experiencing phone freezes.

The Gut Punch

Fifty people relied on me to support their spiritual practice. And I was sitting there saying "I built this" while having absolutely no idea what the code was doing.

I'd been lazy. I'd delegated my responsibility as an engineer to a chatbot.

And now I had to fix it.

The Debug Nightmare: When AI Becomes a Maze

I did what felt natural: I asked AI to fix it.

Attempt 1: "Your logic to rely on playbackStreamSubscription is wrong. Count the reps manually in a loop."

❌ Didn't work.

Attempt 2: "Actually, no—playbackStreamSubscription was right."

The AI literally contradicted itself.

❌ Still broken.

Attempt 3: "The package itself is causing the error. Install audio_service instead."

❌ Still stuck.

Attempt 4: "Move the logic to pure Dart. Use current timestamp, add number of reps × duration of one chant, adjust by playback speed..."

❌ Useless.

Attempt 5: "Add background permission."

❌ Failed.

Two whole days of this. Passing APKs back and forth with users. Opening new chat windows, getting confident answers that led nowhere. Finding bugs in the code AI had just provided with absolute certainty.

I was prompting desperately, hoping one magical change would fix everything.

It didn't.

The Breakthrough: Pen, Paper, and the Docs

Finally, I did what I should've done from the start.

I grabbed a pen and paper. I mapped out how the component was supposed to work. I read the actual documentation. I debugged the root cause instead of brute-forcing solutions.

And that's when it hit me:

This codebase has my name on it, but I don't own it.

I used to enjoy coding logic. I used to love learning how to write robust, clean code. Now it was just: prompt, ship, repeat.

All speed. But at what cost?

What I Learned: The Muscle You're Losing

Here's the truth no one wants to say out loud:

AI is letting you write code without thinking. But debugging requires thinking.

An engineer doesn't become senior because they shipped features that worked. They become senior because they debugged what didn't work. They researched root causes. And in that research, they gained knowledge that tutorials and prompts could never teach.

AI gave me speed. But it took away my ability to understand my own system.

And when production broke, I was helpless.

My New Workflow: The 3-Layer System

I'm not saying don't use AI. The reality is that every organization will expect you to leverage it. But here's what I do now:

1. Architecture Layer (Me)

I design the logic myself. I write it out. I understand the flow before a single line of code is written.

2. Boilerplate Layer (AI)

AI generates UI scaffolding, repetitive code, and placeholder methods. The boring stuff.

3. Ownership Layer (Me)

I fill in the critical logic manually. I review every AI-generated line. And I don't ship anything I can't explain to someone else without looking at the code.

The One Rule:

If you can't explain the logic without looking at code, you don't understand it enough to ship it.

The Uncomfortable Truth

In five years, there will be two types of engineers:

Those who use AI to move faster on problems they understand
Those who use AI to avoid understanding problems at all

Only one of these survives when production breaks at 3 AM.

AI is a tool. But if you're not careful, it becomes a crutch. And when that crutch is taken away, you realize you never learned to walk.

Where I Am Now

I'm still debugging the audio issue. But this time, I'm doing it right—manually coding it, understanding it, owning it.

The app ships slower now. But when it breaks, I know exactly where to look.

And that's worth everything.

Because building with prompts will get your work done. But you won't grow as an engineer.

The speed is tempting. But speed is worthless if you're sprinting in the wrong direction.

Final thought: Don't just ship features. Own your logic. Understand your system. Because the moment production breaks and AI can't save you, the only thing standing between you and disaster is whether you actually know what your code does.

Choose wisely.

PS: Enjoy a screenshot of my claude convo

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

Utkarsh Mishra — Sun, 15 Mar 2026 10:20:54 +0000

What I Learned Shipping a Production App as a Solo Developer

For the past few months, I've been building Anahad — a spiritual app for saadhnas, 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)

Let me start with what most blog posts conveniently leave out:

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

Now for what really happened.

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 DMing 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

The 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... 🪲

Here's what I learned:

Engineering maturity isn't about building things.

It's about building the right things.

I got my first 100 users through 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.

I got feedback like:

"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 completely shifted my mindset.

The question stopped being:

"What features should I add?"

Instead it became:

"How do I make this so smooth that my user's 60-year-old mother can use it without asking questions?"

That's when I added translations:

English
Hindi
Telugu

And started focusing obsessively on UX.

Result:

Users grew from 20 → 100
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:

"Your app doesn't work on iPad."

No explanation. Just rejection.
"Add Sign in with Apple."

Fine — but Apple only gives the email on first registration, which meant handling weird edge cases.
"Your app doesn't have delete account functionality."

I replied with screenshots showing exactly where it was.

They approved.

Next build?

Same rejection again.

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's when it clicked:

An app with 4 features people actually use

is infinitely better than

10 features nobody touches.

Now my 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 someone I didn't know:

"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 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.

Check out Anahad:

https://anahad.space