From Lovable and Cursor Prototype to Production: The Migration Checklist

AI-assisted builders such as Lovable, Cursor, Claude Code, Bolt, v0, and Replit can shorten the path to a clickable product. That is real progress, but "the demo works" does not establish that "real users can rely on this." Production readiness is a separate body of evidence whose scope depends on the architecture, data, threats, regulation, and potential harm. This is the first-pass checklist we use when a prototype moves toward production.

None of this is a knock on the tools, and the tool label does not decide whether a system can run in production. Lovable and Replit both document production deployment options, while Lovable also documents GitHub sync, security review, and backend secret storage. Verify the exact plan and architecture. The checklist maps controls that still need evidence whether code was generated or written by hand.

Built a prototype with an AI IDE?

Book a Production-Readiness Review

What does "production" actually mean?

A demo can provide evidence that an idea and interaction work. Production readiness means defining service and risk objectives, then collecting evidence that the system meets them. It is not a universal guarantee or a single certification.

Authorization. Authenticated identities and permission checks at a trusted enforcement point for each protected action and data object.
Data integrity and recovery. Transactional behavior where needed, versioned changes, defined recovery objectives, protected backups, and tested restoration plus reconciliation.
Reliability. Capacity, failure handling, dependency behavior, deployment safety, and recovery matched to explicit service objectives.
Security. Confidential credentials outside untrusted clients, validated trust boundaries, maintained components, and controls derived from a threat model.
Observability. Logs, metrics, traces, alerts, and retention appropriate to the failures and investigations the team must handle.
Support. Ownership, runbooks, escalation, and enough audit context to answer what happened without guessing.

A prototype may demonstrate useful behavior without evidence for all of these areas. That is why the demo is an input to the readiness decision, not the finish line.

Step 1: How do you lock down auth and data access?

A login screen proves authentication flow, not authorization. For every protected action and object, test whether a different user, tenant, role, or identifier receives a denial. Client-side hiding can improve usability, but OWASP says it must not be the decisive access-control mechanism.

Enforce authorization at a trusted service layer where protected actions or data are controlled. That may be an API, gateway, serverless function, or database policy rather than one traditional server. For multi-tenant systems, centralize tenant and row isolation and test cross-tenant access directly. Database row-level security can be useful, but it still needs correct policies and verification.

Step 2: Can you operate and recover the data layer?

Do not migrate a data service merely because it was connected through a prototype tool. Lovable documents managed backend integrations and Lovable Cloud, and Replit documents persistent database or storage services because a published app's filesystem is not persistent. Keep a service when its ownership, access controls, capacity, retention, export, deletion, backup, and recovery behavior meet your requirements.

Version schema changes where the platform supports migrations and define recovery objectives for databases, object storage, identity configuration, secrets, and infrastructure state. Enable the necessary backup or point-in-time controls and test restoration plus reconciliation. A database backup may not include storage objects or every service configuration, as Supabase explicitly documents, so test the complete recovery scope rather than one database restore.

Step 3: Secrets and environments

Classify credentials before moving them. Public identifiers and publishable keys may be designed for an untrusted client, but privileged API keys, service credentials, signing material, and bearer tokens are confidential. Store confidential values in the platform's backend secret facility or another approved secret manager, grant least privilege, keep them out of bundles, logs, build artifacts, prompts, and repository history, and enforce authorization at the protected service or data layer.

Separate development, test or staging, and production according to risk, using distinct credentials and appropriately isolated data. Lovable's Test and Live environments are currently unavailable to new Cloud projects, so confirm the feature on the exact project or establish separation through the connected backend and delivery workflow. Treat exposed confidential credentials as compromised, revoke or rotate them, and verify downstream tokens, logs, and caches. The effort varies by credential and dependency.

Step 4: Hosting, CI/CD, rollbacks, observability

A bundled host is not automatically unsuitable for production. Lovable documents permanent publishing, custom domains, access settings, security checks, and external deployment through GitHub; Replit documents Autoscale and Reserved VM deployment paths. For the exact plan, verify capacity, regions, persistent storage, network controls, deployment identity, environment separation, custom-domain ownership, backups, rollback or forward-recovery procedure, support, portability, and service objectives. Move only when the existing platform cannot meet those requirements.

Automate repeatable build, test, approval, and deployment steps in proportion to risk. Test a failed release and the chosen rollback or forward-recovery path instead of promising an unmeasured recovery time. Add logs, metrics, traces, error tracking, uptime or synthetic checks, alerts, and runbooks based on what the team needs to detect and investigate. Protect observability data too, since logs can contain sensitive values.

Step 5: When do you keep the generated code, and when do you rebuild?

Not all generated code needs to be thrown away, and not all of it is worth keeping. Assess where the problems live: some gaps can be corrected locally, while others cross data-model, security, or deployment boundaries and need broader replacement.

Keep the foundation when its data model, boundaries, dependencies, maintainability, testability, and deployment model can meet the stated objectives with proportionate changes. Rebuild or replace a core layer when correcting it in place creates more migration risk, duplicated remediation, or long-term operating cost than a controlled replacement. Make the decision from repository and architecture evidence, a dependency map, migration plan, acceptance tests, rollback path, and total lifecycle cost.

"A prototype is valuable evidence, not proof of production readiness. Keep what meets the objectives, replace what does not, and make that decision from the architecture and tests rather than the tool name."

How long does it take, and how much does it cost?

There is no defensible universal duration or price. Scope depends on architecture, code and dependency quality, migration constraints, test coverage, data sensitivity, money movement, integrations, regulatory duties, exposure, and the required service objectives. A narrow internal tool and a public product handling payments or personal data need different evidence and remediation.

We review the repository, deployed architecture, data flows, platform configuration, and current evidence before estimating. The first output should identify whether targeted hardening, partial replacement, or a core rebuild is the lower-risk path, with assumptions and acceptance criteria visible. The detailed version is our software QA service, and the failure modes are covered in QA for AI-generated code.

Final thoughts

A fast prototype is valuable evidence, but production readiness is a separate, risk-based decision. Do not keep or replace a layer because of the builder's name. Verify authorization, recovery, confidential-secret handling, environment separation, deployment safety, observability, support, and the exact platform plan.

Record the evidence and unmet objectives, then choose targeted hardening, partial replacement, or a core rebuild. Review the result independently when the system handles sensitive data, money, privileged actions, or safety-critical outcomes, and reassess whenever the architecture or provider capabilities change.

Primary sources

Platform capabilities and engineering guidance were rechecked on 2 September 2026.