r/Firebase

Hey all — I build UpAlerts, a freelance-job-alerts app for Upwork/Indeed/LinkedIn (about 20,000 active users). Just shipped a release that's mostly a performance/UX rewrite, and the debugging was interesting enough that I figured I'd share.

The home feed was the worst offender. Every bottom-nav switch, every scroll that triggered a rebuild, and every modal close was silently re-subscribing to the same Firestore streams. The culprit was a pattern I see a lot in Flutter code — passing DatabaseAPI.xxxStream() directly into a StreamBuilder inside build(). Looks harmless, but each rebuild constructs a new Stream object, which makes StreamBuilder.didUpdateWidget tear down and resubscribe. That's a billed read every time. Fix was memoizing streams in initState and moving the user-profile doc behind a single app-wide cubit that everything else reads from. Net result: ~87% fewer reads on home.

Persona Hub was a different problem — it felt laggy because every switch re-hit the network. Added a 30-min cache + optimistic writes + persisted selection, and now it just feels instant. Classic case where the right fix wasn't making the network faster, it was not going to the network.

The other big change was the paywall. Old version was a hard wall with weak copy. New version is a 7-day free trial that actually lets people use the full thing first. Early data is way more interesting than I expected — conversion on trial-start is much higher than the old buy-now flow, but what matters is trial-to-paid in 7 days, and I don't have enough cohorts yet to call it. Will report back.

Here's the Play Store link if anyone wants to try it: . Always happy to answer questions or take feature requests — especially interested in what freelancers here wish job-alert tools actually did.

Hey everyone, we just got a massive bill (and climbing, because Google's delayed billing is just faaaantastic...) for a known (to Google, and perhaps you too) issue.

Long story short: Back in February, TruffleSecurity exposed a Google vulnerability. (Read their blog, it's very detailed)

The quickest way to check if your credentials MIGHT be exposed is to run this curl command:

curl ""

There's 3 possible outcomes.

1. If it returns {} then the API is enabled and if your key is exposed through the browser, you should take immediate action.

2. It returns a large JSON that contains this message:

   1. "Gemini API has not been used in project 12345 before or it is disabled. Enable it by visiting then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."

   2. This means that the Gemini API is NOT enabled, but enabling WILL allow others to use this API key.

3. It returns a small JSON with this message:

   1. "Requests to this API method google.ai.generativelanguage.v1beta.FileService.ListFiles are blocked"

   2. This means that even IF the Gemini API service was enabled, this key can't be used to exploit your resources.

We audited our credentials when I first read this in February, and back then, I checked that the keys didn't have permissions enabled (the second case, not the third)... until yesterday, when I wanted to use Google Cloud Assist to review some IAM permissions, and it turned on the Gemini API for that project.

The strange thing is that the second key, as far as I know, was never used/published anywhere.

Now, the timeline...

• I turned on the API around 4PM my time.

• Google reaches out the following morning, around 11AM my time stating unusual API access through "AI Studio" (Which we don't use in our projects)

• I turn off Gemini API around 11:05AM

• We check billing and the amount was a small amount at that point

• We check billing again an hour later and it's 200 times that. (The API was already off, but again, delayed billing...)

What you should do: Make sure that all your credentials
have this permission blocked by checking with the curl command, not just disabled.

Hi everyone. I'm building an image generation web app and I've hit a wall with an infrastructure issue.

I used the Google AI Studio app builder for the prototype. The code works, but the flow requires each user to log in, enter their own API Key, and have the system save it along with their generated image history.

The problem is that when trying to save this data, the console throws this error:

7 PERMISSION_DENIED: Cloud Firestore API has not been used in project ais-us-east1-... before or it is disabled.

I've done some research and I understand exactly why this is happening: the generated code is pointing to Google AI Studio's closed sandbox environment. Since I'm an external user there, I don't have admin permissions to enable the Firestore database in that specific project.

I know the theoretical solution is to create my own Firebase project from scratch and point the code there, but I haven't done it yet and I'm not entirely sure about the correct migration process.

My main questions are:

The step-by-step migration: How do I properly "unplug" this app from the Google sandbox and connect it to my own environment? I assume I need to create a project in Firebase, register the web app, and copy the new firebaseConfig, but is replacing that block in the source code enough? Do I need to do anything else regarding credentials or the local development environment?

Initial structure: Once I manage to connect my own database, what's the best way to structure this in Firestore? Should I create a "users" collection and store the API Key inside it, or is that a major security risk even if it's my own database?

History management: For recording each person's generated images, do you recommend a subcollection within the user document, or a global collection filtered by the user ID?

Any guidance to help me unblock this migration would be a lifesaver. Thanks!