AI App Builder Audits · AI Development Series
Firebase Studio App Audit
Google's builder produces real code on real infrastructure. Two things decide whether it is safe and affordable: your security rules, and how your data is shaped.
What Firebase Studio actually hands you
Firebase Studio is Google's browser-based, agent-driven development environment. It writes real code in mainstream frameworks and wires it to Firebase, and because it is a full environment rather than a black box you can see and change everything it does.
What a Firebase Studio application is made of
- Frontend React, Angular, Next.js or Flutter, depending on the project
- Database Firestore, a document database
- Authentication Firebase Auth
- Server logic Cloud Functions
- Access control Firestore Security Rules
- Hosting Firebase Hosting, with deployment built in
The architecture is the same shape as Lovable on Supabase: the application in the browser talks to the database more or less directly, using configuration anyone can read out of the page. Nothing about that is wrong — it is how Firebase is designed — but it puts the entire security burden onto your Firestore Security Rules.
Firebase adds a second concern that most platforms do not have, and it catches people out badly: you are billed per document read. A screen that fetches more documents than it needs is not just slow, it is expensive, and the cost scales with your traffic. We have seen bills that were a design problem rather than a success problem.
What we consistently find
These recur in generated Firebase applications, and the first is by far the most serious.
Security Rules left open or written permissively
Firestore starts in a mode that either allows everything or denies everything, and generated applications need rules written before they will work at all. What gets written is frequently the minimum that stops the errors: any signed-in user may read any document in the collection.
Your interface only ever requests your own records, so it behaves perfectly. The database is not enforcing that restriction, and the configuration needed to query it directly is embedded in your page for anyone to find.
What it costs you: every record in the collection readable by any user who signs up. Reportable under UK GDPR.A bill that grows faster than your traffic
Because Firestore charges per document read, the cost of a page is decided by how it fetches data. Generated code commonly loads an entire collection and then filters it in the browser, which is invisible at ten documents and ruinous at ten thousand.
The same pattern inside a loop — fetching a list, then one document per item — multiplies it again. This is the most common cause of a Firebase bill that suddenly does not make sense.
What it costs you: costs that rise far faster than usage, for no functional benefit.Relational data in a document database
Firestore has no joins. Data that has relationships must either be duplicated into the documents that need it, or fetched with additional round trips. Generated schemas usually do the first without also doing the work of keeping the copies in step.
The result is customer details that are correct in one place and stale in three others, with nothing in the database preventing it.
What it costs you: inconsistent data, and reports that quietly disagree.Cloud Functions running with full privileges
Functions use the Admin SDK, which bypasses Security Rules entirely by design. That is correct for trusted server-side work, and it means any function reachable by a user must do its own permission checking.
Generated functions often accept an identifier from the request and act on it. One such function undoes an otherwise careful set of rules.
What it costs you: a single endpoint that will act on anyone's data on request.Where Firebase Studio is genuinely good
Firebase is mature, genuinely well-engineered infrastructure with a long track record, and Firebase Studio gives you real code on top of it rather than a proprietary format. As a foundation to build a business on, it is a considerably safer bet than most things in this category.
Genuinely well suited to
- Applications that need to scale without you managing servers
- Real-time features, which Firestore handles very well
- Teams already inside the Google Cloud ecosystem
- Mobile and web applications sharing one backend
- Prototypes that may genuinely become production systems
Where it needs engineering behind it
- Multiple separate customers whose data must never mix
- Anything holding personal data, health data or payment details
- Data with real relational structure and consistency requirements
- Applications where per-read cost matters at your expected volume
- Anything requiring reporting across large collections
The honest summary: Firebase Studio produces something you can genuinely build on. The two things that decide whether that goes well are entirely configuration rather than code: whether your Security Rules actually restrict anything, and whether your data is shaped for how Firestore charges.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- More than one customer or organisation uses it
- It stores personal data of any kind
- Your Firebase bill has grown faster than your user numbers
- You cannot say with confidence what your Security Rules allow
- You are about to promote it, launch it, or raise on it
You are probably fine if
- You are the only person who uses it
- It holds nothing you would mind losing or leaking
- It is a prototype and everyone treats it as one
- Usage and costs are both trivial and expected to stay that way
Questions about auditing a Firebase Studio build
Not necessarily. Having rules and having rules that restrict anything are different things. The most common pattern we find is a rule allowing any authenticated user to read a whole collection, which passes every test you would think to run while you are the only user. We read them as an attacker would: what is the most this rule permits, rather than what does the app happen to ask for.
Yes, and it is one of the more satisfying parts of the job because the savings are usually immediate. Runaway Firebase costs are almost always a small number of read patterns rather than genuine demand. The report identifies which screens are responsible and what the fix is for each.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Firebase Studio expertise, it is that the thing being audited is Firestore, Cloud Functions and a JavaScript front end, which is what we have been working with for years.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- Firestore Security Rules, read as an attacker would read them
- Every Cloud Function that runs with admin privileges
- Your data model and how it fits a document database
- Read patterns and what they will cost at ten times your volume
We reply within one working day.
