Write the builder exit plan before launch

Inventory every form of state

An exported repository is only one part of an application. List source and generated code, dependency locks, database schema and records, object storage, authentication users and provider settings, environment variables, scheduled jobs, integration credentials, domain and DNS control, deployment configuration, logs, analytics definitions, and builder-specific conversation or workflow history. Mark each item as portable, reproducible, replaceable, or trapped. A platform may offer Git synchronization while leaving managed identity or a proprietary workflow outside the repository. Conversely, some state can be recreated from scripts even if it is not exported directly. The exit plan should describe the smallest independent package from which a competent engineer can restore useful service, not merely the files visible in a code panel.

Test the cold path

Create a clean environment outside the builder. Clone the repository, install from locked dependencies, supply documented non-production configuration, restore a sanitized data snapshot, run migrations, build, test, and serve the app. Replace platform conveniences one by one: managed functions, image transformations, email, authentication callbacks, and scheduled tasks. Record which steps require undocumented UI actions or access to the original account. Vercel's v0 materials describe GitHub backup and synchronization paths, while Firebase's official sunset notice says Firebase Studio projects can be exported to GitHub or downloaded. These first-party statements establish available paths at the checked date; only a rehearsal establishes that a particular application's path is complete.

Worked example: a hypothetical appointment app

A hypothetical clinic prototype has generated source in Git, a hosted database, builder-managed authentication, an email integration, and a custom domain. The team exports code and discovers that database row-level policies were configured in a dashboard, OAuth callback URLs are undocumented, and reminder jobs exist only in the builder. Before launch, it captures schema and policy migrations, creates a data export and restore drill with synthetic records, documents identity-provider setup, moves reminder definitions into versioned configuration, and confirms domain ownership in an account the organization controls. A second engineer restores the app to a separate test host and verifies login, booking, reminder generation, and deletion. The exercise reveals portability gaps without requiring an actual vendor departure.

Define exit thresholds and ownership

Assign owners for source, data, identity, infrastructure, and legal retention. State the recovery objectives that matter to the application and the conditions that trigger migration planning: product sunset, unacceptable policy change, missing security control, sustained export failure, or loss of required integration. Keep current exports on an independent schedule and test restores, because a backup that shares the platform's account and failure domain is weak evidence. Preserve license and provenance records for generated and third-party components. Do not demand perfect provider neutrality; platform-specific features can be a rational trade. Price the replacement honestly and identify the point beyond which deeper coupling requires explicit approval. Recheck the plan after adding each managed service, not only during annual procurement.

Firebase Studio sunset and export paths ↗

Vercel Academy: GitHub backup from v0 ↗

Keep evidence beside the inventory

Store the date, environment, operator, duration, and defects from the latest successful restore beside each inventory item. Portability is a dated test result, not a feature label. If a component has never been restored independently, mark it unverified even when the platform advertises export or synchronization.