Start by preserving what the prototype proved
An application built with Claude Code, Cursor, Replit, Lovable, Bolt, v0, or another AI-assisted tool may have reached useful behavior faster than a conventional delivery program. That is not throwaway work. The prototype can reveal the real workflow, the language users understand, the data they need, the exceptions that matter, and whether the outcome is valuable enough to fund.
Production readiness is a separate question. A fast prototype often optimizes for the happy path and visible interface. A production system has to survive the wrong user, malformed data, a failed dependency, a partial release, a traffic spike, a support incident, and the engineer who was not present when it was created.
- Name the workflow, users, business owner, measurable outcome, and consequence if the application is unavailable or wrong.
- Document which prototype behavior is proven by real use and which remains a demonstration or assumption.
- Identify sensitive data, privileged actions, financial effects, contractual obligations, and regulatory exposure.
- Define the intended production audience, volume, availability, support window, and expected lifetime.
- Choose an accountable product and engineering owner before expanding use.
1. Product scope and operating ownership
The first production control is a bounded promise. Teams need to know what the application does, what it explicitly does not do, who approves changes, who supports users, and which outcomes determine whether it should continue.
A prototype can rely on the creator's memory. A production application needs requirements, acceptance criteria, ownership, documentation, and a roadmap that another qualified person can understand.
- Current user roles, workflows, states, decisions, exceptions, and service expectations are documented.
- A named business owner and technical owner can approve scope, risk, access, and release decisions.
- The repository, cloud accounts, domains, databases, vendor accounts, and billing belong to the company—not an employee's personal account.
- Licenses, generated assets, dependencies, model terms, data rights, and third-party services are known and acceptable.
- Support, incident escalation, maintenance, improvement, and eventual retirement have explicit owners.
2. Architecture and data boundaries
Production architecture does not need to be elaborate, but its boundaries must be intentional. The frontend, backend, database, files, queues, model providers, and connected systems should have defined responsibilities. Business rules that matter cannot live only in a browser component or an AI prompt.
Draw the system and data flows before changing them. Show every external service, trust boundary, privileged identity, source of truth, and path by which user- or model-controlled input reaches data or action.
- Development, testing, and production environments have isolated data, services, and credentials.
- Authoritative systems are defined for users, products, customers, orders, documents, finance, and other records.
- Database relationships, constraints, indexes, migrations, retention, backup, restore, and deletion behavior are reviewed.
- Transactions, concurrent updates, retries, duplicate events, timeouts, and partial failures have deterministic handling.
- Expected load, storage, model usage, latency, background work, rate limits, and cost have assumptions and limits.
4. Application, supply-chain, and AI security
Generated code is code. It can contain familiar web vulnerabilities, outdated patterns, hallucinated packages, permissive defaults, exposed secrets, and locally reasonable changes that violate a larger trust boundary. Automated scanning helps, but it does not replace architectural review, adversarial thinking, or human accountability.
If the application contains AI features or agents, treat model output as untrusted. Limit tools, data, permissions, autonomy, and cost; validate output before downstream use; and require human confirmation where actions create meaningful consequence.
- Threat modeling covers users, administrators, insiders, compromised dependencies, malicious files, prompt injection, and abused integrations.
- Input validation, output encoding, upload handling, query construction, redirects, webhooks, and errors are reviewed for injection and exposure.
- Secrets are absent from source and client bundles, stored in managed systems, scoped minimally, rotated, and separated by environment.
- Dependencies are pinned, inventoried, licensed, scanned, updated, and checked for suspicious or nonexistent packages.
- AI prompts, retrieved context, model output, tools, memory, logs, and evaluations are governed according to data and action risk.
OWASP's Secure Coding with AI Cheat Sheet is a useful baseline. For an independent review tied to your application, use SDG's vibe-coded application security audit.
5. Privacy, records, and data governance
A prototype often accumulates data because it is convenient. A production system should collect, expose, retain, and transmit data because there is an approved purpose. Inventory every personal, customer, employee, financial, proprietary, and regulated field and every third party that can receive it.
Logs, analytics, model prompts, support tools, and backups count as data stores. They need the same attention as the primary database because sensitive values often leak through debugging and observability paths.
- Data classification, purpose, consent, residency, retention, deletion, export, and subject-request behavior are documented.
- Encryption is appropriate in transit and at rest, and access to production data is limited, logged, and reviewable.
- Development and test environments do not use uncontrolled copies of production data.
- Logs, traces, prompts, analytics, crash reports, and vendor telemetry exclude or minimize sensitive values.
- Backups are protected, retention-aligned, and proven through restore testing rather than assumed.
6. Testing and release engineering
A prototype demonstrates that one path worked once. Production testing establishes which behavior must continue working across changes. Prioritize business-critical workflows, security boundaries, calculations, integrations, migrations, and failure paths instead of chasing a coverage percentage without context.
Every release should be reproducible from version-controlled source, reviewed by a qualified person, validated in an appropriate environment, and reversible when reality disagrees with the plan.
- Unit and integration tests protect critical rules, permissions, transformations, calculations, and integration contracts.
- End-to-end tests cover representative users, devices, accessibility, core workflows, exceptions, and recovery paths.
- Code review, branch protection, dependency scanning, secret scanning, and build provenance are enforced in CI/CD.
- Database and infrastructure changes are versioned, tested, sequenced, and recoverable.
- Release gates, feature flags, staged rollout, rollback, and communication match the application's consequence.
7. Integrations and systems of record
An application becomes operationally important when it connects to Shopify, ERP, CRM, identity, finance, documents, messaging, or data platforms. Each integration needs an owner, contract, authentication method, rate-limit strategy, failure behavior, and reconciliation process.
A green success message is not sufficient evidence that downstream state is correct. Production systems should prove what happened, detect divergence, and recover without silent duplication or loss.
- The source of truth and allowed direction of change are defined for each object and field.
- Requests and events are authenticated, authorized, validated, idempotent, correlated, and protected from replay where relevant.
- Retries use bounded backoff and dead-letter or exception handling rather than endless loops.
- Operators can see failures, understand impact, replay safely, and reconcile against authoritative records.
- Vendor outages, API changes, expired credentials, rate limits, duplicate events, and out-of-order events are tested.
8. Observability, reliability, and incident readiness
Production readiness means the team can tell whether the application is healthy from the outside and explain a failure from the inside. Define the user and business signals that indicate success, then connect them to technical metrics, traces, queues, dependencies, and alerts.
Alerts should be actionable and routed to someone who can respond. Runbooks should cover likely failure modes, data correction, vendor escalation, rollback, and communication.
- Indicators cover availability, latency, errors, queue age, data freshness, critical workflow completion, and integration health.
- Structured logs and traces use correlation identifiers and protect sensitive data.
- Alerts have thresholds, owners, escalation, deduplication, and links to dashboards and runbooks.
- Backups, restore, failover, rollback, incident response, status communication, and post-incident review are rehearsed.
- Cloud, database, vendor, model, storage, and traffic costs have budgets, anomaly alerts, and abuse limits.
9. Launch, adoption, and long-term maintenance
A safe launch expands consequence gradually. Begin with controlled users and representative data. Measure outcomes, errors, support volume, performance, and operational load before moving to the next cohort. Keep a manual or prior-system fallback until the application has earned dependency.
After launch, the roadmap should include security updates, dependency maintenance, model or vendor changes, data quality, accessibility, performance, support findings, and product improvements. AI can accelerate each release, but a human organization remains accountable.
- Pilot users, success criteria, training, communication, feedback, support, and escalation are ready before access expands.
- Migration and cutover have reconciliation, rollback criteria, freeze windows, owners, and decision gates.
- Production access, changes, incidents, costs, security findings, and user outcomes receive a regular review rhythm.
- Documentation covers architecture, setup, release, data, integrations, permissions, operations, constraints, and support.
- The organization can name the budget and team responsible for the application's next twelve months.
Decide whether to harden, refactor, or rebuild
Do not default to preserving every line because the prototype works, and do not default to rewriting because AI produced it. Evaluate components separately. A sound user interface may sit on a backend that should be replaced. A useful data model may need constraints and migrations rather than abandonment.
Rebuild when the current architecture makes authorization, tenant isolation, data integrity, deployment, or maintenance materially harder than recreating validated behavior on a sound foundation. Refactor when the boundary is clear and risk can be reduced incrementally. Harden when the design is basically correct and controls are missing.
- Keep and harden: sound boundaries, understandable code, controlled dependencies, and gaps that can be remediated directly.
- Refactor selectively: valuable components with specific architectural, security, or testing weaknesses that can be isolated.
- Replace a layer: exchange a risky backend, authentication scheme, data store, or integration while preserving proven experience.
- Rebuild: systemic trust-boundary, data-integrity, maintainability, or ownership problems make repair more expensive or dangerous.
- Retire: the workflow did not create enough value, has no owner, or should remain in an existing platform.
SDG can run this assessment independently or carry the application through architecture, remediation, rebuild, integration, launch, and support. See our enterprise AI application development practice.