There's a moment in every developer's journey where you stop asking "can I build this?" and just... build it. No overthinking, no analysis paralysis. Just a problem in front of you and a keyboard under your hands.
Mine came from the most unexpected place: a maths and physics teacher at the school where I work as an IT trainer.
"Sir, why is there no app where students and teachers can talk separately? WhatsApp is a mess — work stuff, jokes, random forwards, all in one place."
He was right. I'd felt it too. So I said, "Let me think about it." And then I just started building.
What I Built (And What It Became)
The app is called Acadly — yes, I know a similar name exists in the market, but this is a completely different product, and the name isn't final yet. I'm open to suggestions after you read this.
The idea was simple: a focused communication platform for schools. Four sections:
- Chat — personal and group messaging between teachers and students, with file sharing built in
- Files — each user gets their own folder, can upload files, and others can view or download them
- Members — a directory of everyone in the system, organized by role
- Profile — manage your identity, privacy, and settings
As the app grew, so did the features. We added a read-only announcement channel at the top — only Team and Admin could post, everyone else just read. We added Admin controls: lock users who violate rules, delete files or messages, restrict actions entirely for bad actors. A locked user couldn't message anyone, create folders, or even change their profile picture.
For privacy, users could hide their email — it would display as *******@example.com unless they chose otherwise.
We even added a small engagement layer: teachers who actively responded to students earned achievement badges, and students could rate each other for helpfulness — a rating only visible to other students, not to teachers, and not even to the rated student themselves.
It was working well. People were using it. The vibe was good.
The Database Journey (Where It Gets Interesting)
Here's the part I want every mobile developer to read carefully.
I started with Firebase. It's familiar, it has a great free tier (Spark Plan), and the Google sign-in flow is genuinely smooth. On the free plan you get:
- 50,000 document reads/day and 20,000 writes/day on Firestore
- 1 GB storage on Cloud Storage
- 50,000 monthly active users for authentication
Sounds generous — and it is, for small apps. But here's what I didn't implement that cost me later: offline caching.
Modern apps are smart about this. When you open them, they serve you cached data from your local storage first, then quietly fetch only the new stuff in the background. You can even read messages in flight mode if the data is cached. I didn't set this up. So every time a user opened the app, it fetched everything from Firebase fresh. Every. Single. Time.
When the daily read limits hit, messages stopped sending. The app just... stopped.
Now, to be fair — I had only shared the app internally with a small group of users, and I'd warned them not to use it for anything critical yet. So no real damage was done. But the lesson was clear.
For file storage, I moved to Supabase, which made sense because:
- 500 MB database storage on the free plan
- 1 GB file storage
- 50,000 monthly active users
- Max file size of 50 MB per file on the free tier
- Projects pause after 1 week of inactivity (something to watch out for)
Supabase handled files well. But the real question was: what comes next?
Why I'm Moving to Cloudflare (R2 + D1)
After going back and forth between Firebase and Supabase, I made a decision: Cloudflare R2 and D1.
Here's why this combination clicked for me:
You get a SQLite database (D1) that you can deploy and manage entirely through Cloudflare's wrangler CLI. No separate backend hosting. No managing servers. Your entire full-stack web app — frontend on Cloudflare Pages, backend Workers, database on D1, files on R2 — all deployed from the terminal. The deployment headache just disappears.
The free tier is genuinely good:
- Cloudflare Workers: 100,000 requests/day, resets at midnight UTC
- R2 storage: 10 GB free, with no egress fees (yes — no charges for downloading your own files)
- D1 database: generous read/write limits on the free plan
- Cloudflare Pages: static asset requests are unlimited and free
And all of this is free. No credit card required to get started.
I hadn't used R2 or D1 when I was building Acadly. I knew the names, but hadn't touched them. Then I decided I was going to make it work, sat down, figured it out, and now I'm recommending it to anyone building a full-stack app who doesn't want to juggle three different hosting services.
The Lesson Behind All of This
When I look back at the entire Acadly journey, the real lesson isn't about which database to pick. It's about what happens when you decide you're going to build something no matter what.
You end up learning things you wouldn't have learned from a tutorial. Firebase limits teach you about caching. Supabase file limits teach you about storage architecture. Cloudflare teaches you that serverless deployment doesn't have to be painful.
Every constraint pushed me toward a better decision.
If you're building a mobile app — React Native or otherwise — here's what I'd tell you:
Set up offline caching from day one. It's not a nice-to-have. It's the difference between an app that works and an app that hammers your database on every open.
Know your free tier limits before you hit them. Firebase's daily read/write quotas reset at midnight Pacific. Supabase's free projects pause after a week of inactivity. Cloudflare Workers reset at midnight UTC. These aren't gotchas — they're just information you need upfront.
And if you ever feel stuck on a dashboard or config panel — here's my actual trick: Ctrl+A, Ctrl+C, paste it into any AI chatbot, and ask "I want to do X here, how?" It saves hours of YouTube tutorials and gets you moving again fast.
Acadly is still in development. The name might change. The database definitely changed. But the problem it's solving — keeping school communication clean and organized — that hasn't changed at all.
If you've built something similar or have thoughts on the stack, drop it in the comments.
Check it out: Acadly
Part of an ongoing series on building real things and learning the hard way.
