Firebase backend platforms — services — Ahsan Mahmood
Firestore data models, security rules and the read budget that keeps them on the free tier.
A backend on the free tier that stays on the free tier — because the read budget is a design constraint from the first query, not an optimisation afterwards.
An exam platform I built went down for a whole day, and it was not a bug.
ImtehanHub has its own page on this site. It ran out of Firestore's free-tier read quota, and once a day's reads are gone the product is down for everybody until the counter resets.
Nobody was watching the number that decided that.
On Firestore the price of a screen is set by the query behind it rather than by the design in front of it. Every document read is billed.
A list view that pulls a collection into the browser and filters it there looks identical to one that asks the database a question, right up until the collection has grown.
Then the two diverge. One of them is a page. The other is an invoice, or a stopped product, depending on the tier you are on.
The failure is not a slow page. It is a hard stop.
So the read budget is a design constraint from the first query, not an optimisation afterwards.
That sentence decides the data model before it decides any code. A collection is shaped by the questions it has to answer, which sometimes means the same fact is stored twice so that neither copy ever has to be searched for.
Counts come from an aggregation rather than from fetching rows and measuring them. Every list read is paginated with an explicit limit, and a query without one is a bug even on a small collection.
The rules belong to the same design. A rule that checks an owner field can only be satisfied by a query that carries the matching filter, so the rule and the query are written together or neither of them works.
The constraint decides what runs where. Nothing sits on a server that has to be kept alive, and nothing depends on a vendor whose pricing can move under you. That began as a budget decision and became a design one.
What an engagement of this shape covers is settled before the first call ends.
A data model shaped by the queries it must answer. Security rules, and the probe that proves them as a non-admin. Composite indexes for every list read, because an index a query needs is otherwise discovered in production by the first person unlucky enough to run it.
Every list paginated, counts by aggregation. Authentication and account deletion end to end.
An index is not an optimisation here. It is a precondition, because a query missing the composite index it needs does not run slowly; it refuses, in front of a user, on the day the list first gets a second filter.
The probe is the part people are most surprised by. Rules are verified while signed in as an ordinary user with somebody else's data in the database, because an admin account short-circuits exactly the check you are trying to make.
Account deletion earns its own sentence. It is the flow most products describe and few finish, since deleting a user is easy and deleting everything that references them is a query plan.
Firestore is the usual home for this work, and Supabase with row-level security is the same job on different machinery. Which one a project gets is argued from the queries rather than from a preference. I am Ahsan Mahmood, and that argument gets written down where you can read it and disagree with it.
The outage above is not a cost of working this way. It is the reason the method exists, and it is why the read budget is the first conversation rather than the last.
The costs that stay are quieter. A model shaped by today's queries resists tomorrow's question, so a report nobody asked for at the start can mean a migration or a second copy of the data.
There is a smaller one, and it is more irritating. A composite index has to exist before the query that needs it runs, so a new list view is two changes rather than one.
Neither is hidden from you. They are the price of a backend whose growth does not arrive with a bill, and the alternative is paying for reads nobody budgeted for.
What is excluded here is excluded everywhere in this catalogue. Visual design as a standalone deliverable. Native iOS. Blockchain work. Copywriting and content.
Any architecture that needs a paid service in the critical path gets flagged before it is built, not after. Thirty days of bug fixes at no charge, and after that nothing is automatic.
A free tier is a quota somebody else sets, and it can be moved without asking me or you. The design keeps the number of places that change can reach as small as it can be, and every list query I have written since that outage carries an explicit limit.
from $800
How long it takes
Small features 1–2 weeks, an MVP 4–8 weeks, a full production app 8–16 weeks. Those are ranges I have hit on work of that shape before. The scoping call settles how many distinct questions the data has to answer, because the model is shaped by that list rather than by the number of screens.
Every engagement of this shape covers
- Data model shaped by the queries it must answer
- Security rules, and the probe that proves them as a non-admin
- Composite indexes for every list read
- Every list paginated, counts by aggregation
- Authentication and account deletion end to end
Built with
- Firebase
- Firestore
- Supabase
Will the backend stay on the free tier?
It is designed to, because the read budget is a design constraint from the first query, not an optimisation afterwards. Every list read is paginated with an explicit limit and counts come from an aggregation, so the cost of a screen tracks what the user asked for rather than the size of the collection. Quotas belong to the vendor, so I will not promise their future.
How do you know the security rules actually hold?
By probing them signed in as an ordinary user, with somebody else's data in the database — that probe is part of what the service covers. An admin account short-circuits the exact check you are trying to make, which is why the verification is never done as an admin. A rule that reads an owner field is only satisfied by a query carrying the matching filter, so the rule and the query are written together.
Firestore or Supabase?
Whichever the queries argue for, and that argument happens on the scoping call. Firestore suits documents read by key and lists read by a known filter. Postgres with row-level security suits data you will want to ask new questions of later. Both sit on a free tier, and both are the same job on different machinery.
Is account deletion included?
Yes, end to end. Deleting a user is easy; deleting everything that references them is a query plan, and that second half is the part most products describe without finishing. It is written and probed like any other rule.
How much does a backend build cost?
$800 USD is the floor for a small, well-defined feature. Everything above that comes from a scoping call, in writing, before any work starts. What moves the number here is how many distinct questions the data has to answer, because each one is a query, an index and a rule rather than a screen.
https://aoneahsan.com/services/firebase-backend-platforms