Forem: Fascia

Before You Pick a Backend Platform, Ask These Questions

Fascia — Fri, 06 Mar 2026 14:58:03 +0000

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.

Design-Time Safety: How Fascia's Risk Engine Blocks Unsafe Patterns Before Deployment

Fascia — Wed, 04 Mar 2026 09:24:15 +0000

Runtime error handling is an admission that your design phase failed.

If you catch a "payment processed but order not created" error at runtime, the real bug is that your design tool allowed a payment call outside a transaction boundary. The error handler is treating a symptom. The disease is in the architecture.

Risk Levels

Fascia's Risk Engine classifies every Tool (API endpoint) into three levels based on its flow graph patterns:

Green — Safe to Deploy

All of the following must be true:

Only Entity Actions (create, update, transition, soft-delete) — no raw writes
Explicit transaction boundary around all write operations
No unbounded queries (all reads have pagination or limits)
No external calls, OR external calls are outside transaction boundaries

Yellow — Warning, Requires Acknowledgment

Any of the following triggers Yellow:

External call (payment, email, HTTP) inside a state transition
Missing retry configuration on external nodes
High row impact (> 100 rows in a single write operation)
Read without explicit limit
Missing timeout on external nodes

Red — Blocked, Cannot Deploy

Any of the following triggers Red:

Raw write (SQL without Entity abstraction)
Unbounded UPDATE (no WHERE clause or row limit)
Payment call without rollback/compensation mechanism
Missing transaction boundary around write operations
Hard delete (instead of soft delete)
External call with side effects inside a transaction boundary
Circular dependency in flow graph (not a DAG)

Red signals cannot be acknowledged or dismissed. They must be resolved.

Why Design-Time, Not Runtime?

The key insight: unsafe patterns are structural, not behavioral. A payment call inside a transaction boundary is always wrong, regardless of the specific data flowing through it. You don't need to wait for runtime to discover this.

By analyzing the flow graph statically:

Every developer sees the risk before deployment
Non-technical stakeholders can understand "this endpoint is Yellow because it sends emails during state transitions"
Audit logs show risk acceptance decisions, not just runtime errors

Auto-Fix Suggestions

When a risk signal is detected, the engine doesn't just flag it — it suggests the fix:

Signal	Suggested Fix
Missing transaction	Wrap write nodes in a Transaction boundary
External call in transaction	Move external call outside transaction
Missing retry	Add Retry node (max 3 attempts, exponential backoff)
Unbounded update	Add WHERE condition or row limit
Payment without error edge	Add error edge to recovery flow
Hard delete	Convert to soft delete (set `deleted_at`)

The Safety Agent (multi-model cross-check) validates these suggestions before presenting them.

The Execution Contract Enforces It

Even if something slips past the Risk Engine, the 9-step execution contract provides defense in depth:

Step 3 (Policy Check) catches budget/row-limit violations
Step 6 (Enforce Invariants) catches business rule violations before commit
Step 7 (Commit/Rollback) ensures all-or-nothing transactions
Step 8 (Audit Log) records everything unconditionally

But the goal is to catch problems at step 0 — before the code even exists.

Next in this series: BYOC Architecture — Why Your Data Should Stay in Your Cloud.

fascia.run

AI-Generated Backends Break in Production. We Replaced Code with Specs.

Fascia — Wed, 25 Feb 2026 18:51:54 +0000

AI backend tools generate code. Fast. The problem is not how the code is generated - it's what's missing from the output.

Generated code ships without structural guarantees. No enforced transaction boundaries. No mandatory audit logging. No invariant checks before commit. No risk classification before deployment.

The code works until it doesn't, and when it breaks in production, you're debugging code you didn't write.

We made a different choice.

The Problem with Generated Code

When an AI generates your backend code, you get:

No structural safety: Transaction boundaries are optional, not enforced. A payment can process while the order creation fails.
No audit trail: Logging is ad-hoc. "What happened at 3am?" has no guaranteed answer.
Hidden complexity: 6 months later, nobody knows what the generated code does. Including the AI that wrote it.
Security gaps: 45% of AI-generated code contains vulnerabilities (Stanford/UIUC). Not because the AI is bad - because code is too flexible a medium to guarantee safety.
No rollback strategy: External calls with side effects aren't separated from reversible operations.

For prototypes, this is fine. For production backends handling payments, reservations, and user data? It's a structural risk.

The Alternative: Specs Instead of Code

Fascia doesn't generate code. It generates structured specifications - and executes them directly.

When you describe your business in natural language, AI produces specs that define:

Entities: Business objects with fields, relationships, status machines, and invariants
Tools: API endpoints with typed input/output, trigger types, and flow graphs
Policies: Design-time rules that block unsafe patterns before deployment

At runtime, a deterministic executor (written in Go, ~50ms cold start on Cloud Run) reads the spec and follows it. No code interpretation. No LLM inference. No variability.

The "no LLM at runtime" rule isn't about what competitors do - it's about what production systems need. Determinism. Auditability. Predictable behavior under every condition.

The 9-Step Execution Contract

Every API endpoint follows the same sequence:

Validate input against JSON Schema from the spec
Authorize - JWT verification, RBAC role check, row-level ownership
Check policies - design-time rules enforced deterministically
Start transaction - explicit boundary, no auto-commit
Execute flow graph - a DAG of typed nodes (Read, Write, Transform, If/Switch)
Enforce invariants - business rules checked before commit
Commit or rollback - all-or-nothing, no partial state
Write audit log - append-only, unconditional, every execution
Return typed response - matches the output schema from the spec

No shortcuts. No "well, this endpoint is special." The rigidity is the feature.

With generated code, any of these steps can be missing. With specs, they're mandatory. The format doesn't allow you to skip step 4 or forget step 8.

Design-Time Safety

The Risk Engine classifies every API endpoint before deployment:

Green: All writes in transactions, no unbounded queries, no unsafe patterns. Deploy freely.
Yellow: External call without retry, high row impact. Deploy with acknowledgment.
Red: Payment without rollback, write without transaction, unbounded UPDATE. Cannot deploy.

Red signals cannot be dismissed. Fix the design.

This is the key difference from generated code. In a codebase, these patterns are caught by code review (maybe) or by production incidents (definitely). In a spec-driven system, they're caught by static analysis before anything runs.

The Tradeoff

All business logic must be captured in the spec at design time. The runtime cannot improvise. This means:

Complex conditional logic must be modeled as flow graph branches
Custom business rules use a restricted Value DSL (no arbitrary code)
External API calls are explicit nodes with retry/timeout configuration

This is a real constraint. Generated code is more flexible - you can do anything, including unsafe things.

We think the constraint is worth it. Production backends should be provable, not flexible.

Specs vs Generated Code

Dimension	Generated Code	Spec-Driven (Fascia)
Transaction boundaries	Optional (developer's choice)	Mandatory (format enforces)
Audit logging	Ad-hoc	Every execution, unconditional
Unsafe pattern detection	Code review / production incident	Static analysis before deploy
Readability at month 6	Depends on code quality	Spec is always readable
Rollback strategy	Hope for the best	Explicit compensation flows
Response time	Varies by implementation	12-50ms (deterministic executor)

We're building Fascia in public. Pre-launch, solo founder, 150+ PRs deep.

Next in this series: The Risk Engine - How We Classify Green, Yellow, and Red.

fascia.run