I've been building a backend platform for the past year. And before that, I shipped two products on platforms that eventually made decisions I didn't like.
Parse got shut down. Heroku killed its free tier. PlanetScale dropped its free plan with 30 days notice. If you've been around long enough, you have a story like this.
The risk isn't hypothetical. Platforms die, pivot, or cut tiers. And when they do, you find out exactly how deep the dependency runs.
So here are the questions I wish I'd asked before committing.
Where does my data actually live?
This is the most important question, and most platforms bury the answer.
"Managed database" usually means their servers. Your users' data, business records, and application state are sitting in an infrastructure you don't control. You're trusting their security posture, their compliance certifications, and their word that they won't misuse it.
For a side project, that's fine. For anything touching financial records, health data, or EU citizen data, it's a structural liability - not just a risk you can accept in a checkbox.
Ask explicitly: Is my data in their cloud account or mine? If it's theirs, that's the baseline you're working from.
What happens to my running app if you shut down tomorrow?
Think through the failure mode concretely. If the platform went offline right now:
- Would your warm, running instances keep serving requests? Or does every request depend on their control plane?
- Would cold starts fail? (They would if the executor needs to pull its configuration from the platform.)
- Would your app continue to work for hours? Days? Until the next cold start?
The answers tell you what your actual blast radius is. A platform that gives you warm instance continuity but breaks on cold start is a very different risk profile than one that goes down the moment their API does.
There's no universally right answer here. But you should know what you're getting.
Can I export everything I need to run independently?
Data export is table stakes. Most platforms offer it. But data alone isn't enough to run your app.
You also need:
- Your application logic (in a format you can re-deploy)
- Your schema definitions
- Your configuration and secrets
- Your infrastructure setup (or the ability to recreate it)
Ask: If I exported today and had to rebuild on raw infrastructure, what would I need? How long would it take? What can't be exported?
Some platforms make this easy. Others make it technically possible but practically painful. The platforms that can't answer this clearly are the ones to worry about.
What can't I do without you?
Every platform has things you can only do through them. The question is whether you know what those things are upfront.
Common examples:
- Schema migrations (if the platform manages your DB, do you control the migration tooling?)
- Spec or logic modifications (can you edit your application without the platform's build tooling?)
- Debugging and observability (are logs and traces in their system only?)
- Authentication flows (if their auth goes down, do your users lose access?)
Make a list. Not to avoid platforms with dependencies - that's impossible - but to understand what you're committing to.
How hard is the migration if I leave?
Data portability and system portability are different things.
Data portability means you can get a Postgres dump. Most platforms do this. It's a solved problem.
System portability means you can re-run your application without the platform. That's harder. If your application logic lives as configurations in the platform's proprietary format, a database dump doesn't help much. You still need to rebuild the application.
The question to ask: "If I had to migrate away in 30 days, what would the actual work be?" If they can't answer concretely, that's telling.
How some popular platforms compare
These aren't exhaustive reviews. Just quick answers to the same questions, based on public documentation.
Supabase: Your data lives in their managed Postgres (or you can self-host). If Supabase shuts down, the database is standard Postgres, so data export is straightforward. Auth, Edge Functions, and Realtime depend on their infrastructure. Migration effort is moderate: you keep the database, but need to replace their SDK layer. Open source, so self-hosting is a real option.
Railway: Your app runs on their infrastructure. Data lives in their managed databases. If Railway shuts down, you need to migrate both your app and database to another host. Export is possible but you're rebuilding deployment config from scratch. Migration effort is higher because the deployment layer is proprietary.
Firebase: Data lives in Google's infrastructure (Firestore, RTDB). If Firebase changes pricing or drops features, you're migrating away from proprietary data formats. Auth is tightly coupled. Migration effort is high, because Firestore queries and security rules don't map cleanly to standard databases.
Each platform makes different tradeoffs. None of these answers are inherently wrong. The point is knowing what they are before you commit.
How Fascia answers these
I'll be direct about how my project answers these questions, including the parts that aren't perfect.
Where does the data live? In the customer's own GCP project. Every workspace gets its own Cloud SQL instance. Fascia's servers never touch your business data - not in transit, not in storage. That's the whole point of BYOC (Bring Your Own Cloud).
What happens if Fascia shuts down? Warm Cloud Run instances keep running. Cold starts fail, because the executor fetches its spec bundle from Fascia's API by default. If you haven't prepared an exported bundle in advance, you can't spin up new instances. This is a real limitation. The file mode exists (one environment variable switch) but requires you to do the infrastructure work ahead of time, not after the platform is gone.
Can you export everything? You can export the spec bundle - the structured definitions that drive execution. The executor itself is open Go code. The infrastructure is standard GCP resources. But you need to have done the export before you need it. If Fascia is down when you realize you need the bundle, you're stuck.
What can't you do without Fascia? Modify your specs. The design tools (Chat Studio, Flow Studio) live on Fascia's servers. A system you can't evolve is a system with an expiration date. If Fascia disappears, your running app works until the next cold start - but you can't add features or fix logic without the platform. That's a significant dependency.
How hard is the migration? The spec format is readable JSON. The executor is Go. The database is standard Postgres. A technically capable team could rebuild the execution layer. But it's not a 30-minute project.
One more honest note: Fascia is a solo-founder pre-launch project. The bus factor is 1. The specs are readable by anyone, the executor is deterministic, and the infrastructure is standard GCP - those choices were deliberate, partly because of this exact risk. But it's still a risk.
The universal takeaway
Every platform should be able to answer these questions concretely. Not with "we take security seriously" or "we have 99.9% uptime" - but with specific, technical answers about what happens in each failure mode.
If they can't, that's your answer.
The platforms that can answer clearly - whatever their architecture choices are - are the ones that have thought through their own failure modes. That's a signal worth paying attention to.
Pick the platform that fits your risk tolerance. Just make sure you know what you're tolerating.
Top comments (0)