From AI Prototype to Production: A Release Gate

From AI Prototype to Production

An AI-generated prototype is ready for production only when the team has independent evidence for its requirements, domain behavior, architecture, data handling, identity, security, accessibility, reliability, operation, cost, legal obligations, ownership, and exit path. A hosted preview is not a release.

The practical artifact is a production evidence record. Every material gate needs an owner, verification method, result, unresolved exception, and approval. A check mark without evidence is not a gate.

Treat the preview as a candidate

Generated applications are often convincing because the interface arrives before the supporting system has been examined. E098 showed dashboards, submissions, carrier options, classifications, and reports that looked specific to commercial insurance. Some flows worked in a bounded demo. Others broke. None of the preserved runs established secure multi-user behavior, correct insurance operations, or a recoverable production service.

That does not make the prototypes worthless. It identifies the starting point. The team now has something concrete to test.

flowchart LR
    A["Generated preview"] --> B["Requirements and domain evidence"]
    B --> C["Owned architecture and data"]
    C --> D["Security and quality verification"]
    D --> E["Operated deployment"]
    E --> F["Release approval"]
    F --> G["Monitoring and review"]
    G --> B

Production is a continuing evidence loop, not a one-time conversion.

Build the release record in twelve gates

1. Reconcile the generated application with the requirements.

Freeze the requirements version that controls the release. Trace every material requirement to an implementation, test, and status. Mark anything the builder invented, omitted, or interpreted ambiguously.

Test the actual workflow, not the text on the screen. A card labeled "carrier matching" is not evidence that carrier rules are connected. A document called an ACORD form is not evidence that it is current, complete, or permitted for the intended use.

2. Obtain domain approval.

Give critical workflows to someone who understands the real process. Record the evaluator, test cases, disagreements, and remaining limitations.

In insurance, domain review may include form selection, classification, underwriting data, quoting, authority, disclosures, record handling, and state-specific obligations. In another field, the required expertise will differ. General code review cannot substitute for that work.

3. Establish ownership of the system.

Identify who owns the repository, builder project, cloud accounts, domains, certificates, databases, storage, identity tenant, external APIs, analytics, monitoring, and support relationships.

Move production assets out of personal accounts. Require more than one authorized administrator. Document recovery routes and remove unnecessary builder access.

4. Record the architecture and its one-way doors.

Document components, trust boundaries, environments, data stores, identity, authorization, integrations, background work, files, secrets, deployment, observability, backup, recovery, and exit.

State which parts are builder-managed and which are controlled by the team. Run a design review on the data model, tenant boundary, authorization policy, and integration contracts before adding significant real data. [[The Architecture Decisions Hidden Inside an AI-Generated App]] provides the deeper review.

5. Classify and govern the data.

List the data the application collects, creates, derives, transmits, and deletes. Record sensitivity, purpose, authority, retention, residency, processors, access, export, and deletion behavior.

Use representative synthetic data until the controls are ready. Do not paste personal, confidential, regulated, or customer data into a builder chat merely because the preview is convenient. Google's Firebase Studio guidance, for example, warns against entering personally identifiable information or user data into the prototyping chat.

Test migration and deletion. A visible delete button does not prove that backups, logs, files, analytics, and downstream systems follow the intended policy.

6. Verify authentication and authorization.

Authentication answers who the user is. Authorization answers what that user may do. Generated applications frequently implement the first more visibly than the second.

Test account creation, login, logout, session expiry, recovery, administrative access, role changes, invitation, suspension, and deletion. Then test direct access to another user's records, hidden routes, APIs, files, exports, and administrative actions.

OWASP ASVS provides testable web-application security requirements. Select and version the controls appropriate for the project's risk. Do not rely solely on the builder's automated review.

7. Secure the development and supply chain.

Create an inventory of source, dependencies, generated files, build tools, external services, and licenses. Remove embedded credentials. Store secrets in an appropriate manager and test rotation.

NIST SP 800-218 gives a common framework for preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. Use it to assign responsibility for dependency updates, vulnerability intake, patch decisions, release integrity, and incident response.

Record the builder and model as part of provenance when that matters to review. Generated code should pass the same source review and controlled build as other code.

8. Build a layered test suite.

Start with requirement-derived acceptance tests. Add unit tests for critical logic, integration tests for external boundaries, end-to-end tests for important workflows, regression tests for fixed failures, and negative tests for invalid or unauthorized behavior.

Test refresh, restart, concurrency, duplicate submission, partial failure, timeout, unavailable dependencies, and retry. Verify that recovery does not create duplicate financial, messaging, or workflow events.

Automated testing is not the entire quality record. Preserve manual exploratory results and domain review where automation cannot decide correctness.

9. Verify accessibility and performance.

WCAG 2.2 provides technology-neutral success criteria for accessible web content. Test keyboard operation, visible focus, labels, errors, headings, contrast, zoom, target size, authentication, and responsive behavior with the project's intended assistive technologies.

Use Core Web Vitals and project-specific limits to test loading, responsiveness, and visual stability. Measure on representative devices and networks. A fast builder preview on a development machine is not a production performance result.

Accessibility and performance defects often reveal structural problems in generated components. Fix them in the shared system rather than adding page-specific patches.

10. Prove the deployment can be operated.

Separate development, test, staging, and production where the risk warrants it. Make deployment repeatable from a controlled source and configuration. Protect production secrets and restrict who can release.

Add structured logs, metrics, traces where useful, health checks, alerts, dashboards, and an on-call or response route. Avoid logging secrets or sensitive data. Test whether the team can diagnose a failed request from the available evidence.

Back up the data and configuration, then perform a restore drill. Test rollback with a real prior release. A documented button is not evidence until the team uses it under controlled conditions.

11. Model cost and external obligations.

Record builder charges, model usage, deployment, database, storage, bandwidth, authentication, external APIs, monitoring, support, and expected human operation. Test a high-use scenario and define alerts or limits.

Complete the appropriate privacy, security, legal, procurement, accessibility, and regulatory reviews. Document terms, subprocessors, data processing, retention, intellectual-property questions, open-source obligations, and user disclosures.

These reviews depend on the product and jurisdiction. This guide is a release process, not a legal or compliance certification.

12. Approve the release and the rollback.

Bring the evidence record, open exceptions, risk owners, rollback plan, communications plan, and post-launch checks to the authorized decision maker. Critical unresolved controls remain holds.

Define the launch window, success and abort signals, responsible people, monitoring period, and first review date. After release, check real behavior, cost, errors, support contacts, and security events. Feed the result back into requirements and tests.

Use an evidence table, not a ceremonial checklist

The exact roles can change. The requirement for accountable evidence should not.

Know when to stop the release

Hold the launch when a material workflow is not correct, unauthorized access is possible, sensitive data has no approved handling path, the system cannot be restored, critical dependencies are unowned, the cost model is uncontrolled, or the authorized owner has not accepted the remaining risk.

Do not convert a hold into a launch by renaming the application a beta if real users or sensitive data face the same consequences.

Production means the team can explain and recover

The finish state is not a perfect application. It is an owned service whose important behavior has evidence, whose remaining risks are explicit, and whose team can observe, repair, restore, roll back, and eventually leave.

If the platform itself is still being selected, start with [[How to Evaluate an AI App Builder]]. If the first output is being overread, use [[What One-Shot App Generation Proves and Does Not Prove]].

AI assisted with research organization, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority. The transcript and linked public sources control factual claims. Publication remains unauthorized.