Managing Your AI App After Migration
You moved off Base44 or Lovable onto your own Supabase and Staticbot hosting. Here's how to keep shipping — with a full audit trail and atomic deployments you control.
The migration is done. Your database, edge functions, storage, and auth now live on a Supabase project you own, and your frontend is deployed to your own infrastructure — Cloudflare Workers for full-stack apps, AWS S3 + CloudFront for static sites. The important part: it's all standard now. No proprietary SDK, no managed entity layer, no vendor console you can't leave. That opens up how you build from here on.
Two ways to keep building
You don't have to pick one and stick with it — many teams do both. The point is that owning the stack gives you options the builder never did.
Keep using the AI builder
Stay in Lovable, Bolt, or Base44 exactly as before. With Continuous Sync turned on, every change you ship there flows automatically to the Supabase and hosting you now own. Nothing about your workflow changes — the difference is where production actually runs.
Edit the repo with Claude Code
Because it's a normal repo against a normal Supabase project now, you can open it in Claude Code (or Cursor, or Codex) and change anything — add a table, write an edge function, refactor the frontend. Push to your branch and Continuous Sync applies it, or deploy on your own terms. No builder credit limits, no black-box backend.
Both paths coexist cleanly
Staticbot deploys production from a dedicated staticbot/live branch. Your AI builder's changes are applied onto it, and if you also edit with Claude Code, those commits land the same way. The builder keeps writing to its own branch, untouched — so you can mix a Lovable session and a Claude Code refactor without either side stepping on the other. Merging staticbot/live back into the builder branch is an explicit, opt-in "cut the cord" move — never automatic.
Continuous Sync is your audit trail
Every push produces a sync run — a recorded, inspectable unit of change. Instead of a builder-managed backend where a change just "happens," you get a granular diff of exactly what moved and a deterministic order in which it was applied to the infrastructure you own.
Recorded diffs
Each sync run captures what changed — new SQL migrations, changed edge functions, frontend, storage, and auth — tracked fromRepoVersion → toCommitSha for reproducibility.
Review gates
Destructive migrations (DROP TABLE, ALTER COLUMN) pause for your explicit approval. Non-destructive syncs apply automatically. You decide what reaches production.
Version pinning
Templates are pinned to Git commit SHAs, so every deploy maps back to an exact commit. You can always see — and re-run — the precise state that shipped.
Atomic deployments, in the right order
A sync run doesn't fire off changes at random. It applies them in a fixed, dependency-safe sequence so your database and frontend never drift out of step:
1. SQL migrations first
New files in supabase/migrations/ apply sequentially to your Supabase project — managed or self-hosted — before anything depends on them.
2. Edge functions next
New or changed functions in supabase/functions/ deploy in parallel to your Supabase project.
3. Frontend last
A full rebuild and deploy to Cloudflare Workers (full-stack apps) or AWS S3 + CloudFront (static sites), followed by CDN invalidation — so users see backend and frontend change together.
The result is deployments you can reason about: an ordered, logged, reproducible change set landing on infrastructure you own — the opposite of an opaque managed backend where you can't see, audit, or roll back what happened.
Optional: drive it all from your AI agent
None of the above requires an MCP server — the dashboard does everything, and your infrastructure runs whether or not you ever touch a terminal. But if you like managing things from Claude Code or Cursor, the staticbot-mcp server lets an AI agent trigger syncs, inspect sync runs, deploy, and even run new migrations via the Staticbot API — one API key, no context-switching. It's entirely optional. See the migrate-via-chat write-up for how the same tools drive a migration end to end.
You're never locked in — including to Staticbot. Your Supabase project and your Cloudflare/AWS deployment are standard and keep running on their own. Pause Continuous Sync, disconnect the builder, or manage everything by hand whenever you want. Ownership is the whole point.
Build there. Own it here.
Keep shipping in your AI builder or in Claude Code — and let every change flow to infrastructure you control, with a full audit trail.