I Didn't Plan to Build an Offline-First Attendance System. Firestore Forced Me To.

How accidentally exhausting Firestore's free-tier limit transformed a rushed MVP into a more resilient anti-proxy attendance system.

Introduction

When I started building an attendance system for my university's UBA (Unnat Bharat Abhiyan) club, I had one clear instruction from our coordinator:

"Build an MVP as soon as possible."

Like most student developers, I focused on getting the features working first.

The application already had everything I needed for the MVP:

Dynamic QR-based attendance Firebase Authentication Firestore database Anti-proxy validation Admin dashboard Meeting management

My daily workflow looked something like this:

Code ↓ Run ↓ Test ↓ Scan QR ↓ Debug ↓ Repeat

Everything seemed to be progressing smoothly.

What I wasn't paying attention to was something happening quietly in the background.

Every refresh.

Every API call.

Every test.

Every debugging session.

All of them were consuming Firestore document reads.

The Problem I Never Expected

One day, while testing the application, things suddenly stopped working.

Attendance requests started failing.

Firestore wasn't responding.

Like most developers, my first thought was:

"I definitely broke something."

I checked my recent commits.

I reviewed the API routes.

I verified Firebase Authentication.

I even looked through my Firestore Security Rules.

Everything looked perfectly fine.

Then I opened the Firebase Console.

That's when I saw it.

Firestore Reads: 50,000 / 50,000

I had exhausted the entire free-tier quota.

Not because thousands of students were using my application.

Not because it had gone viral.

Simply because I had spent days developing and debugging it.

Ironically, I had become my own biggest user.

The Easy Fix Wasn't the Right Fix

Technically, I could have waited for the daily quota to reset.

Problem solved.

But this wasn't just another side project.

It was an attendance system intended to be used during actual UBA meetings.

If Firestore became unavailable during a meeting, attendance couldn't simply stop.

So instead of asking,

"How do I reduce Firestore reads?"

I asked a different question.

"How do I make the system continue working even when Firestore isn't available?"

That single question completely changed the architecture of the project.

Offline-First Was Never the Plan

Before this happened, offline support wasn't even on my roadmap.

Every attendance request depended on Firestore.

Every scan required the backend.

Which meant one dependency controlled whether the entire application worked.

I didn't like that.

So I redesigned the workflow.

Instead of immediately writing attendance to Firestore, the application could now continue functioning locally whenever the backend wasn't available.

Attendance records would be stored securely on the device and synchronised automatically once connectivity or database access returned.

The project unexpectedly became offline-first.

But There Was One Catch...

Building o…