DEV Community: Jonathan Mensah

How I Got to 50,000 Downloads Without Spending on Ads (And What Actually Drove Growth)

Jonathan Mensah — Tue, 10 Mar 2026 10:11:37 +0000

In 2021, I built my first mobile app during a high school vacation. It was terrible, basically a wrapper around a website for exam past questions. But it made okay money from ads, so I forgot about it for years.

Fast forward to September 2024: I rebuilt the entire app with React Native. Today, it has over 50,000 downloads across Ghana, Nigeria, and Sierra Leone. I've never spent a dollar on ads.

Here's exactly how it happened, the channels that worked, the timing that mattered, and the one thing my brother said that changed everything.

The App: Solving a Real Problem

BECE Past Questions helps students in Ghana prepare for the Basic Education Certificate Examination (BECE).

The problem it solves is simple but real:

Students need past exam questions to practice
Physical past question books cost money
Those books are often outdated
Digital alternatives barely existed

I built an app that gives students free access to all BECE past questions, plus quizzes to help them prepare.

Key lesson: I found a niche problem and solved it. This matters more than most people realize.

I've built other apps since then. They all failed. Why? Competition was fierce, and competitors had marketing budgets. If you're a student or solo dev without ad spend, you'll sink in competitive markets.

But BECE exam prep? That was wide open.

The Failed First Version (2021-2024)

My first version was bad. Really bad.

It was a glorified webview, just a wrapper around a website. The UI was clunky. The experience was poor. Downloads were decent, but churn was terrible. People would download it, use it once, and never come back.

I made okay money from AdMob, so I left it alone and moved on to other projects.

For three years, that app just sat there, slowly accumulating bad reviews.

The Rebuild: September 2024

In September 2024, I decided to do a complete overhaul.

I rebuilt the app from scratch in React Native:

Proper offline support
Better UI/UX
Quiz features
Faster performance
Cleaner store listing

I updated the Play Store screenshots, rewrote the description, and relaunched.

Then I waited for users to pour in.

They didn't.

I got a bit discouraged. I'd just spent weeks rebuilding this app, and downloads were... the same.

That's when my brother said something that changed everything:

"Jonathan, no one knows about the app. How do you expect people to download it?"

He was right. I had built it. Now I needed to actually tell people it existed.

The Growth Strategy (That Wasn't Really a Strategy)

My brother started posting the app link in Facebook groups.

What he posted:

Simple message: "This app gives you access to all BECE past questions for free"
Link to the Play Store
Posted in student groups across Ghana

How often: Regularly, but not spammy enough to get flagged by Facebook.

Results: We started seeing downloads. Sometimes 100-200 per day. During exam season? 500+ downloads per day.

That was it. That was the entire "marketing strategy."

No paid ads. No influencer outreach. No TikTok videos. Just my brother dropping links in Facebook groups where students actually were.

What Actually Drove Growth: Four Things

1. Accidental ASO (App Store Optimization)

When I set up the store listing, I didn't know anything about ASO. I just named it "BECE Past Questions" and wrote a description focused on what students were searching for.

Turns out, that was perfect.

Today, I rank top 3 when you search "BECE" in the Play Store.

I didn't intentionally optimize for keywords. I just named the app what students would search for. That accidental SEO has been my biggest growth driver.

Lesson: Sometimes the best ASO is just being obvious. Name your app what people are searching for.

2. Word of Mouth (The Compounding Effect)

Students tell other students. Teachers recommend it. Parents share it.

I know this because:

Users tell me directly: "My friend told me about this app"
Teachers and parents call me to thank me (my number is in the app for support)
Reviews mention: "My teacher recommended this"

Word of mouth didn't happen overnight. It took time. But once it started, it compounded.

The 2025 spike (44,000+ downloads) wasn't because I suddenly started marketing. It was because enough people knew about the app that it spread organically.

3. Seasonal Timing (Exam Cycles)

My app follows a predictable pattern:

Month	Installs
Jan-Apr	Growth begins
May-Jun	Peak season (7,500+ downloads/month)
Jul-Aug	Drop after exams
Sep-Dec	Low activity

Example from 2025:

January: 2,857 downloads
May: 7,520 downloads (peak)
July: 2,019 downloads (post-exam drop)

This seasonal pattern is actually good. It means the product perfectly fits the exam cycle. Students need it when exams are approaching, not year-round.

Lesson: If your product is seasonal, lean into it. Don't fight the cycle, optimize for the peaks.

4. Community Building (The WhatsApp Groups)

After the 5th iteration of the app, I added a WhatsApp group link for students to study together.

I did this on a whim. I didn't expect much.

Today, there are 5 WhatsApp groups with ~5,000 students total (WhatsApp limits groups to 1,000 members).

What happens in these groups:

Students help each other with past questions
They ask questions about specific exams
I jump in occasionally to help
New users join the app because they're in the groups

The moderation problem: Managing 5,000 teenagers is... challenging.

So I built a WhatsApp bot that:

Removes inappropriate content
Steers conversations back to studying
Moderates automatically

These groups create a community around the app. They keep students engaged, help with retention, and generate word-of-mouth growth.

Lesson: Community isn't just for SaaS products. Even a mobile app can benefit from giving users a place to interact.

The Review Recovery Strategy

When I rebuilt the app, I had a problem: tons of bad reviews from the old version.

The old app was terrible, and users left 1-star reviews. Those reviews stuck around even after the rebuild.

How I fixed it:

1. Created a review funnel I showed the Play Store review dialog after users completed something rewarding, like finishing a quiz or completing a set of questions.

Psychology: People are more likely to leave positive reviews when they've just experienced success.

2. Responded to every bad review I replied to complaints, explained what I'd fixed, and asked users to reconsider their rating.

Some updated their reviews. Many didn't. But new positive reviews eventually outnumbered the old bad ones.

Result: Rating climbed from ~2.5 stars to 4.3 stars with hundreds of positive reviews.

Teachers and parents now call me to thank me. One parent told me the app helped their child pass BECE. That's worth more than any 5-star review.

The 2025 Breakout: 9× Growth

2024: ~5,000 downloads 2025: 44,000+ downloads

That's 9× growth in one year.

What changed?

The React Native rebuild (better product)
Improved Play Store listing (better screenshots, description)
Facebook group posts (initial traction)
Word of mouth compounding (organic growth)
WhatsApp community (retention and engagement)

But honestly? The biggest factor was timing + product-market fit.

Students needed this. It solved a real problem. And once enough people knew about it, it spread on its own.

Geographic Expansion (Without Trying)

I built this app for Ghana. That's where BECE exams happen.

But look at my user base now:

Country	Share
🇬🇭 Ghana	~70%
🇳🇬 Nigeria	~25%
🇸🇱 Sierra Leone	~5%

Nigeria is growing fast:

2022: ~2,167 downloads
2025: ~7,980 downloads

Nigeria has 10× Ghana's population and it’s already my second largest market at 25% of users.

Sierra Leone is small but consistent: 600+ downloads per month. For a country that size, that's significant.

Lesson: Build for one specific market, but don't geo-block. You might discover adjacent markets you didn't know existed.

What Didn't Work (And What I Never Tried)

What I didn't try:

Twitter/X posts
TikTok videos
Instagram ads
Influencer outreach
Reddit posts
Paid ads (Google, Facebook)

Why? Honestly, I just didn't think about it. My brother handled the Facebook groups, and that worked, so I never explored other channels.

What failed: I built a game app recently (Z Play - mini games). It's not doing well.

Why? The market is too competitive. Gaming apps have massive competition, and competitors have real marketing budgets. Without ads or a unique angle, you sink.

Lesson: Niche > competitive. A small, underserved market beats a huge, competitive one, especially if you have no budget.

What I'd Do Differently

1. Start the Facebook groups earlier

I wasted three years with a bad app sitting idle. If I'd rebuilt sooner and started promoting it earlier, I'd be at 100K+ downloads by now.

2. Respond to reviews faster

I eventually responded to bad reviews, but it took time. Responding immediately would've helped the rating recover faster.

3. Build the WhatsApp community from day one

The groups are now a core part of user retention. I should've added that feature in version 1.

4. Track metrics from the start

I didn't pay attention to where downloads were coming from until recently. If I'd tracked it earlier, I could've doubled down on what worked.

What's Next

For BECE Past Questions:

Keep improving based on user feedback
Update with new past questions every year
Maintain the WhatsApp community

New project: WASSCE Past Questions

I'm building a separate app for WASSCE (West African Senior School Certificate Examination).

The challenge: Collecting past questions for WASSCE is exponentially harder than BECE. There are more subjects and more years

Right now, I'm deep in the data collection phase. It's the most time-intensive part of apps like this.

I'll write about that experience in a future post, how I scrape, collect, and process exam questions at scale.

The Bottom Line

50,000 downloads. $0 spent on ads.

Here's what actually worked:

Solved a real, niche problem (free access to past questions)
Accidental ASO (named the app what students search for)
Facebook groups (thanks to my brother)
Word of mouth (compounded over time)
Seasonal timing (aligned with exam cycles)
Community building (WhatsApp groups kept users engaged)

What didn't matter:

Fancy marketing strategies
Social media presence
Paid ads
Influencers

Sometimes growth isn't about doing everything. It's about doing the one or two things that actually matter for your specific product and market.

For me, that was:

Building something students actually needed
Showing up where they already were (Facebook groups)
Letting word of mouth do the rest

If you're a student or solo dev without a marketing budget, find a niche problem, solve it well, and show up where your users are. The rest will follow.

Next up: How I'm collecting and processing WASSCE past questions at scale (and why it's 10× harder than BECE).

Written while debugging to: [Dunsin Oyekan – Nagode]

How I Built a Multi-App OTA Update System (And Cut Costs from $199/month to $0)

Jonathan Mensah — Tue, 10 Mar 2026 10:09:39 +0000

Expo's EAS Update service costs $199/month for 50,000 monthly active users. If you have multiple apps or are a solo dev with modest traffic, that's expensive, even the $19/month tier only covers 3,000 monthly active users(MAU).

I found an open-source alternative called Xavia OTA, modified it to support multiple apps in a single instance, and self-hosted it on my $5 VPS with Cloudflare R2 storage (which gives 10GB free).

Total cost: $0 for OTA updates across all my apps.

Here's how I built it, what I changed, and how you can do the same.

What Are OTA Updates (And Why They Matter)

OTA (Over-The-Air) updates let you push JavaScript/React Native changes to users without going through App Store or Play Store review.

What you can update OTA:

Bug fixes
UI changes
Business logic
API endpoint changes

What requires a full app store update:

Native code changes
New permissions
Native dependency updates

This is crucial for mobile development. Play Store reviews can take days. A critical bug fix via OTA? Minutes.

I consider OTA updates a must-have for every app. The ability to fix bugs or push features without waiting for store approval is too valuable to skip.

The Problem: Expo EAS Update Gets Expensive Fast

Expo's EAS Update pricing:

Free tier: 1,000 monthly active users (MAU), then service stops
Starter: $19/month for 3,000 MAU (~$0.005 per additional MAU)
Production: $199/month for 50,000 MAU
Enterprise: $1,999/month for custom scaling

For my app with ~10,000 active users, I'd need either:

Starter plan ($19/month) + overage fees (~$35/month extra) = ~$54/month
Or jump straight to Production ($199/month)

If you have multiple apps, multiply those costs. For a student or indie dev, that's not sustainable.

I needed a cheaper solution, ideally self-hosted.

Enter Xavia OTA (With Limitations)

I found Xavia OTA, an open-source alternative to Expo's OTA service. It had one major limitation: one app per Docker container.

If you had multiple apps, you needed:

Multiple Docker containers
Multiple databases
Multiple domains/ports

This was expensive (more VPS resources) and annoying to manage.

So I modified it.

What I Changed: Multi-App Support

I forked Xavia OTA and rewrote it to support multiple apps in a single instance.

Key Changes

1. Database Schema

Added an apps table:

CREATE TABLE apps (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  upload_key TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

Modified releases to include app_id:

ALTER TABLE releases ADD COLUMN app_id UUID REFERENCES apps(id);

2. Per-App Upload Keys

Original: Single UPLOAD_KEY environment variable for the entire instance.

My version: Each app has its own upload_key stored in the database.

When you upload an update:

curl -X POST $OTA_URL/api/upload \
  -F "file=@update.zip" \
  -F "uploadKey=your-app-specific-key" \
  -F "appSlug=your-app-slug"

The server looks up the app by uploadKey and validates it before accepting the update.

3. App-Scoped File Storage

Original structure (single app):

updates/
  {runtimeVersion}/
    {timestamp}.zip

My structure (multi-app):

apps/
  {appId}/
    updates/
      {runtimeVersion}/
        {timestamp}.zip

Each app's updates are isolated in its own directory.

4. Smart App Resolution in Manifest Endpoint

The manifest endpoint (/api/manifest) needs to know which app is requesting an update. I implemented a 3-tier resolution strategy:

Priority 1: Explicit header

const appSlug = req.headers['expo-app-slug'];

Priority 2: Infer from update ID The app sends its current expo-current-update-id. I map that to an app slug:

const updateId = req.headers['expo-current-update-id'];
const mapping = await database.getAppSlugByUpdateId(updateId);

Priority 3: Default app If neither works, fall back to a default-app:

app = await database.getAppBySlug('default-app');

This way, updates work seamlessly even without explicit configuration.

5. Per-App Code Signing

Original: Single PRIVATE_KEY_BASE_64 for code signing.

My version: Per-app signing keys:

SIGNING_BECEAPP_PRIVATE_KEY_BASE64=...
SIGNING_WASSCE_PRIVATE_KEY_BASE64=...

Each app can have its own signing certificate for security.

6. Admin UI for Managing Apps

I built a simple UI to:

Create new apps (name, slug, upload key)
View all apps
See releases per app
Copy upload keys

This makes onboarding new apps trivial, no environment variable changes needed.

My Setup: Self-Hosted on $5 VPS + Cloudflare R2

Infrastructure:

Xavia OTA running on my $5 VPS (same one as my backend)
Cloudflare R2 for storage (10GB free tier)
R2 is S3-compatible, so configuration was straightforward

Why R2?

Free 10GB storage (enough for dozens of app versions)
S3-compatible API (works with existing S3 code)
No egress fees (unlike AWS S3)

Total cost: $0 (R2 free tier + already paying for the VPS anyway).

Architecture Overview

How it works:

Developer runs build script with app-specific upload key
Script bundles JavaScript/assets and uploads to Xavia OTA
Xavia validates upload key, identifies app, stores metadata in PostgreSQL
Update bundle is uploaded to Cloudflare R2
User devices periodically check for updates via manifest endpoint
Xavia queries database to find latest update for that app/runtime version
If update exists, Xavia serves it from R2
Users download and apply update on next app restart

The Deployment Flow

Here's how I push updates from code to users' phones:

1. Build Script

I have a script: ./build-and-publish-app-release.sh

./build-and-publish-app-release.sh <runtimeVersion> <xavia-ota-url> <uploadKey>

What it does:

Extracts the app slug from app.config.js
Gets current git commit hash and message
Runs npx expo export to bundle the JavaScript
Normalizes file paths in metadata (for cross-platform compatibility)
Generates expoconfig.json
Zips everything
Uploads to Xavia OTA with the upload key

Example:

./build-and-publish-app-release.sh 1.0.5 https://ota.myapp.com abc123uploadkey

The script itself:

#!/bin/bash

if [ "$#" -ne 3 ]; then
  echo "Usage: $0 <runtimeVersion> <xavia-ota-url> <upload-key>"
  exit 1
fi

commitHash=$(git rev-parse HEAD)
commitMessage=$(git log -1 --pretty=%B)
appSlug=$(node scripts/get-slug.js)

runtimeVersion=$1
serverHost=$2
uploadKey=$3

timestamp=$(date -u +%Y%m%d%H%M%S) 
outputFolder="./ota-builds/$timestamp"

echo "Output Folder: $outputFolder"
echo "Runtime Version: $runtimeVersion"
echo "App Slug: $appSlug"
echo "Commit Hash: $commitHash"
echo "Commit Message: $commitMessage"

read -p "Do you want to proceed? (y/n): " confirm

if [ "$confirm" != "y" ]; then
  echo "Operation cancelled."
  exit 1
fi

rm -rf $outputFolder
mkdir -p $outputFolder

npx expo export --output-dir $outputFolder

# Normalize paths in metadata.json
metadataFile="$outputFolder/metadata.json"
if [ -f "$metadataFile" ]; then
  node - "$metadataFile" <<'NODE'
const fs = require('fs');
const metadataPath = process.argv[2];
const data = JSON.parse(fs.readFileSync(metadataPath, 'utf8'));
const normalize = (value) =>
  typeof value === 'string' ? value.replace(/\\/g, '/') : value;

if (data.fileMetadata) {
  for (const platform of Object.values(data.fileMetadata)) {
    if (platform.bundle) platform.bundle = normalize(platform.bundle);
    if (Array.isArray(platform.assets)) {
      platform.assets = platform.assets.map((asset) => ({
        ...asset,
        path: normalize(asset.path),
      }));
    }
  }
}
fs.writeFileSync(metadataPath, JSON.stringify(data));
NODE
fi

npx expo config --json > $outputFolder/expoconfig.json

cd $outputFolder  
zip -q -r ${timestamp}.zip .

curl -X POST $serverHost/api/upload \
  -F "file=@${timestamp}.zip" \
  -F "runtimeVersion=$runtimeVersion" \
  -F "appSlug=$appSlug" \
  -F "commitHash=$commitHash" \
  -F "commitMessage=$commitMessage" \
  -F "uploadKey=$uploadKey"

echo ""
echo "Uploaded to $serverHost/api/upload"
cd ..
rm -rf $outputFolder
echo "Done"

2. React Native App Configuration

In my app.config.js:

module.exports = {
  expo: {
    name: "BECE Past Questions",
    slug: "beceapp",
    runtimeVersion: {
      policy: "appVersion"
    },
    updates: {
      url: "https://xavia-ota.myserver.com/api/manifest",
      codeSigningCertificate: "./certs/certificate.pem",
      codeSigningMetadata: {
        keyid: "main",
        alg: "rsa-v1_5-sha256"
      }
    }
  }
}

The updates.url points to my self-hosted Xavia OTA server instead of Expo's.

3. Update Delivery

When a user opens the app:

App checks https://ota.myserver.com/api/manifest
Xavia OTA identifies the app (via slug or update ID)
Checks if there's a newer update for the runtime version
If yes, downloads and applies it
User gets the update on next app restart

Typical flow:

Push code → Run build script → Update live in ~5 minutes
No App Store. No Play Store. Just works.

What Problems This Solved

Before (multiple Docker containers):

Running 3 apps = 3 containers = more RAM/CPU usage on VPS
Managing 3 separate databases
3 different upload keys in environment variables
3 different domains/ports to manage

After (single multi-app instance):

One container handles all apps
One database with app isolation
Upload keys stored per app in DB (no env var changes)
One domain with app-aware routing

Cost savings:

Expo EAS Update (Production plan): $199/month
Or Starter + overages: ~$54/month
My setup: $0/month (using free R2 tier + existing VPS)

Annual savings: $648-$2,388/year

Onboarding a New App

Adding a new app is dead simple:

Create app in UI:

*   Name: "My New App"

*   Slug: "mynewapp"

*   Upload key: "some-secret-key-123"

Configure app:

   updates: {
     url: "https://ota.myserver.com/api/manifest"
   }

Deploy updates:

   ./build-and-publish-app-release.sh 1.0.0 https://ota.myserver.com some-secret-key-123

Done. No Docker containers to spin up. No infrastructure changes.

What Breaks (And How I Handle It)

Broken OTA Update

I pushed an update once that crashed on certain Android devices.

The fix:

Noticed crashes in Sentry within minutes
Logged into Xavia OTA dashboard
Rolled back to previous version (one click)
Users automatically got the stable version

Total downtime: ~15 minutes.

If this had been an App Store update, users would be stuck with a broken app for days.

Upload Failures

Sometimes the build script fails to upload (network issues, wrong upload key).

The fix:

Check upload response in terminal
If upload key is wrong: "Invalid upload key" error immediately
If network fails: retry the script (idempotent)

What I'd Do Differently

1. Automate backups

Right now, I manually backup the Xavia OTA database. Should automate this.

2. Implement staged rollouts

Currently, updates go to 100% of users immediately. I should add:

10% rollout first
Monitor for crashes for 24 hours
If stable, roll out to 100%

This would've caught that Android bug before it hit everyone.

3. Add deployment notifications

Set up webhooks to notify me (Slack/Discord) when:

New update is uploaded
Rollback happens
Upload fails

Open Sourcing My Fork

I'm currently cleaning up my multi-app fork of Xavia OTA to open source it. Once it's ready, other devs can:

Self-host OTA updates for free
Manage multiple apps in one instance
Save $54-$199/month (depending on app count)

The original Xavia OTA is great, but the multi-app limitation makes it expensive for indie devs managing multiple projects.

The Bottom Line

You don't need to pay $19-$199/month for OTA updates.

What you need:

A VPS (mine is $5/month, shared with other services)
Cloudflare R2 free tier (10GB storage)
Xavia OTA with multi-app support (my fork, coming soon)

What you get:

Unlimited apps
OTA updates in minutes
One-click rollbacks
Full control

The tradeoff? You maintain it yourself. But if you're already self-hosting your backend (like I am), adding OTA updates is trivial.

Next up: How I Got to 50,000 Downloads Without Spending on Ads (And What Actually Drove Growth)

Written while debugging to: [Yebba– Yellow Eyes]

How I Handle Deployments and CI/CD for a $5/Month Production App

Jonathan Mensah — Tue, 10 Mar 2026 10:06:32 +0000

Running a production app with ~10,000 active users on a $5/month VPS sounds impossible. But it's not, if you're smart about your tooling.

Here's my entire deployment setup: from code commit to production, backend to mobile OTA updates, and how I handle rollbacks when things break.

Spoiler: I didn't compromise on automation. I just stopped paying for things I could self-host.

The Stack

Infrastructure:

$5/month VPS (2 vCPU, 4GB RAM + swap memory)
GitHub (free tier)
Dokploy (self-hosted, free)
Xavia OTA (self-hosted, open source)
MongoDB Atlas (free tier)
Cloudflare R2 (free tier)

Total monthly cost: $5. That's it.

Backend Deployment: Dokploy Does Everything

I used to manually SSH into my VPS, pull code, restart services, and pray nothing broke. Now I use Dokploy—a self-hosted alternative to platforms like Railway or Render.

What Dokploy does:

Listens for commits on my GitHub repo
Automatically builds the NestJS backend
Deploys with zero-downtime (spins up new instance, switches traffic, kills old instance)
Shows deployment status in a dashboard

The setup:

Install Dokploy on my VPS
Connect it to my GitHub repo
Configure build settings (Node.js, environment variables, ports)
Done

Every time I push to main, Dokploy:

Pulls the latest code
Installs dependencies
Builds the app
Deploys it
Notifies me if it fails

No GitHub Actions minutes consumed. No paying for CI/CD platforms. Just a self-hosted tool doing exactly what I need.

How I know if deployment failed:

The Dokploy dashboard shows:

Build logs in real-time
Deployment status (success/failed)
Current running version
Resource usage

If something breaks, I see it immediately.

Mobile Deployment: Self-Hosted OTA Updates

This is where it gets interesting.

I used to pay for Expo's OTA update service. Then I found Xavia OTA, an open-source alternative I could self-host.

What Are OTA (Over-The-Air) Updates?

For those unfamiliar: OTA updates let you push JavaScript/React Native changes to users without going through the App Store or Play Store review process.

What can be updated OTA:

Bug fixes
UI changes
Business logic
API endpoint changes

What cannot be updated OTA:

Native code changes (requires a full app store update)
New permissions
Version bumps that change native dependencies

This is crucial for mobile apps. Play Store reviews can take days. OTA updates deploy in minutes.

How I Set Up Xavia OTA

Xavia OTA had one limitation: it only supported one app per instance. If you had multiple apps, you needed multiple Docker containers.

I tinkered with the code and made it support multiple apps in a single instance. Now I can host updates for multiple projects without spinning up separate containers.

The deployment process:

I have a script: ./build-and-publish-app-release.sh

./build-and-publish-app-release.sh <runtimeVersion> <xavia-ota-url> <uploadKey>

What this does:

Builds the React Native bundle
Creates an update manifest
Uploads it to my self-hosted Xavia OTA server
Users get the update next time they open the app

Example:

./build-and-publish-app-release.sh 1.2.3 https://ota.myapp.com abc123key

Within minutes, all users on runtime version 1.2.3 get the update. No app store. No waiting.

Version Compatibility Strategy

Here's the key: all my backend APIs are backward compatible.

This means:

New app versions can talk to old backend APIs
Old app versions can talk to new backend APIs
I never force users to update immediately

This prevents the nightmare scenario where a backend update breaks older app versions.

Database Updates: Automated Past Questions Sync

My app serves exam past questions. These get updated regularly.

I have an automated script that:

Listens for new past questions (scraped or manually added)
Automatically updates MongoDB with new content
Runs on a cron job

Users get fresh content without me manually updating the database every time.

What Breaks (And How I Handle It)

The OTA Update That Crashed Everything

I pushed an OTA update once. Within minutes, users started reporting crashes.

The problem: I had introduced a bug that only appeared on certain Android devices (classic React Native moment).

The fix:

Because I control the OTA server, I just rolled back the update:

Removed the broken update from Xavia OTA
Re-published the previous stable version
Users automatically got the working version

Total downtime: ~15 minutes.

If this had been an app store update, I would've been screwed. Users would be stuck with a broken app for days while the fix went through review.

Backend Deployment Failures

Dokploy's dashboard shows me immediately if a deployment fails:

Build errors (syntax error, missing dependencies)
Runtime errors (crashes on startup)

When this happens:

Check the logs in Dokploy
Fix the issue locally
Push the fix
Dokploy auto-deploys the corrected version

If the new deployment is completely broken, I can roll back to the previous version with one click in the Dokploy dashboard.

Monitoring and Health Checks

Backend monitoring:

Dokploy shows resource usage (CPU, RAM, network)
I have Sentry for error tracking (from my previous post)
Simple HTTP health check endpoint (/health)

Mobile monitoring:

Sentry for crash reporting
Analytics for user sessions
OTA update adoption rate (I can see how many users are on each version)

If something's wrong, I know within minutes, not hours or days.

The $5/Month Reality Check

People ask: "How can you run production on a $5 VPS?"

Here's the secret: A 2 vCPU, 4GB RAM VPS is plenty for most apps.

What I run on this VPS:

NestJS backend
Dokploy (for deployments)
Xavia OTA (for mobile updates)
Nginx (reverse proxy)
Automated scripts (cron jobs for content updates)

The trick: I added swap memory to handle occasional spikes. The VPS rarely uses more than 60% of its resources under normal load.

I might upgrade when I deploy more applications, but for now, it's more than enough.

What I Didn't Have to Compromise On

This is important: I didn't compromise on automation because of the budget.

I still have:

Automated deployments (Dokploy)
OTA updates (Xavia OTA)
Zero-downtime deploys (Dokploy handles this)
Rollback capability (one click)
Real-time deployment logs
Error tracking (Sentry)

The only difference? I self-host the tools instead of paying for SaaS platforms.

What I saved by self-hosting:

GitHub Actions: $0 (would be ~$10-20/month for private repos with heavy CI usage)
Expo OTA: $0 (would be $29/month)
Railway/Render: $0 (would be $20-50/month)
Total savings: ~$60-100/month

What I'd Do Differently

1. Set up automated backups earlier

I should've automated MongoDB backups from day one. I do manual exports weekly now, but this should be automated.

2. Add deployment notifications

Dokploy doesn't notify me on success/failure. I should set up a webhook to Slack or Discord so I know immediately when deployments happen.

3. Implement staged rollouts for OTA updates

Right now, OTA updates go to all users at once. I should implement:

10% of users get the update first
If no crashes/errors after 24 hours, roll out to 100%

This would've caught that Android crash before it hit everyone.

The Bottom Line

You don't need expensive DevOps tools to run a production app. You need:

A decent VPS ($5/month is enough)
Self-hosted CI/CD (Dokploy)
Self-hosted OTA updates (Xavia OTA)
Backward-compatible APIs
A rollback strategy

I went from paying ~$100/month (Expo OTA + managed hosting + CI/CD) to $5/month, without losing any automation or deployment speed.

The tradeoff? You have to set up and maintain the tools yourself. But if you're a solo dev or a student, that's a tradeoff worth making.

Next up: How I built a multi-app OTA update system for $0/month (and saved $199/month by ditching Expo's service).

Written while debugging to: [Dunsin Oyekan– Nagode]

How I Migrated 50,000 Users from Firebase to a Custom Backend (And What Broke Anyway)

Jonathan Mensah — Tue, 10 Mar 2026 10:04:03 +0000

After my Firebase bill hit $300/month, I knew I had to migrate. But I had a problem: 50,000 downloads, ~10,000 active users, and zero tolerance for downtime or forcing password resets.

Here's how I migrated from Firebase to a custom NestJS + MongoDB stack without breaking everything, and the auth bug that almost ruined it all.

The Challenge

I couldn't just flip a switch. I needed:

Zero downtime during migration
No forced password resets (users hate this, I know I do)
Data consistency between old and new systems
A way to roll back if things went wrong

The solution? Run both systems in parallel and migrate gradually.

Phase 1: Building the New Backend (2 Days Planning)

Before touching production, I had to build the entire new stack:

The new setup:

NestJS backend (full API control)
MongoDB Atlas (free tier)
$5/month VPS

The first problem: Firestore vs MongoDB data models

Firestore loves subcollections. MongoDB doesn't work that way.

In Firestore, I had:

users/{userId}/progress/{examId}/questions/{questionId}

I had to flatten this for MongoDB:

{
  userId: "abc123",
  examId: "exam456",
  questionProgress: [
    { questionId: "q1", completed: true },
    { questionId: "q2", completed: false }
  ]
}

Deeply nested subcollections had to become embedded documents or separate collections with references. This took careful planning to avoid slow queries later.

Phase 2: The Dual-Write Strategy

Instead of a "big bang" migration, I used a safer approach: write to both systems simultaneously.

Here's how the dual-write flow worked:

The implementation:

Installed Firebase Admin SDK in my NestJS backend - This let my new backend talk to Firebase
Updated my React Native app to call the new NestJS API instead of Firebase SDKs directly
Set up dual-write proxying:
- User makes a request to NestJS
- NestJS writes to MongoDB Atlas (new system)
- NestJS immediately mirrors that write to Firestore (old system)
- Both systems stay in sync
For reads: I kept reading from Firestore (source of truth) while verifying MongoDB was populating correctly

The deployment problem:

I needed to push an app update with the new API endpoints, but Play Store review was taking forever. Solution? OTA (Over-The-Air) update. I self-host this, so I pushed the update directly to users without waiting for Google.

Phase 3: The Authentication Migration (The Tricky Part)

This was the hardest part. I had thousands of users with Firebase Auth accounts, and I couldn't force them all to reset passwords.

The lazy migration approach:

Instead of migrating all users at once, I migrated them as they logged in:

Here's the process:

User tries to log in
NestJS checks: "Do they exist in MongoDB?"
If NO:
- Use Firebase Admin SDK to verify their credentials against Firebase
- If successful, capture their plaintext password during that single login
- Hash it with bcrypt and save to MongoDB
- User is now migrated
If YES: User already migrated, authenticate normally with MongoDB

For inactive users:

I used Firebase's bulk export:

firebase auth:export users.json --project my-project

Then imported their password hashes using Firebase's custom scrypt parameters:

Signer key
Salt separator
Rounds
Memory cost

This let me pre-migrate users who hadn't logged in yet without forcing resets.

What Broke: The Base64 Signer Key Bug

Everything was ready. I deployed. And then every legacy login failed.

Users who hadn't migrated yet couldn't log in. My error logs were filled with authentication failures.

The problem: Firebase's scrypt signerKey parameter needs to be Base64 decoded before passing it to the hash verification function.

I was treating it as a raw string. My backend wasn't decoding it correctly, so Firebase's scrypt hashes never matched.

The fix:

// Wrong - treating as raw string
const signerKey = process.env.FIREBASE_SIGNER_KEY;

// Right - Base64 decode to buffer
const signerKey = Buffer.from(
  process.env.FIREBASE_SIGNER_KEY,
  'base64'
);

One line. That's all it took to break authentication for thousands of users.

Luckily, my app is still usable without logging in (users can browse questions), so the damage was limited. But it was a stressful few hours.

What I Kept on Firebase

I didn't migrate everything. Some Firebase services are still cheap/free and not worth rebuilding:

Still using Firebase for:

Analytics (still free)
Cloud Messaging/Push notifications (still free)
Storage for profile pictures (I'm nowhere near the limit, and images are compressed before upload)

No point migrating these when they're working and costing nothing.

The Deep Nesting Problem

Another issue: Firestore lets you nest subcollections infinitely. MongoDB doesn't work that way.

I tried flattening deeply nested Firestore structures into single MongoDB documents. Bad idea. Queries became slow because documents got massive.

The fix: Split deeply nested data into separate collections with references, just like a traditional relational database.

Timeline

Planning: 2 days
Execution: 1 day
Stabilization: A few weeks (fixing the auth bug, optimizing queries, monitoring for issues)

What I'd Do Differently

1. Test the scrypt parameters earlier

I should've written integration tests specifically for Firebase scrypt verification before deploying. That Base64 bug would've been caught immediately.

2. Start with a small cohort

Instead of dual-writing for all users at once, I should've tested with 5-10% of traffic first to catch issues before they affected everyone.

3. Document the data model mapping

I spent way too much time figuring out how to flatten Firestore's subcollections. A clear document mapping old structure → new structure would've saved hours.

4. Set up better monitoring

I only realized auth was broken when users complained. I should've had alerts for auth failure rate spikes.

The Bottom Line

Migrating from Firebase to a custom backend without downtime is possible, but it's not trivial.

What worked:

Dual-write strategy (safe, reversible)
Lazy password migration (no forced resets)
Keeping Firebase services that are still cheap

What almost broke everything:

Not properly Base64 decoding Firebase scrypt parameters
Trying to directly map deeply nested Firestore structures to MongoDB

Was it worth it?

Absolutely. I went from $15-20/month (after optimization) to $5/month total. More importantly, I'm not constantly worried about a spike in usage causing a surprise bill.

If you're considering migrating away from Firebase, take your time, test thoroughly, and run both systems in parallel until you're confident the new one works.

Next up: How I handle deployments and CI/CD for a $5/month production app.

Written while debugging to: [Așa – Eye Adaba]

How My Firebase Bill Hit $300 in One Month (And Why I Don't Use Firebase Anymore)

Jonathan Mensah — Tue, 10 Mar 2026 09:53:59 +0000

I randomly checked my Firebase dashboard one day and my heart sank.

$300. In one month. For an app I thought was "basically free to run."

Turns out "free tier" doesn't mean much when you're making inefficient queries to thousands of active users.

Here's what went wrong, and why I eventually migrated away from Firebase entirely.

The Three Mistakes That Cost Me $300

Mistake #1: No Caching (The Biggest One)

I was fetching the same data over and over again. Every time a user opened the app, I'd query Firestore for data that hadn't changed in months.

My app shows past exam questions. These questions don't change. They're literally historical data. But every single user, every single session, was hitting Firestore to fetch them.

The math:

~10,000 active users
Average 3-5 app opens per day per active user
Each open = full query to fetch questions
Firestore charges per document read

That's 30,000-50,000 unnecessary Firestore reads per day. Every single day.

What I should have done: Aggressively cache anything that doesn't change. Past exam questions? Cache them locally. Don't hit the database unless absolutely necessary.

Mistake #2: No Pagination

I was loading entire question sets at once. Instead of showing 10 questions and loading more as needed, I'd fetch 50-100 questions upfront.

Mistake #3: No Billing Alerts

The worst part? I had no idea this was happening until I randomly checked my dashboard.

Firebase lets you set up billing alerts. I didn't. So I went weeks burning money without knowing.

What I should have done: Set up billing alerts immediately. Get notified when you hit $10, $25, $50. Don't wait until you're at $300 to find out.

What I Did to Fix It

Fix #1: Aggressive Caching

I implemented local caching for anything that doesn't change. Past questions get cached on the device after the first fetch. Users only hit Firestore when:

They're accessing new content
Cache is outdated (which for past questions, never happens)

This alone cut my Firestore reads by ~80%.

Fix #2: Pagination

I rewrote my queries to load data in batches:

// Before: Load everything
const questions = await firestore()
  .collection('questions')
  .get();

// After: Load 20 at a time
const questions = await firestore()
  .collection('questions')
  .limit(20)
  .get();

Users don't need to see 100 questions at once. They need 10-20, then more as they scroll.

Fix #3: Billing Alerts

I set up alerts in the Firebase console:

$10 threshold: "Okay, things are running normally"
$25 threshold: "Check what's spiking"
$50 threshold: "Something is wrong, investigate now"

This way I'd never wake up to a surprise $300 bill again.

The Bill Dropped... But I Still Migrated Away

After implementing these fixes, my Firebase bill dropped to ~$15-20/month. Much better.

But here's the thing: Firebase gets expensive at scale, even when you're being careful.

Even with ~10,000 active users , I was constantly worried about costs. One inefficient query, one spike in usage, and my bill could explode again. I didn't want to spend my time optimizing for Firebase's pricing model, I wanted to build features.

So I migrated.

My New Stack (And Why It's Cheaper)

I moved to:

NestJS backend (full control over my API)
MongoDB Atlas (free tierno per-read pricing)
Cloudflare R2 (storage with generous free tier)
$5/month VPS (to run the NestJS backend)

Total cost now: $5/month. That's it. Not $15-20. Not $300. Just the VPS.

MongoDB Atlas free tier handles my database. Cloudflare R2 free tier handles my storage. The only thing I actually pay for is the server to run my backend.

What I Learned About Firebase

Firebase is great for:

Prototypes and MVPs
Apps with small, predictable traffic
Teams that don't want to manage infrastructure

Firebase is NOT great for:

Apps with high read volume
Apps where data doesn't change often (you're paying to re-fetch the same thing)
Apps at scale where costs matter

If you're serving mostly static or slowly-changing data to thousands of users, you'll get killed by per-read pricing.

What I'd Do Differently

If I were starting this app from scratch today:

Set up billing alerts before writing a single line of code - Know when costs spike
Cache aggressively from day one - If data doesn't change, don't fetch it again
Implement pagination immediately - Never load more than you need
Question whether Firebase is the right choice - For high-read, low-write apps, traditional backends are often cheaper

Or honestly? Start with a $5 VPS and a traditional stack. You'll have more control and predictable costs.

The Bottom Line

Firebase's "pay as you go" pricing sounds great until you realize you're paying for every single read, even when you're fetching the same data for the hundredth time.

I went from $0 to $300 in one month because I didn't understand how Firebase pricing works. I fixed it and got down to $15-20/month. Then I migrated entirely and now pay $5/month total.

The lesson: Know your pricing model before you scale. Firebase is convenient, but convenience has a cost.

Next up: How I migrated 50,000 users from Firebase to a custom backend without downtime (and what broke anyway).

Written while debugging to: [J. Cole – Poor Thang]

Why My App Crashed 47 Times in One Week (And the Monitoring Tool That Would've Saved Me)

Jonathan Mensah — Tue, 10 Mar 2026 09:51:55 +0000

47 crashes in one week. That's what happens when you ship an app to 50,000 users without proper error monitoring.

My app's rating started tanking. Users were leaving one-star reviews. And I had no idea what was actually causing it.

The Play Console crash reports told me something was wrong, SIGABRT errors related to AdMob, but they didn't tell me why or where in my code it was happening. The ad unit ID wasn't making it to the app somehow, but I couldn't pinpoint the exact failure point.

So I did what any panicking developer would do: I started guessing.

What I Tried (That Didn't Work)

I pushed update after update, each one adding more try-catch blocks and "precautionary" error handling around the ad loading logic.

Update 1: Wrapped ad initialization in try-catch. Still crashing.

Update 2: Added null checks everywhere. Still crashing.

Update 3: Added more defensive code around the ad unit ID. Still crashing.

Each update took time to build, publish, and roll out. Each time, I'd wait anxiously to see if the crash rate went down. And each time, the crashes kept coming.

Meanwhile, my rating dropped from 4.5 stars to 3.8. Users were getting frustrated, and so was I.

The Problem With Play Console Crash Reports

Don't get me wrong, Google Play Console crash reports are useful. They told me:

That crashes were happening (obviously)
The error type (SIGABRT)
That it was related to AdMob
A stack trace that was... mostly useless

What they didn't tell me:

The exact line of code causing the crash
The user flow that triggered it
What data state led to the failure
Real-time alerts when crashes spiked

I was debugging blind, deploying hopeful fixes and waiting days to see if they worked.

What Actually Fixed It: Sentry

After a week of this mess, I did what I should've done from day one: I integrated Sentry.

One update later, I had my answer within minutes.

Sentry showed me:

The exact line where the ad unit ID was undefined
The user flow that triggered it (app opening from a cold start in specific scenarios)
The device info and OS versions where it happened most
Real-time alerts every time the crash occurred

Turns out the ad unit ID was being accessed before my config was fully initialized. A simple timing issue I would've never caught without detailed crash context.

I added a proper initialization check, pushed the fix, and the crashes stopped immediately.

What I Learned

Lesson 1: Play Console crash reports are not enough

They're a starting point, but they don't give you the context you need to debug effectively. You're essentially flying blind.

Lesson 2: Adding random try-catch blocks doesn't fix crashes

It just hides symptoms. I wasted a week pushing defensive code that didn't address the root cause because I didn't have visibility into what was actually happening.

Lesson 3: Real-time error monitoring should be set up BEFORE you ship

Waiting until your app is crashing in production to add monitoring is like waiting until your house is on fire to install smoke detectors. Sentry takes 15 minutes to integrate, there's no excuse not to have it from day one.

Why Sentry Specifically?

I'm not sponsored by Sentry (I wish). I'm recommending it because:

Dead simple to set up in React Native (literally 3 steps in their docs)
Free tier that's generous enough for student projects
Instantly points to the exact error with full context
Real-time alerts so you know when things break
Source maps support so you see readable code, not minified garbage

Other tools exist (Firebase Crashlytics, Bugsnag, LogRocket), but Sentry hit the sweet spot of easy setup, useful insights, and actually free for small projects.

What I'd Do Differently

If I were starting this app from scratch today:

Integrate Sentry before the first user - Not after 50,000 downloads and a crisis
Set up alerts - Get notified immediately when crash rates spike
Test error reporting - Trigger a test crash to make sure monitoring is working
Never ship blind - If I can't see what's breaking in production, I'm not ready to ship

The Bottom Line

You will ship bugs. That's not the problem.

The problem is shipping bugs and having no idea they exist until your rating tanks and users are gone.

47 crashes. One week. One monitoring tool that would've caught it in 5 minutes instead of 7 days.

Don't make my mistake. Set up error monitoring before your first real user. Your future self (and your app rating) will thank you.

Next up: How my Firebase bill hit $300 in one month, and the three pricing mistakes that caused it.

Currently debugging to: [Octavian – Lightning]

Building in Public as a CS Student (After a Year in Production)

Jonathan Mensah — Tue, 10 Mar 2026 09:48:29 +0000

My app crashed 47 times in one week. That same month, my Firebase bill hit $300 because I didn't understand read/write pricing.

By that point, the app had been live for nearly a year and reached 50,000 downloads, which meant every mistake was expensive and public.

Nothing in my coursework prepared me for production. Shipping to real users forced me to learn cost management, backend scaling, monitoring, and what "it works on my machine" actually means, all through mistakes I couldn't ignore.

Turns out the best teacher is production breaking at 2am. School never covered that.

I'm a CS student who ships software to real users and writes about every lesson it teaches me.

Here's what I write about:

Why your app crashes at scale, and what testing actually misses
Firebase and backend mistakes that cost real money
Decisions that matter after your app gets its first 1,000 users
What breaks in production that never shows up in tutorials

Next post: Why my app crashed 47 times in one week, and the one monitoring tool that would've caught it before users did.

Currently debugging to: [Așa – Bibanke]