Your Code Is in GitHub. That Doesn't Mean You Can Recover Your App.

The problem

You connected your AI-built app to GitHub. That is a good move. It is also easy to overestimate what it gives you.

A Git repository can contain your React app, API code, SQL migrations and configuration files. But a production application is usually larger than its repository.

• live database data
• object storage and uploaded files
• environment variables and secrets
• auth-provider configuration
• payment webhooks
• scheduled jobs
• custom domains and DNS
• deployment settings
• production-only infrastructure state
• monitoring, logs and alerting

That distinction is showing up repeatedly in current founder discussions. In a convenience sample of 10 public Replit and Lovable threads reviewed from 11 August to 10 September 2026, 9 explicitly discussed database or data access, deployment or environment state, migration, portability or production infrastructure control. This is not a prevalence estimate for AI-built apps. It is evidence of a recurring post-MVP question: I have the code. Do I actually control production?

GitHub solves one important part of the problem

Keeping your source in Git is good engineering. It gives you history, diffs, branches, collaboration and a path to build somewhere else.

But import and migration documentation from builder platforms makes the missing pieces clear. Code and schema can often move while existing records, secrets, custom domains, environment values and platform-specific services may not.

Source-code portability is not the same as production recoverability.

What your application actually looks like

A modern AI-built SaaS may look like one product in the browser, but operationally it is a set of connected assets. GitHub may protect the application code. Your customers depend on the whole system.

• Application code in GitHub
• Production database and schema state
• Uploaded files and object storage
• Authentication provider settings
• Secrets and environment variables
• Deployment runtime
• Domain and DNS records
• Logs, monitoring and alerting

What is perfectly fine today

This is not an argument for abandoning managed platforms. For an early product, keeping build, deploy, database and debugging close together can be a major advantage. The founder can ship faster and operate with less infrastructure knowledge.

You do not become more sophisticated by moving everything to AWS, Kubernetes or a VPS before you need to. Every useful platform creates some dependency. The better question is: if this dependency becomes a problem, do I understand what I would need to recover?

What changes when the MVP becomes a business

The architecture may stay exactly the same while the consequence changes. Yesterday you had test accounts, fake data, one founder and no launch deadline. Tomorrow you may have paying customers, uploaded files, staff relying on the system, Stripe payments and customers expecting the service to be there.

At that point, "the platform usually handles it" is no longer the whole operating model.

Failure mode 1 - the repository is not what is running

A founder can have source code in GitHub and still be unsure whether that commit is the version actually running in production. External functions, migrations, deployment settings and backend behavior can drift from the repository.

The practical control is simple: you should be able to answer which commit is running in production. If you cannot, recovery starts with ambiguity.

Failure mode 2 - you can rebuild the app but not its state

Imagine the builder disappeared for a day and you created a fresh deployment from GitHub. You might recover the UI and API, but would you recover customer records, uploaded files, auth users, webhook secrets, production environment variables and the correct database schema version?

Backup and restore are two different capabilities. A backup you have never restored is evidence that you copied something, not evidence that you can recover the business.

Failure mode 3 - development and production boundaries blur

Several fresh discussions involved development and production databases, secrets or deployment state becoming difficult to reason about. That is dangerous even when nobody loses data.

You do not need complex infrastructure to reduce this risk. You need an explicit environment map: which database, secrets, domain, payment mode and data policy belong to development, staging and production.

Failure mode 4 - a platform incident becomes a business incident

A managed platform can have an outage. So can AWS. So can your own code. The production-readiness question is not whether failure is possible. It is whether you have enough independent visibility and control to make a decision when it happens.

• Is the code unhealthy or the platform unhealthy?
• Is the database still intact?
• Is production pointing to the expected environment?
• Can you export the data?
• Can you deploy the last known-good commit elsewhere if necessary?
• Who controls the domain?

If every answer requires the same broken control plane or support ticket, one operational dependency has accumulated too much responsibility.

The recovery test I would run before a rewrite

Do not migrate everything. Run a tabletop recovery exercise. Assume your builder is unavailable for 24 hours. Can you identify, without changing production:

1. the exact production commit
2. the production database and schema version
3. where customer files live
4. which secrets the runtime requires
5. who controls auth configuration
6. who controls the domain and DNS
7. how to export or restore production data
8. how to create a fresh deployment from source

Then test the parts that are safe to test in staging. You are not trying to prove that you can leave the platform tomorrow. You are trying to remove unknowns.

A useful way to think about RTO and RPO

RTO, or Recovery Time Objective, is how long the product could reasonably be unavailable before it becomes a serious business problem. RPO, or Recovery Point Objective, is how much recent data you could reasonably lose.

An early beta may tolerate a long RTO and manual recovery. A product processing orders or running a customer daily operation probably cannot. Your architecture should match the consequence.

Signals that mean you should do this now

• real customer or personal data is stored
• people are paying
• uploaded files would be difficult to recreate
• the app has multiple production integrations
• staff or customers rely on it operationally
• a platform change or outage has already surprised you
• nobody can confidently explain how production differs from development
• moving the app would require discovering the architecture while under pressure

What not to over-engineer

You probably do not need multi-cloud, Kubernetes, active-active databases, a custom deployment platform, a full SRE team or to leave Lovable, Replit or Supabase just because the product has traction.

For many early products, production hardening may be as small as GitHub as an external source repository, a documented production asset map, tested database backup or export, clear dev/prod secrets, domain ownership you understand, a smoke test after every publish and a short recovery runbook.

WFS engineering view

A production-ready system is not one with zero vendor dependency. That is unrealistic. A better standard is to use managed platforms aggressively where they buy speed, while keeping enough ownership to understand, verify and recover the parts your business depends on.

GitHub is part of that. It is not the whole recovery plan. The Production Gap often appears precisely here: the software is functional, but operational ownership has not caught up with how important the product has become.

What's Next?

Your app works. The next question is whether the architecture is carrying more business risk than you realise. Use the WFS Architecture Check to map the current system, identify the production boundaries that matter now and avoid rewriting the parts that are already good.