On June 22, 2026, Google quietly turned off the lights on new signups for Firebase Studio. No more new workspaces. No new accounts. The full shutdown comes March 22, 2027, and Google's own docs are blunt about what happens then: "All remaining data will be permanently deleted and cannot be recovered."
Here's the part that should stop you. Firebase Studio launched in April 2025 as Google's big AI pitch, the place where you describe an app in plain English and the agent builds it for you. That's about 14 months from "build your apps here" to "no new builders allowed."
I'm not writing this to dunk on Google. I'm writing it because the way they're winding it down accidentally teaches the single most important thing a builder can learn about where their work actually lives.
What survives and what disappears
Read Google's migration notes closely and you'll see two very different fates.
What survives: "Any apps already deployed to Firebase will continue to run even after the sunset date." Your databases, your authentication, your hosting, all of it keeps humming. Those run on infrastructure that exists whether or not the build tool does.
What disappears: the workspace itself. The development environment, and any code you didn't export, gets wiped. Gone for good on the deletion date.
Sit with that split for a second, because it's the whole lesson. Your running app and the place you built it are two completely different things. The app keeps going because at some point it got pushed out to infrastructure. The build environment dies because it was only ever rented.
If your app is live right now, it's easy to feel like you own it. You can visit the URL. Customers use it. It works. But "my app is live" and "I own the thing that built it" are not the same sentence, and a lot of people are about to find that out the expensive way.
The category error nobody catches in time
Here's the trap, and it's a quiet one. You build something with an AI tool, it deploys, it works, and you move on. You never go back and ask: if this platform vanished tomorrow, what would I actually still have in my hands?
Most people assume the answer is "everything." The real answer is "whatever you exported, and nothing else."
And the export story has fine print most builders never read. When you migrate a Firebase Studio project out, the one-click path gives you a brand new URL ending in *.run.app. Want to keep your existing custom domain? Now you need your own API key and you have to wire up GitHub sync yourself. The convenient button doesn't preserve the thing your customers have bookmarked.
It gets worse for vibe-coded apps specifically. The prompts and the AI's responses, the actual conversation that built your app, are the real source of truth for how the thing works. Google stores those in a hidden folder:
/home/user/.idx/ai
That folder is not in the export zip. The thing that built your app for you is the thing you're least likely to walk away with. Think about that. The most valuable record of your project, the "why is this code shaped like this" history, is also the least portable asset you own. Or thought you owned.
This isn't a Google problem, it's a rented-platform problem
Google shutting things down is practically a genre at this point. The folks at killedbygoogle.com count nearly 300 dead products. So it's tempting to make this a "lol, Google killed another thing" story. It isn't.
The pattern is bigger than one company. Across the AI app builder space, some platforms put code export behind a paid tier, which means you can have a working app and still not be allowed to leave with the code unless you pay up. And on the distribution side, app store gatekeepers spent early 2026 freezing updates for AI-builder apps with basically no warning, on the grounds that they run code that changes their own behavior.
So your build platform is temporary from two directions at once. The place you build it can shut down. The gate between your app and your users can change the rules overnight. Neither of those is something you control by being a good builder. They're somebody else's business decision.
The uncomfortable truth underneath all of it: the more a platform does the building for you, the more it's a bet that company can call off. Stable, boring backend services tend to survive because lots of people depend on them. The shiny "describe it and we'll build it" layer is exactly the kind of strategic experiment that gets folded into something else 14 months later.
What "owning it" actually means
Owning your tech stack doesn't mean you have to hand-code everything or run your own servers. Use the AI tools. Build fast. That part is genuinely great.
It means you can answer one question without flinching: where does this live, and could I take it with me today?
That's the line. Exported, deployable code in a repo you control is an asset. A working app inside a platform you don't control is a convenience with an expiration date you didn't get to pick. Both can be true at the same time, and most people only own the second one without realizing it.
We build and run things for clients with that question answered up front. Your code in your repository. Your app on infrastructure that doesn't evaporate when a vendor reshuffles its priorities. Boring, durable, yours. The fun part of building with AI shouldn't come with a hidden clause that says "until we change our minds."
If you've built something you'd hate to lose and you're not 100% sure which parts are actually yours, that's worth a conversation. The first one's free, no commitment. And if you'd rather just keep learning at your own pace, subscribe free at kief.studio for the resources and guides we put out for builders trying to keep what they make.